* 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.
There are various places where it's not guaranteed that the
variable being used is array, and instead, can be null, bool, int...
We need to check that because php74 warns about it.
Where possible we have used the coalesce operator as
replacement for isset() ternary operations.
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()
This function was used only by deleted upgrade steps
so it's safe to proceed with straight deletion, considering
it internal. Deletion has been documented in corresponding
upgrade.txt files.
These functions and setting 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_theme_is_from_family()
- upgrade_find_theme_location()
- linkcoursesectionsupgradescriptwasrun setting
The upgrade_fix_block_instance_configuration() function was used
only by deleted upgrade steps so it's safe to proceed with straight
deletion, considering it internal. Deletion has been documented in
corresponding upgrade.txt files.
This extends the step
Given the following "users" exist:
to also support things like
Given the following "mod_quiz > user overrides" exist:
Instructions are on the behat_data_generators and
behat_generator_base classes.
Basically the provider is ignoring the CRLF to LF normalization
results and loading the original file again.
This doesn't have any impact normally, because all moodle
files are LF ones and people using other systems have their
git configurations set to work that way (not modify or force LF).
But there may be checkouts out there (for example travis) where
the git configuration by defult is to convert to the OS, causing
windows runs to fail badly there. See the issue for more info
and links.
When a closing comment is used, such as when we wrap css with the
rtl:begin:ignore and rtl🔚ignore (the latter being the closing),
it is ignored in the following case:
- If the closing comment is the last item in a csslist like:
div {/*rtl:begin:ignore*/left:20px; text-align:left/*rtl🔚ignore*/}
in which case there is no css rule following the comment for it to be
associated with. It is therefore not seen and registered, meaning we
continue ignoring rtl (a bug).
In such cases, we should either:
- ensure the comment is not the final element in the css list
- use self-closing (/*rtl:ignore*/) comments for each rule instead.
- use a self-closing comment on the entire css list, if applicable.
The core_rtlcss class extends the \MoodleHQ\RTLCSS\RTLCSS class. This
upstream library had tests, but these were not included in core. This
change uses those test cases to test core_rtlcss, to make sure future
lib changes don't break the css parsing.
resolve_page_instance_helper() already processes the type, returning
the correct context that should be processing the navigation URL.
With that extra call to parse_page_name() the 2nd call always returns
"core", ultimately leading to tons of behat failures because "core" is
not aware of those (plugin, quiz for now) pages typology.
