The external function 'core_user_update_users()' always returned 'null' no matter
if a user or users were successfully updated or there were some failures.
So, there was no way for the caller to know which users were updated and which were not.
After the commit changes the function returns an 'external_warnings' instance. The function uses
a delegated transaction for each user to update within a loop. This enables the function to update
as many users as possible. This differs from the previous behavior of the function when it used
a delegate transaction outside of the loop where the users were updated. This resulted in a rollback
of the whole users updating in case any of the users had some invalid data. For each user within a loop
a 'try-catch' block is used to throw exceptions which are actually returned
as warnings by the function when they are caught.
Until Moodle 4.0, renderer.php file was optional (although highly recommended)
for course formats. From Moodle 4.0 onwards, renderer is required to support
the new course editor implementation.
The legacy_format_renderer class has been created for backward compatibility,
to avoid some errors with course formats (such as social) without the renderer
file. Apart from that, course_format->get_renderer() method has been reviewed
to use this legacy_format_renderer when no renderer.php file is found.
When defining settings that are used by scheduled tasks,
it is also useful, or even needed, to know the status
of that scheduled task to have the whole big picture of
that part of the system.
Based on the admin_setting_description, this new setting
reports its name, its status, a link to the configuration.
When adding a new setting of this type, the user can add
an extra description field to complete the whole meaning.
The deprecated method to render the dropdown based activity chooser
from 430746d3 was still being called, which produced debugging on
the site when doing so.
It's mostly addDocuments(), used by test_add_document_batch_large()
with 100 big documents what requires a lot of ram
although apparently, it's freed (partially) once ended.
Just the peak usage remains high. In any case, isolating that
test to avoid the non-freed side of it to consume too
much memory for the rest. (We allow "only" 2GB).
Still, I think that there is a good work about to detect which
tests are leaking / consuming too much, I'd bet there are
a bunch running completely out of control.
Upstream behat/mink-extension isn't updated since 2018.
So we switch to friends-of-behat/mink-extension until
upstream situation is clarified.
But friends-of-behat/mink-extension has some PHP8 issues
that, at the time of writting this, have not been solved:
- https://github.com/FriendsOfBehat/MinkExtension/pull/9
So we are temporarily changing to one fork:
https://github.com/moodlehq/MinkExtension
Whenever those issues are solved by friends-of-beha or behat
we will change back to them and remove our fork.
Generated with composer 2.x and PHP 7.3
