It seems that the new phpcs3 checker is now controlling those
line comments that previously were ignored.
This commit just looks for all the cases and bulk-add
them when needed. The bash script (mac) used to add all them is:
while read -r line; do
arr=(${line//:/ })
if [[ -n ${arr[0]} ]] && [[ -n ${arr[1]} ]]; then
echo " file ${arr[0]}, line ${arr[1]}"
sed -i "${arr[1]}s/\$/\./" ${arr[0]}
fi
done < <(find . -name version.php | xargs ag --nomultiline '>(version|requires) *=.*//.*[^;\.]$')
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.
The external database authentication plugin (auth_db) can update the
external database if mapped fields are set to Update external: On
update. This change adds error handling in case this update fails.
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()
Significant string changes:
* importgroups_help,core_group - Correcting optional fieldnames
(removing picture, hidepicture and adding groupidnumber, groupingname
and enablemessaging)
* penaltyforeachincorrecttry_help,core_question - additional paragraph
about scoring logic
* resultdownloadready,tool_dataprivacy - wording corrected (no need to
go to a download page)
* auth_dbfielduser,auth_db - varchar data type requirement
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).
Significant string changes:
* withselectedusers_help, core - removing mention of 'Add a common note'
as the option no longer exists
* considereddigitalminor and digitalminor_desc, core - more
child-friendly wording
* configmessagingallusers, core_admin - clearer explanation
* auth_dbtype, auth_db - fixed broken link
The output strings for the Test Settings function were hard-coded English
strings. They've been changed to standard language strings which can be
translated and maintained via AMOS.
Also fixed call to get_string() and defined var 'errorlogtag'
in base class.
AMOS BEGIN
MOV [auth_dbusernotexist,auth_db],[auth_usernotexist,auth]
AMOS END
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.