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

alternative_cache_factory_class isn't honored when caching is disabled

    XMLWordPrintable

Details

    • MOODLE_310_STABLE
    • MOODLE_310_STABLE, MOODLE_311_STABLE
    • MDL-70233-alternative-disabled-cache-311
    • 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.      

    Description

      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?

       

       

      Attachments

        Issue Links

          Activity

            People

              peterburnett Peter Burnett
              brendanheywood Brendan Heywood
              Brendan Heywood Brendan Heywood
              Andrew Lyons Andrew Lyons
              Gladys Basiana Gladys Basiana
              Matteo Scaramuccia, David Woloszyn, Huong Nguyen, Jake Dallimore, Michael Hawkins, Stevani Andolo
              Votes:
              2 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                12/Jul/21

                Time Tracking

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