Upgrade to 15.10 fails for sites that have upgraded Mahara by copying over their existing installation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mahara |
Won't Fix
|
Medium
|
Aaron Wells | ||
15.10 |
Won't Fix
|
Medium
|
Aaron Wells | ||
16.04 |
Won't Fix
|
Medium
|
Aaron Wells |
Bug Description
I've now encountered two users on the support forums who had issues upgrading because they had copied over their existing Mahara site, and now have duplicate methods defined in the (old) multirecipient artefact plugin and the (new) multirecipient module plugin:
https:/
https:/
This was caused because in Bug 1468156, we refactored this plugin from an artefact to a module. Apparently some users upgrade their sites through this process:
1. Download & unzip the new release
2. Copy the release into their existing Mahara webroot
3. When prompted, replace existing files in the webroot with new versions from the zip.
The problem is this leaves the old files in place. Thus far, this approach has not caused any crashes, though I imagine it might lead to some strange behaviors, like possibly extra CSS files getting loaded, and the redundant ContactInfo block still being around. But the multirecipient module is perhaps the first case of us moving a library file from one location to another, and that results in the user having two library files that define some methods with the same name, and that causes a fatal PHP error.
Since this has been common enough to come up twice in the forum, it would probably be a good idea to address it somehow.
Changed in mahara: | |
status: | Fix Committed → Won't Fix |
Filed a related bug 1519519 for the idea of putting in a sanity check to warn users off of this practice.
In the meantime, I think I'm just going to tackle this with this approach:
1. Make sure our official upgrade documentation is not telling people to upgrade by copying over their existing installation.
2. Rename the methods in the multiplerecipie ntnotification module so that they don't conflict with the names of the methods in the old artefact.
I think if I do #2 above, then there probably won't be any problems caused by the old artefact. The files will be there, and they'll still be loaded whenever you load up an artefact, but we won't actually use them for anything.
Though I will have to check and make sure that the artefact doesn't have any crons or event handlers that might be getting triggered as well.