The new parameter of curl_security_helper::url_is_blocked() introduced
in MDL-71916 became part of the API. Even if we reverted it quickly,
someone can use a released Moodle version that has that parameter in
place. For that reason and also to avoid potential troubles in the
future (e.g. when yet another argument would be added to this method),
we need to make it clear that the second parameter of this method should
never be used again.
Poor $maxredirects, you did not live long with us. Oh well.
This reverts the original fix introduced in MDL-71916. It introduced an
extra native cURL call inside curl_security_helper to check if the given
URL triggers a redirect to a blocked URL or not.
Shortly after the release, a couple of regressions were reported as a
result of the integrated solution. It was agreed to revert the fix and
progress with implementing an alternative approach.
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.
Before this patch strings that were declared over multiple lines in
a template would not be parsed correctly.
{{#str}}value,
mod_forum{{/str}}
would have been been parsed to get_string('value', 'core')
{{#str}}
value, mod_forum
{{/str}}
would have been been parsed to get_string('', 'core')
If the allcountrycodes filter contains only invalid values, ignore the
whole filter setting and make get_list_of_countries() return the full
list of all known countries, rather than empty list.
When editing a user and checking the 'Delete picture' checkbox to delete
the old picture and uploading a new one at a time, the new one didn't appear
in the user profile. This happened due to the 'if/else' statement
in the 'core_user::update_picture()' method which allowed either to delete
the old picture or to upload a new one.
The fix removes the 'else' part of the 'if/else' statement to force
checking for a new uploaded picture no matter if a user checked
the 'Delete picture' checkbox or not.
When a given user doesn't have the capability to "Include user data"
during course copying, freeze the form element rather than not adding
it at all.
This caused problems as the element was required before preceding with
the course copy.
Currently, PHP getimagesize method doesn't support SVG images.
As some features, such as badges, processs and optimise the images
before using them, a new filetype group has been created to exclude
SVG from there: optimised_image.
SVG can't be removed from web_image because then users won't be
able to add SVG images to their courses using labels, pages...
Some browsers like Firefox are very inflexible with window.open()
and block it if it is not instantly invoked after the user click.
Also according to https://stackoverflow.com/a/6807615 it is best
practice to replace self:: with static::
Fetching the theme version number via get_component_version() which
requires lib/adminlib.php unnecessarily increases memory consumption.
Using get_config() is more direct and simpler.
