Static variables do not behave the way you might expect when accessing
them through the classes inheritance. When accessing a method via self::
or static:: operators, even though the method is inherited, its variable
scope is not. So the method unique_sql_parameter() was using the scope
of the child class and each child class had its own sequence of usp1,
usp2, usp3, ... placeholders. This led to "Incorrect number of query
parameters" error when multiuple condition classes were contributing to
a single SQL query.
All credit should go to Adam Olley who debugged and described the
essence of the problem in the tracker.
Before this change if a language pack was updated by the
\tool_langimport\task\update_langpacks_task scheduled task, changes
would not be available to users until an admin manually cleared the
strings cache.
This change causes the cache to purged when a language pack it update,
this will cause it to rebuild so users will start seeing updates
automatically.
Two new classes in lib/adminlib. One providing validation for a
newline-delimited textarea supporting domain names, domain wildcards,
IPv4/IPv6 addresses and IPv4/IPv6 ranges. The second providing
validation for a newline-delimited textarea of port numbers.
Sometimes it is possible that a user is presented with the profile
edit form, but is in a state where they are not considered fully
set up (one example is when a site is installed using the CLI script)
In these cases the filepicker gets upset when the user tries
to upload a profile picture.
This patch simply disables that field in these cases and replaces it
with an error message explaining what's wrong.
We should complete the deletion process using the same
user that started it.
Added a new param to loginas() to prevent the event to be generated as
there is no need to generate an new event for that as the user didn't
explicitly loginas again.
AMOS BEGIN
MOV [mobilecssurl,core_admin],[mobilecssurl,tool_mobile]
MOV [configmobilecssurl,core_admin],[configmobilecssurl,tool_mobile]
AMOS END
From Plugins / Web Services / Mobile to Appearance / Mobile
If the user navigates away from the grading page immediately
after saving the grading form, the browser warning can be
safely omitted, as there are no unsaved changes. This is achieved
by calling `reset_form_dirty_state()` of the core_formchangechecker
YUI module, which is responsible for the warning.