* CLI adhoc_task.php: new option --taskslimit
* CLI adhoc_task.php: --execute option is implied when other options are given
* core\task\manager::get_next_adhoc_task(): new param $number
for limiting number of tasks to run
* CLI adhoc_task.php: new option --id
* cron::run_adhoc_task($taskid) for running tasks by id
* core\task\manager::get_adhoc_task($taskid) for retreival/locking
A new setting, $CFG->setsitepresetduringinstall, has been added to
config file, to let admins define the site admin preset to be applied
during the Moodle installation.
Besides, a new parameter, "--sitepreset" has been also added
to admin/cli/install.php, to let define it too when running the
upgrade process using CLI.
Remove support for migrating MySQL databases using the old MyISAM storage
engine to the InnoDB storage engine. MyISAM was supported up to Moodle
2.8 (dropped in 2.9: MDL-46064). Beyond Moodle 3.3 -- the highest version
that can upgrade from 2.8 -- this functionality was no longer applicable.
This isn't really a deprecations where something is replaced
by another and all uses must adapt to. Instead it's just a
fallback functionality that will stop working in Moodle 4.2.
Because of that, I've tried to add TODO/@todo comments to
the places that will need to modified, always pointing to
MDL-71421 that is where the removal will happen.
Also, haven't added any debugging() output, after thinking
a lot about it, because this isn't anything that developers
can be using but a internal implementation detail (a fallback)
that we want to remove in some versions.
Table names and database name now enclosed in backticks.
admin/cli/mysql_collation.php failed if $CFG->prefix was blank with
MySQL 8.0 because table 'groups' conflicted with a new reserved word.
Note that this quotes both mysql_collation.php and mysql_compressed_rows.php
but only the former was mal-functioning.
The case of mysql_compressed_rows.php is a little bit special because
not all tables are processed, only those having big rows. And the groups
table is not one of them. In any case, better add the quotes there for
any future case.
Also, when testing this patch https://tracker.moodle.org/browse/MDL-71512
was discovered and will need to be fixed to make core 100% compliant
with MySQL 8.0 and MariaDB 10.6 and up.
The machinery to fix orphaned calendar events that were broken by MDL-67494.
The solution consists of:
1) Upgrade step that checks if this site has executed the problematic upgrade steps and
if positive, it will schedule a new run for calendar_fix_orphaned_events adhoc task.
2) Adhoc task that will self-spawn calling the recovery machinery, running until
all the orphaned calendar events are fixed. It also sets the maximum runtime of
60 seconds. It is also possible to override that number by specifing the desired
number setting the ->calendareventsmaxseconds in your config.php
3) CLI script that will look for all the calendar events which userids
where broken by a wrong upgrade step, affecting to Moodle 3.9.5
and up.
It performs checks to both:
a) Detect if the site was affected (ran the wrong upgrade step).
b) Look for orphaned calendar events, categorising them as:
- standard: site / category / course / group / user events
- subscription: events created via subscriptions.
- action: normal action events, created to show common important dates.
- override: user and group override events, particular, that some activities support.
- custom: other events, not being any of the above, common or particular.
By specifying it (--fix) try to recover as many broken events (missing userid) as
possible. Standard, subscription, action, override events in core are fully supported but
override or custom events should be fixed by each plugin as far as there isn't any standard
API (plugin-wise) to launch a rebuild of the calendar events.
4) Unit tests and helper functions to generate calendar events. We have decided to
keep the tests simple, testing only true and false and not using data generators because
the code is purely to recover the calendar events and won't turn into an API or something
and also due to the urgency of this issue.
The helpers have been created in calendar/tests/helpers.php since there are no data generators
for calendar.
Copy the CLI scripts from admin/tool/task/cli to admin/cli (schedule_task.php and adhoc_task.php)
and rename to scheduled_task.php and to improve in order to use cron_run_inner_scheduled_task.
* Plugins can now explicitly declare supported and incompatible Moodle
versions in version.php
- $plugin->supported[37,39];
supported takes an array of ascending numbers, that correspond to a
range of branch numbers of supported versions, inclusive. Moodle
versions that are outside of this range will produce a message
notifying at install time, but will allow for installation.
- $plugin->incompatible = 36;
incompatible takes a single int corresponding to the first incompatible
branch. Any Moodle versions including and below this will be prevented
from installing the plugin, and a message will be given when
attempting installation.
It is still used widely in the plugins that would stop working suddenly
without being warned via a debugging message. We must keep it forever as
an alias for the wwwroot.
