mahara-contributors team mailing list archive

[Aaron Wells <1614805@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

In Bug 1614298 there were some differences of behavior between the CLI
upgrader and the web upgrader, due to how they handled the out-of-
sequence installation of the module/webservices plugin. This plugin is
installed in the core lib/db/upgrade.php file, by a call to
plugin_upgrade(), in order to make sure it gets installed instead of
leaving it as an optional user-initiated installation.

The CLI upgrader operates by running "check_upgrades()" at the
beginning, which then looks at every component and plugin in Mahara to
see which ones need to be upgraded. The return data includes the
"installed" version number (retrieved from the database) and the "new"
version number (from the version.php files on the filesystem). It then
passes this data to "upgrade_mahara($data)", which loops over the array
and runs the installer for each component.

As a result, the webservices plugin was listed as needing upgrading, and
then it got installed during the "core" upgrade step by the call to
"upgrade_plugin()", and again by upgrade_mahara() when it looped through
the listed plugins needing installation. The version number passed to
the upgrade function by upgrade_mahara() was based on the initial call
to check_upgrades() at the start of the script, causing the same upgrade
block in the plugin's db/upgrade.php script to be executed twice.

The AJAX upgrader didn't have this problem, because it re-checks the
status of each plugin before running the upgrade function for that
plugin. First the parent script calls "check_plugins()" to find all the
plugins that need to be upgraded. Then it sends a request to
upgrade.json.php for each upgrade component. And then upgrade.json.php
calls check_plugins() again. It does this in order to retrieve the full
data about the plugin; but it has the side effect of preventing the
double-upgrading of plugins that were upgraded or installed out of order
by core.

It'd be best if both installation routes performed the same.

** Affects: mahara
     Importance: Medium
     Assignee: Aaron Wells (u-aaronw)
         Status: In Progress

** Affects: mahara/15.04
     Importance: Medium
     Assignee: Aaron Wells (u-aaronw)
         Status: In Progress

** Affects: mahara/15.10
     Importance: Medium
     Assignee: Aaron Wells (u-aaronw)
         Status: In Progress

** Affects: mahara/16.04
     Importance: Medium
     Assignee: Aaron Wells (u-aaronw)
         Status: In Progress

** Affects: mahara/16.10
     Importance: Medium
     Assignee: Aaron Wells (u-aaronw)
         Status: In Progress

** Also affects: mahara/16.10
   Importance: Undecided
       Status: New

** Also affects: mahara/16.04
   Importance: Undecided
       Status: New

** Also affects: mahara/15.04
   Importance: Undecided
       Status: New

** Also affects: mahara/15.10
   Importance: Undecided
       Status: New

** Changed in: mahara/16.10
    Milestone: None => 16.10.0

** Changed in: mahara/16.04
    Milestone: None => 16.04.4

** Changed in: mahara/15.10
    Milestone: None => 15.10.6

** Changed in: mahara/15.04
    Milestone: None => 15.04.10

** Changed in: mahara/15.04
     Assignee: (unassigned) => Aaron Wells (u-aaronw)

** Changed in: mahara/15.10
     Assignee: (unassigned) => Aaron Wells (u-aaronw)

** Changed in: mahara/16.04
     Assignee: (unassigned) => Aaron Wells (u-aaronw)

** Changed in: mahara/16.10
     Assignee: (unassigned) => Aaron Wells (u-aaronw)

** Changed in: mahara/16.10
   Importance: Undecided => Medium

** Changed in: mahara/16.04
   Importance: Undecided => Medium

** Changed in: mahara/15.10
   Importance: Undecided => Medium

** Changed in: mahara/15.04
   Importance: Undecided => Medium

** Changed in: mahara/16.10
       Status: New => In Progress

** Changed in: mahara/16.04
       Status: New => In Progress

** Changed in: mahara/15.10
       Status: New => In Progress

** Changed in: mahara/15.04
       Status: New => In Progress

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1614805

Title:
  Make out-of-sequence plugin upgrades consistent in CLI upgrader & web
  upgrader

Status in Mahara:
  In Progress
Status in Mahara 15.04 series:
  In Progress
Status in Mahara 15.10 series:
  In Progress
Status in Mahara 16.04 series:
  In Progress
Status in Mahara 16.10 series:
  In Progress

Bug description:
  In Bug 1614298 there were some differences of behavior between the CLI
  upgrader and the web upgrader, due to how they handled the out-of-
  sequence installation of the module/webservices plugin. This plugin is
  installed in the core lib/db/upgrade.php file, by a call to
  plugin_upgrade(), in order to make sure it gets installed instead of
  leaving it as an optional user-initiated installation.

  The CLI upgrader operates by running "check_upgrades()" at the
  beginning, which then looks at every component and plugin in Mahara to
  see which ones need to be upgraded. The return data includes the
  "installed" version number (retrieved from the database) and the "new"
  version number (from the version.php files on the filesystem). It then
  passes this data to "upgrade_mahara($data)", which loops over the
  array and runs the installer for each component.

  As a result, the webservices plugin was listed as needing upgrading,
  and then it got installed during the "core" upgrade step by the call
  to "upgrade_plugin()", and again by upgrade_mahara() when it looped
  through the listed plugins needing installation. The version number
  passed to the upgrade function by upgrade_mahara() was based on the
  initial call to check_upgrades() at the start of the script, causing
  the same upgrade block in the plugin's db/upgrade.php script to be
  executed twice.

  The AJAX upgrader didn't have this problem, because it re-checks the
  status of each plugin before running the upgrade function for that
  plugin. First the parent script calls "check_plugins()" to find all
  the plugins that need to be upgraded. Then it sends a request to
  upgrade.json.php for each upgrade component. And then upgrade.json.php
  calls check_plugins() again. It does this in order to retrieve the
  full data about the plugin; but it has the side effect of preventing
  the double-upgrading of plugins that were upgraded or installed out of
  order by core.

  It'd be best if both installation routes performed the same.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1614805/+subscriptions