Moodle
  1. Moodle
  2. MDL-22725

admin/replace.php breaks serialised data

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Not a bug
    • Affects Version/s: 1.9.9, 2.0
    • Fix Version/s: None
    • Component/s: Administration
    • Labels:
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE
    • Rank:
      6069

      Description

      Serialised data breaks when using the migration approach documented by http://docs.moodle.org/en/Moodle_migration

      Either using /admin/replace.php or `sed` causes the issue.

      The severity of the issue depends on what string you are replacing. In PHP 5.1.6, if you edit serialised data and replace a string with one of different length without updating the s:<number>: value to the new length, it will throw a warning and return false. In PHP 5.2.10 it put up with the incorrect length and worked anyway.

      If the problem is effecting the course.modinfo field you can simply update mdl_course set modinfo='' to fix. The issue effected a third party block I was using (course_menu block) which used serialised data and contained a URL which I was replacing, causing the block to crash out and not display.

      I checked all core code for other uses of unserialise. There are some serialised fields stored in mnet as well as gradebook preferences which could break if they get tampered with.

      Thanks

        Issue Links

          Activity

          Hide
          Michael Blake added a comment -

          This issue has been reported to affect MP clients. Please give it priority.

          Show
          Michael Blake added a comment - This issue has been reported to affect MP clients. Please give it priority.
          Hide
          Petr Škoda added a comment -

          "Simple" solution is to use json encoding instead, unfortunately it would not be backwards compatible. There shoudl be some hook to allow block to recode the info - see html block for more info (please note the config processing in blocks is pretty hacky/buggy).

          Show
          Petr Škoda added a comment - "Simple" solution is to use json encoding instead, unfortunately it would not be backwards compatible. There shoudl be some hook to allow block to recode the info - see html block for more info (please note the config processing in blocks is pretty hacky/buggy).
          Hide
          Petr Škoda added a comment -

          From WCAG 2.0: http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-dis-audio.html

          Note: Playing audio automatically when landing on a page may affect a screen reader user's ability to find the mechanism to stop it because they navigate by listening and automatically started sounds might interfere with that navigation. Therefore, we discourage the practice of automatically starting sounds (especially if they last more than 3 seconds), and encourage that the sound be started by an action initiated by the user after they reach the page, rather than requiring that the sound be stopped by an action of the user after they land on the page.

          Show
          Petr Škoda added a comment - From WCAG 2.0: http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-dis-audio.html Note: Playing audio automatically when landing on a page may affect a screen reader user's ability to find the mechanism to stop it because they navigate by listening and automatically started sounds might interfere with that navigation. Therefore, we discourage the practice of automatically starting sounds (especially if they last more than 3 seconds), and encourage that the sound be started by an action initiated by the user after they reach the page, rather than requiring that the sound be stopped by an action of the user after they land on the page.
          Hide
          Michael de Raadt added a comment -

          I'm not sure if Petr's last comment is relevant to this issue. Perhaps it was meant for another issue.

          Now that our minimum PHP version is 5.3.x, I wonder if this issue is still a problem any more.

          Show
          Michael de Raadt added a comment - I'm not sure if Petr's last comment is relevant to this issue. Perhaps it was meant for another issue. Now that our minimum PHP version is 5.3.x, I wonder if this issue is still a problem any more.
          Hide
          Michael de Raadt added a comment -

          I'm closing this issue as, according to the report, it is not a problem with versions of PHP that are supported by current Moodle versions.

          Show
          Michael de Raadt added a comment - I'm closing this issue as, according to the report, it is not a problem with versions of PHP that are supported by current Moodle versions.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: