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.
I did not think thought through if this new URL parameter would be a
potential security hole. The simple cop-out option is to make it only
work on Behat sites for now.
Site indicators shared with the registration hub used to have the hub
URL in the relevant setting names - such as site_name_httpsmoodlenet.
This upgrade step converts all such settings and drops the URL suffix
because we do not support alternative hubs any more.
Additionally the upgrade step renames the official hub and updates its
URL so that existing registrations with https://moodle.net are still
valid.
This is implemented in a bit of a hacky way, because the only other
alternative would be a large rewrite of the whole class, which is
not feasible for me right now. Note that many other types of thing
that can be generated suffer from the same issue. (E.g. if you ever
wanted to generate two groups with the same name in two different
courses and then add group memebers.)
It is worth doing a special-case fix for question categories, because
way Moodle works, it is inevitable that we end up with many categories
called 'top' in the database.
