- Core upgrade MUST NOT call rebuild_course_cache() at all - update DB directly instead
- Plugins MUST call rebuild_course_cache(.., TRUE) for clearing the course cache and can not update DB directly
- Plugins MUST NOT call rebuild_course_cache() unless for clearing the cache
- Created function upgrade_ensure_not_running() to be included in other functions that can not be used during upgrade
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
- Course categories caches are purged by event now
- session cache has additional 10 minutes ttl to clear itself and accomodate for permission changes that do not trigger event purging
- additional request-level cache for coursecat::get()
- We store only children of one category in one cache key
- Function coursecat::get_children() can return results sorted and/or paginated. Added tests
- Retrieve and cache only often-used fields of course category
- Removed function coursecat::get_all_visible() as potentially causing performance issues
- removed function coursecat::get_all_parents() as ineffective and unnecessary, replaced with get_parents()
- retrieve all fields from course_categories when unretrieved field is accessed
Also some code improvements:
- rename functions starting with _ , rename arguments, etc.
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.
