-
Bug
-
Resolution: Fixed
-
Major
-
2.6.2, 2.7
-
MOODLE_26_STABLE, MOODLE_27_STABLE
-
MOODLE_26_STABLE, MOODLE_27_STABLE
-
MDL-45339-master -
-
BACKEND Sprint 14
I've just noticed we've got the main upgrade file calling get_config() a bit:
git grep get_config lib/db/upgrade.php
|
lib/db/upgrade.php: if ($filters = get_config(null, $config)) {
|
lib/db/upgrade.php: if (get_config('core', 'theme') === 'mymobile') {
|
lib/db/upgrade.php: if (get_config('core', 'thememobile') === 'mymobile') {
|
lib/db/upgrade.php: if (get_config('core', 'themelegacy') === 'mymobile') {
|
lib/db/upgrade.php: if (get_config('core', 'themetablet') === 'mymobile') {
|
lib/db/upgrade.php: if (in_array(get_config('core', 'theme'), $themes)) {
|
lib/db/upgrade.php: if (in_array(get_config('core', 'thememobile'), $themes)) {
|
lib/db/upgrade.php: if (in_array(get_config('core', 'themelegacy'), $themes)) {
|
lib/db/upgrade.php: if (in_array(get_config('core', 'themetablet'), $themes)) {
|
That goes against our upgrade code restrictions:
http://docs.moodle.org/dev/Upgrade_API#Upgrade_code_restrictions
And more to the point, I don't think that function can be guaranteed to be long-term safe for upgrade. In fact it looks like it already uses a MUC cache - which itself could be problematic too.
I think we should confert those uses to standard DB api calls.
- Testing discovered
-
MDL-45298 Keep old user/category/course/site theme settings during 2.7 upgrade to make it easier for admins who want to keep using old themes
-
- Closed
-