get_plugin_list was calling clean_param($pluginname, PARAM_PLUGIN) a
lot (600+ times per page), and that is much slower than you would guess.
A specific function for this case, (which we then also use from
clean_param) is a performance win.
This clean_param was added as part of MDL-22015. It is a good idea when
developer debug is turned on, but it showed up as a surprisingly
expensive cost in our profiling.
This change:
1. Removes the check during string_extist. This will not change
behaviour, the method returns false if the string does not exist.
2. In get_string, it only does the check if debugging is set to
DEVELOPER level.
I also broke the unit tests into more, smaller, named tests, so that
when things start failing, more tests are run, and it is clearer what
the problem is.
In a couple of cases, I adjusted the $ideal lenght in the test. A
careful counting of the characters in the test input (added as comments)
suggests that the new values make for better tests.
The patch reimplements the core_string_manager::get_language_dependencies()
so that potentially mis-configured language packs with circular
dependencies or self dependency do not make the site unavailable.
Unit tests for the expected behaviour are added.
The badges feature allows to integrate Mozilla "Open Badges" to issue, assign,
manage and display digital badges in Moodle. This feature supports:
-- badge creation and issuing based on criteria
-- badge baking and verification service
-- direct pushing of internal badges to external backpack
-- interanl and external badge display in Moodle
-- Moodle block to display latest badges
It is weird, but Chrome PDF viewer keeps retrying byteserving requests for anything but 407. This commit also normalises response headers on all error pages.
GD PHP extension is now required. Add-ons need to remove $CFG->gdversion tests. The worst case regression is that add-on will think GD is not available.
Data cached in these caches change only at well defined places (during
need for upgrade checks, at the plugin management screen etc). So it
makes sense to use proper application caches instead of request caches.
This saves couple of database queries at almost every page in Moodle.
This is quite frequently called function at most pages. The cache needs to be
invalidated only when a new plugin is installed or existing plugin uninstalled.
However, given how moodle_needs_upgrading() checks for new plugins, we need to
purge the cache there. Which is a shame because this means that the cache gets
purged in each cron call and when the admin looks at the front page and/or
system notifications page.
Cache stores with no hits and some misses are highlighted in red. Caches
stores with some hits but more misses are highlighted in yellow.
Otherwise (more hits than misses) the stores are highlighted in green.
This change removes the "0 bytes" option from the get_max_upload_sizes list
and replaces it with "Course limit (X)" or "Site limit (X)" (whichever is smaller).
This means we can remove all custom handling in the modules that were removing and
adding these options. It only affects pages that pass valid options for sitelimit and
courselimit - so admin pages will work correctly.
It also orders the list so the course/site limit options will be first
(as it will be the largest).
AMOS START
REM [courseuploadlimit, core] has been parameterized to get [uploadlimitwithsize, core]
AMOS END
