Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-70233

alternative_cache_factory_class isn't honored when caching is disabled

XMLWordPrintable

    • MOODLE_310_STABLE
    • MOODLE_310_STABLE, MOODLE_311_STABLE
    • MDL-70233-alternative-disabled-cache
    • Hide

      1) Install tool_forcedcache for use in testing the seperate writer.

       

      git clone git@github.com:catalyst/moodle-tool_forcedcache.git admin/tool/forcedcache

      2) Visit admin/index.php and proceed through the frontend upgrade until you reach the 'Plugins Check' page, and do not proceed any further.

      3) Visit the site dataroot/muc folder, and confirm the config.php file is present.

      4) Delete the config.php file.

      5) Reload the 'Plugins Check' page and confirm that the config.php file was regenerated.

      6) Now proceed with the plugin installation, and get to the main moodle home.

      7) Edit config.php to add the following line:

       

      $CFG->alternative_cache_factory_class = 'tool_forcedcache_cache_factory';

      8) Visit /admin/tool/forcedcache/index.php and confirm that forcedcaching is active and OK. This shows that an alternative cache factory is in use.

       

      9) Delete the muc/config.php file.

      10) Bump version.php up 1 increment, to trigger an upgrade, and click through the upgrade until you reach the 'Server Checks' page.

      11) Confirm that the config.php file hasn't been regenerated. This is a non-cached page, so this hits the code path in which the disabled writer is active.

      12) As a final confirmation, edit the /admin/tool/forcedcache/classes/cache_factory.php file and add the following line at the start of the get_disabled_writer function:

       

      die();

      13) Reload the page and confirm it dies and you see nothing. This confirms the alternate writer is being loaded and applied in disabled situations.

       

       

       

      Show
      1) Install tool_forcedcache for use in testing the seperate writer.   git clone git @github .com:catalyst/moodle-tool_forcedcache.git admin/tool/forcedcache 2) Visit admin/index.php and proceed through the frontend upgrade until you reach the 'Plugins Check' page, and do not proceed any further. 3) Visit the site dataroot/muc folder, and confirm the config.php file is present. 4) Delete the config.php file. 5) Reload the 'Plugins Check' page and confirm that the config.php file was regenerated. 6) Now proceed with the plugin installation, and get to the main moodle home. 7) Edit config.php to add the following line:   $CFG->alternative_cache_factory_class = 'tool_forcedcache_cache_factory' ; 8) Visit /admin/tool/forcedcache/index.php and confirm that forcedcaching is active and OK. This shows that an alternative cache factory is in use.   9) Delete the muc/config.php file. 10) Bump version.php up 1 increment, to trigger an upgrade, and click through the upgrade until you reach the 'Server Checks' page. 11) Confirm that the config.php file hasn't been regenerated. This is a non-cached page, so this hits the code path in which the disabled writer is active. 12) As a final confirmation, edit the /admin/tool/forcedcache/classes/cache_factory.php file and add the following line at the start of the get_disabled_writer function:   die(); 13) Reload the page and confirm it dies and you see nothing. This confirms the alternate writer is being loaded and applied in disabled situations.      

      Internally we've rolled out a forced cache configuration via MDL-41492 but despite this we are still seeing some weirdness which smells very similar to to the root cause of MDL-51111.

      Certain pages such as /admin/index.php?cache=0 set CACHE_DISABLE_ALL which means that the cache_factory_disabled() factory is used instead of the alternative class:

      https://github.com/moodle/moodle/blob/master/cache/classes/factory.php#L130-L145

      This means that the original sitedata/muc/config.php gets regenerated with fresh default config. This is probably not the end of the world but still causes some confusion when there is an expectation that this file should never exist anymore.

      So this is more of an interface design question:

      1) if you specify alternative_cache_factory_class should it completely manage all caches including those when caching is disabled and during php unit tests?

      2) or should we just accept the weirdness and move on?

       

       

        1. MDL-70233_Test Passed.png
          MDL-70233_Test Passed.png
          266 kB

            peterburnett Peter Burnett
            brendanheywood Brendan Heywood
            Brendan Heywood Brendan Heywood
            Andrew Lyons Andrew Lyons
            Gladys Basiana Gladys Basiana
            Votes:
            2 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 3 hours, 1 minute
                3h 1m

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.