One of my main tasks as an administrator is ensuring the Moodle core code remains current. The ideal time for this is when the Moodle core team officially releases updates. A new update was announced today, prompting this update process.

Before installing this update, I’m taking inventory of any modifications made to the core Moodle code in my 2.2 installation, as I anticipate these changes will be overwritten during the upgrade to 2.3.

I’ve modified one of the core themes and am migrating those changes to a custom theme, “au,” which is a duplicate of the core “anomaly” theme. I also have a custom SQL reporting plugin that I believe will need reinstallation after the upgrade. Additionally, I adjusted the permissions of the “manager” core role, which I expect will revert to their defaults. It turned out the permission changes to the core role were not lost.

Changes expected to be lost during the core update:

1. Theme modifications
2. Custom plugin
3. Permissions (This was not the case; they migrated successfully)

The upgrade process, as outlined in the Moodle documentation, involves these steps:

1. Move the existing Moodle program files to a different location on the server.
2. Upload the new program files to the server.
3. Copy the ‘config.php’ file from the old Moodle directory to the new one.
4. Run the notification scripts.
5. Move any custom themes or plugin directories from the old Moodle directory to the new one.
6. Allow Moodle to perform plugin checks.

I downloaded the 30MB update package, which expanded to about 91MB after extraction. After renaming the current Moodle directory to “moodleOLD,” I copied the newly extracted Moodle directory to the server. This required closing any open browser windows or applications with active sessions to the Moodle instance. Once the new Moodle files were copied, I moved the ‘config.php’ file from the “moodleOLD” folder to the new Moodle directory. Upon accessing the site, I was prompted by the new Moodle version (build # …) to update the database, followed by server and plugin checks.

After logging in, I found two new settings in Moodle 2.2.3, which I configured. Notably, one setting allows using the course file name instead of the ID number in automated course backups.

Visually confirming the upgrade:

The notifications area indicated the updated version as Moodle 2.2.3 (build:20120514).

I encountered issues with the duplicated “anomaly” theme (renamed “au”) initially. Copying the theme, updating the version number, and refreshing triggered the plugin update process, which seemed normal. However, attempting to clear the theme cache or switch to a different theme resulted in errors. The error log reported a fatal PHP error about redeclaring a class. I was able to resolve this error, install the custom “au” theme, and re-add the original “anomaly” theme from the updated Moodle package. I then reinstalled my two custom plugins.

General steps for the next upgrade:

1. Enable maintenance mode.
2. Download and extract the Moodle update package to a network location.
3. Close any programs with active sessions to the Moodle instance.
4. Rename the Moodle directory (e.g., to “moodleOLD”).
5. Copy the extracted Moodle directory to the server’s web root.
6. Move the ‘config.php’ file from the old Moodle directory to the new one.
7. Start a new browser session and navigate to the Moodle site.
8. Allow the database and system updates to proceed.
9. Review and address any server checks or updates.
10. Review the plugin check results.
11. Migrate the custom “au” theme from the old to the new Moodle directory.
12. Update the version number in the “au” theme.
13. Refresh the page and proceed through the plugin update process.
14. Activate the “au” theme.
15. Migrate the “report\customsql” folder.
16. Update the “customsql” plugin version number.
17. Migrate the “block\student_manager” folder.
18. Update the “student_manager” plugin version number.
19. Copy the contents of the “local” folder from the old to the new Moodle directory.

I will need to reinstall the questionnaire module and expect the feedback module to retain its settings. Additionally, I have installed the checklist module and am curious if it, along with its settings, will persist through future upgrades. My understanding is that Moodle preserves plugins and their configurations during upgrades, and it is only direct modifications to the core code that are overwritten.