Moodle
  1. Moodle
  2. MDL-40136

moving moodle dirroot causes cache to be corrupt.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.5.1
    • Component/s: Caching
    • Labels:
    • Testing Instructions:
      Hide

      set up a normal moodle site and make sure it's running

      Move your Moodle sites dirroot for example:

      $CFG->dirroot = '/home/sites/moodle';
      to
      $CFG->dirroot = '/home/sites/newmoodle';

      And make sure the old dirroot doesn't exist anymore - if you leave the old dirroot in place this test doesn't work correctly.

      (NOTE: dirroot isn't a required field in $CFG anymore as it is calculated automatically)
      load the homepage of your Moodle site - make sure it loads correctly.

      Show
      set up a normal moodle site and make sure it's running Move your Moodle sites dirroot for example: $CFG->dirroot = '/home/sites/moodle'; to $CFG->dirroot = '/home/sites/newmoodle'; And make sure the old dirroot doesn't exist anymore - if you leave the old dirroot in place this test doesn't work correctly. (NOTE: dirroot isn't a required field in $CFG anymore as it is calculated automatically) load the homepage of your Moodle site - make sure it loads correctly.
    • Workaround:
      Hide

      after changing dirroot - delete the cache dir in moodledata

      Show
      after changing dirroot - delete the cache dir in moodledata
    • Affected Branches:
      MOODLE_25_STABLE
    • Fixed Branches:
      MOODLE_25_STABLE
    • Pull 2.5 Branch:
      wip-MDL-40136-m25
    • Pull Master Branch:
      wip-MDL-40136-m26
    • Rank:
      50879

      Description

      if you move your Moodle site files (dirroot) to a different location this causes the site to fail like this:

      Coding error detected, it must be fixed by a programmer: Request for an unknown renderer class block_navigation_renderer 
       line 230 of \lib\outputfactories.php: coding_exception thrown
      line 1384 of \lib\outputlib.php: call to standard_renderer_factory->get_renderer()
      line 754 of \lib\pagelib.php: call to theme_config->get_renderer()
      line 208 of \blocks\navigation\block_navigation.php: call to moodle_page->get_renderer()
      line 292 of \blocks\moodleblock.class.php: call to block_navigation->get_content()
      line 238 of \blocks\moodleblock.class.php: call to block_base->formatted_contents()
      line 951 of \lib\blocklib.php: call to block_base->get_content_for_output()
      line 1003 of \lib\blocklib.php: call to block_manager->create_block_contents()
      line 353 of \lib\blocklib.php: call to block_manager->ensure_content_created()
      line 3 of \theme\base\layout\frontpage.php: call to block_manager->region_has_content()
      line 847 of \lib\outputrenderers.php: call to include()
      line 777 of \lib\outputrenderers.php: call to core_renderer->render_page_layout()
      line 99 of \index.php: call to core_renderer->header()
      

      this is because the cache returns the old dirroot instead of the correct new one.

      It would be nice if we could do some form of sanity check on the cache to see if $CFG->dirroot (which is correct after directory change) matches whatever is coming from the cache.

      This is also an issue as some deployment software (like MS Web Matrix) allow a user to package Moodle on their local system and then deploy to an external webserver taking both moodleweb and moodledata across to the external system.

        Activity

        Hide
        Sam Hemelryk added a comment -

        Hi Dan,

        Thanks for reporting this issue, I've reproduced it now and can confirm it as a bug.

        It is however not to do with the storage of dirroot, that CFG var is not stored in the cache.
        The problem appears to me to be with the plugin cache. It caches two sets of records, one contains plugin types mapped to the relative path of they belong to. The second maps plugin types to plugin directory and includes $CFG->dirroot.
        Its this that is causing the issue.

        I'll look to a solution now.

        Many thanks
        Sam

        Show
        Sam Hemelryk added a comment - Hi Dan, Thanks for reporting this issue, I've reproduced it now and can confirm it as a bug. It is however not to do with the storage of dirroot, that CFG var is not stored in the cache. The problem appears to me to be with the plugin cache. It caches two sets of records, one contains plugin types mapped to the relative path of they belong to. The second maps plugin types to plugin directory and includes $CFG->dirroot. Its this that is causing the issue. I'll look to a solution now. Many thanks Sam
        Hide
        Sam Hemelryk added a comment -

        Putting this up for peer-review now.
        I've added a couple of watchers who may have some interest in the changes here.

        Dan perhaps you would be able to test this for me as well and just check it resolves the issue for you.

        Many thanks
        Sam

        Show
        Sam Hemelryk added a comment - Putting this up for peer-review now. I've added a couple of watchers who may have some interest in the changes here. Dan perhaps you would be able to test this for me as well and just check it resolves the issue for you. Many thanks Sam
        Hide
        Dan Marsden added a comment -

        thanks Sam - that was quick! - yeah, I'd found the issue was with the plugin cache - wasn't very clear in my report there sorry!

        Show
        Dan Marsden added a comment - thanks Sam - that was quick! - yeah, I'd found the issue was with the plugin cache - wasn't very clear in my report there sorry!
        Hide
        Petr Škoda added a comment -

        hi, I have already used a similar trick in new classloading patch.

        Show
        Petr Škoda added a comment - hi, I have already used a similar trick in new classloading patch.
        Hide
        David Mudrak added a comment -

        Hey guys. Just to note, beside the pluginlist cache at https://github.com/samhemelryk/moodle/commit/wip-MDL-40136-m26#L0R8316, there are other plugin related caches - e.g. plugintypes, plugininfo related etc. Should they be covered by the $CFG->dirroot identifier too?

        Show
        David Mudrak added a comment - Hey guys. Just to note, beside the pluginlist cache at https://github.com/samhemelryk/moodle/commit/wip-MDL-40136-m26#L0R8316 , there are other plugin related caches - e.g. plugintypes, plugininfo related etc. Should they be covered by the $CFG->dirroot identifier too?
        Hide
        Sam Hemelryk added a comment -

        Thanks for checking that out guys.

        Hopefully your class loading will land this week Petr and replace the changes I am purposing here on master.

        I've reviewed the other plugin caches and only the two changed here require fixing.
        Putting this up for integration now.

        Many thanks
        Sam

        Show
        Sam Hemelryk added a comment - Thanks for checking that out guys. Hopefully your class loading will land this week Petr and replace the changes I am purposing here on master. I've reviewed the other plugin caches and only the two changed here require fixing. Putting this up for integration now. Many thanks Sam
        Hide
        Dan Poltawski added a comment -

        Integrated to master and 25 - thanks Sam

        Show
        Dan Poltawski added a comment - Integrated to master and 25 - thanks Sam
        Hide
        Petr Škoda added a comment -

        works for me, thanks

        master is using a different plugin acching code, it has similar dirroot change detection

        Show
        Petr Škoda added a comment - works for me, thanks master is using a different plugin acching code, it has similar dirroot change detection
        Hide
        Dan Poltawski added a comment -

        Thanks for your contributions!

        _main:
        @ BB#0:
                push    {r7, lr}
                mov     r7, sp
                sub     sp, #4
                movw    r0, :lower16:(L_.str-(LPC0_0+4))
                movt    r0, :upper16:(L_.str-(LPC0_0+4))
        LPC0_0:
                add     r0, pc
                bl      _printf
                movs    r1, #0
                movt    r1, #0
                str     r0, [sp]                @ 4-byte Spill
                mov     r0, r1
                add     sp, #4
                pop     {r7, pc}
        
                .section        __TEXT,__cstring,cstring_literals
        L_.str:                                 @ @.str
                .asciz   "This code is now upstream!"
        
        Show
        Dan Poltawski added a comment - Thanks for your contributions! _main: @ BB#0: push {r7, lr} mov r7, sp sub sp, #4 movw r0, :lower16:(L_.str-(LPC0_0+4)) movt r0, :upper16:(L_.str-(LPC0_0+4)) LPC0_0: add r0, pc bl _printf movs r1, #0 movt r1, #0 str r0, [sp] @ 4- byte Spill mov r0, r1 add sp, #4 pop {r7, pc} .section __TEXT,__cstring,cstring_literals L_.str: @ @.str .asciz "This code is now upstream!"

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: