19 October 2013, 5:45

Hi All,

We're looking for input from other places using customizations in Mahara.  We'd appreciate hearing how you handle your upgrades and if you have any suggestions for our programmers.

Many thanks,

Beth (Pace University)

22 October 2013, 21:25

Hi Beth,

I don't have any experience with upgrading a mahara with customizations yet, but here's what I would/will do:

1) Make a list of all customizations, explicitly changes in core-files that will be overwritten and copied pages that are reached by redirections, like in the menu_items-methods (should ideally be startet with the installation and kept up to date whenever customizations are made)

2) Copy the installation into a new and up-to-date Mahara-installation, that is, copy the plugins and themes into a fresh installation, copy database and dataroot-files, change path to file-directory and database-access in the fresh installed config.php and change the wwwroot-entry in the config-table of the database-copy to the temporary test-url

3) Redo all changes in core-files that you recorded earlier - and run a quick test

4) Check the copied pages for changes you have to propagate. That can be a bit tricky, maybe it helps if you download an original version of that file and run a diff with the new file. 

5) Test the complete copied installation with focus on the pages/plugins you changed, everything you usually use and everything you can image that is influenced by your customizations

6) When everything works, perform the update: make another copy of your recent mahara-installation (including database and dataroot), overwrite the installation with your testinstallation - exept the config.php - and check that it works

24 October 2013, 23:09

Hello Beth,

I might have already asked this once, but can't remember the answer: Do your developers use Git? It certainly makes upgrading easier

• as you have the entire history of the code and changes in individual commits and can thus backtrack things (as long as everything is committed properly of course ;-) )
• because git already tells you where there are so called merge conflicts making it easier to resolve any issues

Cheers

Kristina

25 October 2013, 12:51

Here at Catalyst IT we use git to keep track of our code, and it also helps a lot with merging upgrades. (The downside is that git has a pretty steep learning curve, so it usually requires new devs to take a training session or two before they're really handy with it.) The general procedure is something like this:

When you're first bringing a new site into git:

1. You clone the Mahara git repo from gitorious -- https://gitorious.org/mahara/mahara/

2. Create a branch based off of whichever version the site is using (i.e. "git checkout -b 1.7.2_RELEASE")

3. Add your existing customizations to that branch as a series of commits.

Then, to do a minor upgrade (i.e. 1.7.2 -> 1.7.3), you can just merge in the tag for that release (git merge 1.7.3_RELEASE), manually merging any conflicts you run up against.

To merge in a major upgrade (i.e. 1.7 -> 1.8) can be harder, because the stable branches receive copies of a lot of the same patches, which tends to confuse git and create a lot of merge conflicts.  So, I use the method described here to deal with major upgrades: https://moodle.org/mod/forum/discuss.php?d=191774#p834646

If you're not using git (or some other version tracking system that you could maybe export the git repo into), perhaps the most helpful thing you can do to make upgrades easier is to try as much as possible to squeeze all your customizations into new plugins and/or the /local directory.

Cheers,

Aaron