-
Improvement
-
Resolution: Fixed
-
Minor
-
3.9
-
MOODLE_39_STABLE
-
MOODLE_39_STABLE
-
MDL-68056-master -
-
3
-
Activity Sprint 8, Activity Sprint 9
This method is called once per course section and currently handles a few cases:
- If $THEME->enablecourseajax == true AND $course->id == $this->page->course->id AND $usermodchooser == true (a user pref), then display the "Add an activity or resource" link allowing the chooser modal to be opened.
- If $THEME->enablecourseajax == true AND $course->id == $this->page->course->id AND $usermodchooser == false (a user pref), then display fallback 1 - a control including two lists of resources and activities which, when selected, take the user to the creation page for that module.
- If $THEME->enablecourseajax == true AND $course->id != $this->page->course->id, then display fallback 1 - a control including two lists of resources and activities, which, when selected, take the user to the creation page for that module.
- If $THEME->enablecourseajax == false, then display fallback 1 - a control including two lists of resources and activities which, when selected, take the user to the creation page for that module.
- If JS is disabled in the browser (not a case we support any more), then fallback 2 is shown - a control including the same two lists of resources and activities plus a 'Go' submit button. The user needs to select the activity/resource and then click 'Go' in this fallback case.
Fallback 1 and 2 are handled by the same code - it's just that when loaded in a browser without js enabled, the 'Go' button is shown (it's inside a <noscript> tag)
The way this method is currently structured is such that we always generate the fallback control HTML. I.e. every time this method is called, which is once per course section, this is created. Then, if the theme supports course ajax (provided the course also matches the page course, as above), then we wrap that entire fallback HTML inside <noscript> tags and append the link control to the output string before returning.
I think we can clean this up. We don't have any obligation to support the "I disabled JS in my browser" case as we have been JS dependent for some time now. We should therefore be able to do one of two things depending only on the courseajax support:
- Render fallback control 1 in cases where:
- The theme sets $THEME->enablecourseajax to false or;
- $THEME->enablecourseajax is true but course doesn't match the this->page->course or;
- The user has disabled the modchooser in their user prefs.
- We're running in Behat, since many behat setup steps expect the step I add a "x" to section "y" and I fill the form with to work without JS.
- Render the link control in cases where the $THEME->enablecourseajax is true and the course matches the $this->page->course and the user preference allows for the chooser.
This would mean we're likely going to reduce DB calls, and reduce the volume of code we're running on every course home load - when editing is enabled, of course.
- caused a regression
-
MDL-68231 Dropping sections does not complete
- Closed