Following MDL-63580 this now finally deprecates and removes the class
\tool_task\run_from_cli, please use \core\task\manager.
Following MDL-63580 this now finally deprecates and removes
- admin/tool/task/cli/schedule_task.php, use admin/cli/scheduled_task.php
- admin/tool/task/cli/adhoc_task.php, use admin/cli/adhoc_task.php
Also mentions and references to the old CLI scripts are updated to
point to the new counterparts.
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
This patch fixes the behat failures with classic for the scenario
"Upload users enrolling them on courses and assign category roles".
There is a "Participants" link hidden in the "Site pages" which is
causing these failures.
Apart from this, there was another issue because it was not possible
to navigation with classic (I've added one extra step to visit homepage).
- Updates to log stores and backup helper to improve performance when
checking if a course has been modified.
- This is a breaking change as it adds a new function on the sql_reader
interface.
Co-authored-by: Kevin Pham <keevan.pham@gmail.com>
Applied the following changes to various testcase classes:
- Namespaced with component[\level2-API]
- Moved to level2-API subdirectory when required.
- Fixed incorrect use statements with leading backslash.
- Remove file phpdoc block
- Remove MOODLE_INTERNAL if not needed.
- Changed code to point to global scope when needed.
- Fix some relative paths and comments here and there.
- All them passing individually.
- Complete runs passing too.
Special mention to:
- Some fixtures, initially defined in the test files have been
moved to new files in fixtures subdirectory, leaving the unit
test files clearer:
- moodle2_course_format_test.php
- Rename wrong named test:
- baseoptiogroup_test = baseoptigroup_test
Adds a callback xxx_pre_enable_plugin_actions in admin/modules.php
which plugins can use to force additional actions before enabling the
plugin. The return value (bool) from the plugin callback method
specifies whether the process of enabling the plugin should continue
after the added actions or not.
The defined context in admin_settingpage does not always relate to the
system context. One example is the 'frontpagesettings' admin setting
page which specifies front page as it's default context. Therefore, the
page context in admin/settings.php should be consisent with the defined
context in the related admin_settingpage object to make sure that the
expected navigation menus are being displayed and properly highlighted.
Additionally, the code in admin/settings.php related to the breadcrumb
structure specific to 'frontpagesettings' has been removed as it is no
longer relevant.
