Prerequisites
New requirements in Totara 9.0:
- PHP version 5.5.9 now required (was 5.4.4 in Totara 2.9).
- PHP zlib and OPcache modules now recommended.
- MSSQL only: Database user requires additional permissions: 'ALTER SETTINGS(SERVER)'.
- MSSQL 2008 now required (was 2005 in Totara 2.6).
- Postgres 9.2 now required (was 9.1 in Totara 2.9).
- MySQL 5.5.31 now required (was 5.1.33 in Totara 2.6).
- MariaDB 5.5.31 now required (was 5.3.5 in Totara 2.6).
To upgrade to Totara 9.0 you must be on Totara 2.2.13 or later. If your version is earlier than 2.2.13 the upgrade will not run. Versions of Totara prior to 2.2 must first upgrade to 2.2 via Totara 1.1.17+, then to at least 2.2.13, before upgrading to 9.0. For more information see Upgrading from Moodle.
Upgrade process
- Log in as an administrator.
- Check the live logs to check if any users are currently using the site. The site will be offline while the upgrades are performed (Site administration > Reports > Live Logs).
- Enable maintenance mode in Totara (Site administration > Server > Maintenance Mode).
- Log out.
- Back up the Totara database.
- Back up the sitedata directory.
- Back up the Totara source code directory.
- Make a copy of your config.php and any plugins you have installed.
- Remove the old source code - delete everything!
Extract the new source code into the source code directory.
Do not copy the new code on top of the existing code folder.
- Copy your config.php and any third party plugins back into the source code directory.
Run the following command in your terminal, replacing www-data with your web users username.
sudo -u www-data php admin/cli/upgrade.php
- Review the information provided and confirm you want to continue.
Carefully check the output in the terminal and ensure no errors were encountered.
If you have encountered an error the site will need to be rolled back, the issue fixed, and then the upgrade attempted again.
- Log in as an administrator.
- Review and save changes to new settings (if any).
- Disable server maintenance mode.
- Congratulations, your site is now upgraded. Read CHANGELOG.php for details on what is new.
In 9.0 there is now added support for multiple jobs. During upgrade, all existing position assignments are converted to Job Assignments, for more information go to Upgrading and Using Job Assignments.
Considerations for upgrading
When upgrading there are many things to consider both from a technical and training perspective. It is important to ensure all elements of your system are technically compatible, including your theme and any customisations. You will also want to make sure any training materials, and indeed any trainers, are up-to-date with new features and improvements.
Changelogs
It is important to review the changelogs and make sure you understand what is changing. New features and improvements are likely to bring changes to interfaces, behaviour, and workflows. Our changelogs will help you identify which areas have changed, so you can then find information on new behaviours and workflows on this help site. This is important so that any internal training material you have can be updated and staff trainers can learn about what has changed.
You should also review any new administration settings, as new controls get added with every major release. These added controls may facilitate new functionality, improve security, or allow further customisation. Each setting should be reviewed so that you can check your Totara site configuration is current and understood.
System requirements may also change and although these will have no impact for those using the site, you will need review them to ensure they are met during deployment of the new release.
Themes
User experience (UX) changes will mean that you will need to review your theme. It is likely there will be new places that need to be styled to make them look a part of your site. This is because HTML structure, CSS classes, and Javascript changes have been made. New features also bring new interfaces.
Customisations
Our APIs can change significantly between major releases. We have a deprecation policy that ensures that all changes where possible are backwards compatible, and that customisations will continue to function in the short term. When backwards compatibility is being used developer debugging information will be printed out to inform you that customisations and plugins will need to be updated. It is important these changes are made as backwards compatibility is only maintained for a limited time (typically one major release).
Incompatible API changes are rare, but they do occur. If you have customisations using API that no longer functions you will be presented with a debugging notice and you'll find that your customisations don't function as they should.
Password salting & module security
Totara automatically generates and adds a different salt for each user. A site-wide variable for the salt is no longer required for new installations of 2.5 or greater.
Backward compatibility for site upgrades
If you are upgrading a site from 2.4 or below and you are already using a site-wide salt in your configuration file, you need to keep using it to ensure your existing users can still log in.
Each time a user logs in their password hash will be converted to the new scheme, but it may take a long time before all your users have logged in. Alternatively, if you would like to force all your users to use the new scheme you could force reset all passwords using bulk user actions.
