Converts existing data to new structure in database as part of
upgrade, including a progress bar.
Deletes the database tables and fields that were used by the old
system and are no longer needed.
Centralise management of all types of cron tasks with registration, scheduling,
parallel task conflicts(blocking) and running once off tasks, all using an
administration screen.
This is a combination of several issues:
MDL-25502: Added "black magic" task allocator for cron
MDL-25503: Add step to cron to run all scheduled tasks
MDL-25504 cron: Refactor to use scheduler
MDL-25505: Add an admin interface to schedule tasks via cron.
MDL-25507: Add support for adhoc tasks.
This data should all have been upgraded when moving to Moodle 2.1. It
was only kept as a back-up, and now, after 3 years have past, we can
clean it up.
This locking system is designed to be used everywhere requiring
locking in Moodle. Each use of the locking system can be configured
to use a different type of locking (or the same type with a different
configuration).
The first supported lock types are memcache, memcached, file (flock),
db (specific handlers for pg, mysql and mariadb).
Instead we will create new MUC caches inside each filter plugin.
Please note that all cache filters should work with local caches
without the need of strict cache invalidation.
Too many functions, too different parameters, unnecessary DB queries.
All repositories developed for Moodle 2.3-2.5 will continue to work.
Also get rid of DB field files_reference.lifetime, it is not used by
anybody except repository itself.
This parallels question_attempt->minfraction, which allows the
fractional mark to go below zere.
This is needed to allow the certainty-base marking behaviours to work
better.
Fields files.referencelastsync and files.referencelifetime just waste the space and actually duplicate the fields
files_reference.lifetime and files_reference.lastsync
This patch includes:
* version column removed from modules table, now using standard config, this allows decimal version for modules
* version column removed from block table, now using standard config, this allows decimal version for blocks
* module version.php can safely use $plugins instead of module
* new plugin_manager bulk caching, this should help with MUC performance when logged in as admin
* all missing plugins are now in plugin overview (previously only blocks and modules)
* simplified code and improved coding style
* reworked plugin_manager unit tests - now using real plugins instead of mocks
* unit tests now fail if any plugin does not contain proper version.php file
* allow uninstall of deleted filters
to question bank
- move cron to clean up old cache records move code and
rename classes
- further review of the quiz reports statistics code
- starting to separate calculations of quiz stats, question stats and
response analysis
- introduce hashcode db field for cached stats convert
- code to use qubaids hashcode for caches
We just drop the old tables (including previous upgrade steps) and
re-create the new ones, because these tables just cache calculated
statistics. No important data is stored in them.
1) Moved the calendar types location to a sub-folder in the calendar directory.
2) Removed/moved language strings.
3) Removed calendar types that should be downloaded as plugins.
4) Removed a Non-English language pack for the Gregorian calendar type that
should be downloaded separately.
5) Removed custom files responsible for checking for updates and uninstalling
calendar types, which should be done by core.
6) Removed JS from the calendar_month block as there is no non-JS alternative
provided and the JS written does not make use of the YUI library to ensure
multiple browser support.
7) Removed code from the base class responsible for creating timestamps that
are saved in the DB.
8) Added PHPDocs.
Note: In the original patch we are editing core functions responsible for saving
time in the database in the calendar base class. This is very dangerous, we do
not want to touch these functions as it could cause a complete fubar of the
database. There are places we are forcing the use of the gregorian calendar as
we are passing dates generated by the PHP date function, where as sometimes
we pass dates from usergetdate (which was being overwritten to return the
date specific to the calendar). We can not expect third party modules to
change the calendar type depending on the format they pass to these functions.
Move all statistics temporary tables into the code. We are not
going to continue to use database templates. They were a mix
of reading the install.xml and tables in the database. It is
much clearer to have them created inline at the point they are
used in the code.
