Updates
Introduction
Its night, you should be asleep but you’re not. All around the silence of the night deafens your senses. Feeling pale and with a slight cold sweat you’re worried. Is it because you forgot to put the cat out? The iron is still on and burning its way through your best work clothes? That tap washer that’s on the blink and you really should have called a plumber? No, its because you’ve not applied that last Moodle or plugin update, you’re worried about the no win situation. If you apply the update then could it break your system and have hoards of terrified and panicking educators at your door, but if you don’t then what then? Does the update have fixes that make that annoying glitch go away or even security related ones that the whole world now knows about?
Disclaimers
Moodle™ is a registered trademark of ‘Martin Dougiamas’ – moodle.com/trademarks.
Other names / logos can be trademarks of their respective owners. Please review their website for details.
I am independent from the organisations listed above and am in no way writing for or endorsed by them.
How to cope
Ok, firstly ‘Don’t panic’. Take a breath and be calm. Knowledge is power, so the first thing to do is to read what the update has. All good developers will publish a list of what has changed. This is your first task, to read and understand this. If you don’t understand, then ask the developer.
Now we know what the update is about, its time to work out if you really need it and if it fixes something you already know about. If you don’t need it then don’t upgrade! Follow the adage ‘If it ain’t broke then don’t fix it’. Upgrading takes time, has technical risk and you may need to re-educate your educators.
If you do need it then you need to be in a position to mitigate any technical risk or unintentional side effects. Developers are human, they make mistakes, they test, but they can’t test every scenario. Your installation could be different. Therefore the absolute best thing you can have is a test installation that is absolutely in as much as possible identical to your production system. Then if an update fails then you’ll not break a live system or panic and you’ll be in a position to contact the developer with time to sort things out.
Test installations
By having a test installation then you will have time to work through any issues with the developer and even better if you have ‘dummy users’ with ‘fake data’, possibly allow them access to see for themselves what the issue is.
If an update works well, then a test installation is a good place to learn and prepare material to educate your educators about the changes.
Timing
Like a lot of things in life with updates, timing is everything. Being able to schedule an update when the installation is being used the least and your educators have time to cope with the change (and learning about it) is critical. When that exact time is will depend on your circumstances.
Clearly some updates that are security critical will force your hand into undertaking the update sooner than you’d like.
The process
When updating it is always best to follow the official documentation and in conjunction with any plugin specific instructions that the developer may have published. For Moodle 3.6, you can find the documentation on docs.moodle.org/36/en/Upgrading – for your version of Moodle, just change the number in the URL.
You will often find contributed plugin specific information in a ‘Readme’ file that comes with it. Clearly you’ll need to download and extract the plugin in order to get the file. Or sometimes look for a ‘Source control URL’ listed on the plugin’s Moodle.org database entry, for example as shown on my ‘Foundation’ theme: moodle.org/plugins/theme_foundation. That will then take you to the code where you can find the ‘Readme’ file. Additionally there will also be a ‘Changes’ file that has information about what has changed between versions that can help you make a decision on whether to upgrade or not.
Generally though with contributed plugins, if you are performing the update manually and not via ‘Automatic updates deployment’ (docs.moodle.org/36/en/Automatic_updates_deployment) the best practice is to log in as an administrator, put the site in maintenance mode, make a backup of the plugin files, delete all of the plugin files in its folder, extract and put the new files back in the plugin folder (ensuring that you don’t have the plugin name folder within itself), go to site administration then notifications and run through the upgrade process, check everything is as expected, take the site out of maintenance mode.
Maturity
Each component of Moodle (that has a version.php file) can have a ‘Maturity’ indicated by the PHP ‘$plugin→maturity’ variable assignment in its version.php file (docs.moodle.org/dev/version.php). For plugins it should be in the same location as the ‘Changes’ and ‘Readme’ files. It can have a value of ‘MATURITY_ALPHA’, ‘MATURITY_BETA’, ‘MATURITY_RC’ or ‘MATURITY_STABLE’. It is a really good indicator about how the developer considers the state of the code to be. My own interpretation of these is:
- MATURITY_ALPHA – Alpha – Development only, can break at any time, functionality subject to change and only as a basis for the developer to create the next version.
- MATURITY_BETA – Beta – Code has been completed but only just finished, has been tested and but may contain unexpected bugs.
- MATURITY_RC – Release Candidate – Code has been completed and finished and the developer is confident that there are no bugs but their still could be.
- MATURITY_STABLE – Stable – Code has been tested, used by others and proven to be without bugs. However as with any software, unexpected bugs can still occur.
Test, test and test again
I cannot stress enough the importance of testing not only the new version of Moodle / contributed plugin, but your upgrade and backup / restore procedures. Prepare and plan for the worst! You need to be sure that you can get back to what you had as fast as possible in the eventuality of disaster. Having a ‘Test installation’ can help so much to prepare and ensure your procedures are correct and to test the upgrade more than once.
Conclusion
Updates are an inevitable consequence of running software in a connected world. They can bring both joy and sadness at the same time. But the key thing is not to get stressed but to plan and prepare. Then hopefully your updates will be fine.
- Moodle 4 Security – A Review – 16th April 2024
- A little bit #fab – 16th March 2024
- Static framework – 16th February 2024
Great post Gareth – so important for all administrators to take on board. I think there are variances too – for example I’ve never had a major issue with a WordPress plugin pdae (but I still image a WordPress site before updating), but certainly I’ve had issues with plugins for Moodle for example – not lately to be fair. But yes, the advice MUST always remain – test your upgrades before you upgrade. And this is doubly important when you are considering upgrading an Operating System on a server.