This just deletes all the upgrade steps previous to 3.6.0. Some
small adjustments, like tweaking globals can also be applied
when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2018120300 (v3.6.0) as anti-cheating measure.
Note that in this case, there wasn't any case of upgradelib
functions being used, hence we haven't to deprecate/remove
anything in codebase. When there is such a need, that is done
in separate commits (one for each function) and documented here.
See MDL-65809 commits for an example removing/deprecating a
good number of functions.
version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in master, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
This just deletes all the upgrade steps previous to 3.5.0. Some
small adjustments, like tweaking globals can also be applied
when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2018051700 (v3.5.0) as anti-cheating measure.
Previous commits have removed/deprecated all the upgradelib functions
not used anymore in codebase. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_fix_block_instance_configuration()
- upgrade_theme_is_from_family(), upgrade_find_theme_location()
and linkcoursesectionsupgradescriptwasrun setting
- upgrade_block_positions
- upgrade_fix_config_auth_plugin_names()
and upgrade_fix_config_auth_plugin_defaults()
- format_xxx_upgrade_remove_numsections(), format_xxx_upgrade_hide_extra_sections()
and format_xxx_upgrade_add_empty_sections()
- filter_mathjaxloader_upgrade_cdn_cloudflare()
and filter_mathjaxloader_upgrade_mathjaxconfig_equal()
- get_assignments_with_rescaled_null_grades()
These have been kept because continue being used by restore:
- \core\task\refresh_mod_calendar_events_task
These functions were used only by deleted upgrade steps
so it's safe to proceed with straight deletion, considering
them internal. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_fix_config_auth_plugin_names()
- upgrade_fix_config_auth_plugin_defaults()
3.7 (min PHP 7.1) requires 3.2 (first version supporting PHP 7.1)
This just deletes all the upgrade steps previous to 3.2.0. Some
small adjustments, like adding missing MOODLE_INTERNAL or tweaking
globals can also be applied when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2016120500 (v3.2.0) as anti-cheating measure.
Next commit will get rid of/deprecate all the upgradelib functions
not used anymore in codebase. (note there isn't any this time).
As a result of fixing the auth plugins config storage in MDL-12689, many
settings would be falsely reported as new ones by
admin/upgradesettings.php. We do not want to confuse admins so we try to
reduce the bewilderment by pre-populating the config_plugins table with
default values. This should be done only for disabled auth methods. The
enabled methods have their settings already stored, so reporting actual
new settings for them is valid.
It has never been guaranteed that settings.php would always be included
from inside the core\plugininfo\auth::load_settings() scope only.
Alternative fix would be to use $plugininfo->name but I think it is
better to be explicit here (same as we are explicit with setting names,
strings etc).
Some auth plugins used to have a mix of the legacy style of plugin names
in config_plugins table (such as 'auth/mnet') and the new correct
style (such as 'auth_mnet'). Attempting to rename the setting plugin via
low level SQL UPDATE could lead to duplicate key violation.
The patch introduces a new helper function to safely migrate the old
settings to the new ones, eventually informing the admin about the
values mismatch.
version = planned 2015051100 release version
requires= current 2015050500 rc1 version
Note: On purpose, the course format social wrong version (2015102100)
has been kept unmodified. Looking forward a solution right now.
From now on, all English strings use the new syntax. They are not
eval()'ed any more and the only valid placeholders are {$a} and
{$a->foobar}. No extra quotes escaping, dollar sign escaping and putting
double percent signs.
The modified files were exported from AMOS database repository in the
new syntax and were re-ordered by stringid. Standard GNU/GPL and PHPdoc
blocks are added. Where there was no copyright note so far, I added the
default one with Martin Dougiamas as the copyright holder.
Live long and prosper.
