In a recent Moodle community forum thread, an administrator upgrading a Moodle 4.5 site to 5.0 on a staging copy watched the upgrade stop with an error. The site’s analytics setting still pointed at the PHP machine learning backend, which Moodle 5.0 removed. Nothing on that site used the component day to day, yet one stored setting still depended on it. Because it failed on a copy, no member was affected, and that rehearsal is where associations prevent Moodle 5.0 upgrade dependency errors before members see them.
An association’s Moodle site usually carries more of these than anyone remembers. Some sit in settings nobody has opened in years; others sit in continuing education (CE) courses that last ran several renewal cycles ago. The work is to find them before the upgrade and give each one a named decision.
I recently migrated my site to Mindfield from another host, and the experience couldn’t have been better. Mindfield kept working until they were certain that my site was operating as well as it was before, and they even helped clean up a few issues to improve my site’s performance – issues my prior host never mentioned. I also found Mindfield’s communication to be excellent. Before the migration, they prepared me for what to expect, and during the migration they kept me well-informed.
Jim Benedek
review Source: Google Reviews
Outline
- Why a Dependency Error on a Test Copy is the Good Outcome
- Components Moodle 5.0 Removed and Their Association Dependencies
- Third-Party Plugins Not Ready for Moodle 5.0
- Issues Other Sites Hit Upgrading to Moodle 5.0
- Who Decides What Happens to Each Dependency
- What “Ready to Upgrade” Looks Like
- Strategic Moodle Upgrade Management
- Frequently Asked Questions (FAQs)
Why a Dependency Error on a Test Copy is the Good Outcome
An upgrade that stops on a test copy with a dependency error is actually a positive outcome. This scenario indicates that the rehearsal caught a critical issue before it could impact live members. A stopped upgrade on a copy costs a day.
The Cost of Unforeseen Live Site Failures
The same dependency error, if discovered on the live site, carries a much higher cost. It can block member access during a renewal period, which is exactly when members need the site most.
Missed dependencies can manifest in several ways for members:
- Sign-in Issues: Members may be unable to access their accounts.
- Missing Course Activities: Essential learning components might disappear from courses.
- Certificate Non-Issuance: Members cannot receive their earned CE certificates.
- Content Editing Problems: Staff may face difficulties editing course materials as before.
Components Moodle 5.0 Removed and Their Association Dependencies
Moodle 5.0 removed several components outright. The Atto editor and Central Authentication Service (CAS) sign-in remain available separately, maintained outside Moodle core; the others are gone.
However, a dependency is not only something the association actively uses. It can be a stored setting, an older CE course that still contains a removed activity, or member accounts set to an authentication method.
Where Dependencies Hide
Each removed component maps to something an association may still rely on, and each one needs a decision before the upgrade starts:
| Removed in Moodle 5.0 | What at an association may still depend on it | Decision to make before upgrading |
|---|---|---|
| CAS authentication | Member accounts that sign in through CAS | Keep the separately maintained CAS plugin, or move those accounts to another sign-in method before the upgrade. Review single sign-on (SSO) for Moodle options. |
| Atto editor | Staff who edit course content with it | Move editing to the current default editor, or keep the separately maintained Atto plugin. |
| Chat and Survey activities | Older CE courses that still contain them, and the participation they hold | Decide what is kept, exported, or retired first. This impacts continuing education management in Moodle. |
| MNet plugins | Any link to another Moodle site through it | Confirm nothing uses it and remove any related configurations. |
| PHP machine learning backend | Analytics settings still pointing at it | The setting has to change before the upgrade. Moodle 5.0 now defaults to a Python backend for analytics. |
Most associations reaching this point are coming from Moodle 4.5, a long-term support (LTS) release. The Moodle 4.5 LTS review covers that starting point, and which version to land on is settled separately in latest Moodle vs Moodle LTS.
Third-Party Plugins Not Ready for Moodle 5.0
Moodle’s upgrade process includes a comprehensive check of all installed plugins. Each plugin declares the Moodle versions it supports and any other plugins it requires. If Moodle identifies a plugin whose dependencies are missing or incompatible with the target version, the upgrade will halt. On a copy, that stop is useful: it names the plugin before members ever see it.
Auditing Existing Plugins
An association’s Moodle site often accumulates plugins over time. Some might have been added years ago for a single course or event and are no longer actively used. However, these unused plugins can still pose a risk during an upgrade if they are not compatible with Moodle 5.0.
That is why the plugin list gets reviewed before the upgrade, which is the same discipline as ongoing Moodle plugin cleanup strategies.
Criticality of Certificate Plugins
Moodle core ships no certificate activity, so certificates come from plugins. If a certificate plugin is not ready for Moodle 5.0, it poses a direct and significant risk to members’ ability to receive their earned CE certificates. Consequently, this makes certificate plugins a top priority during the audit. Associations should review their Moodle certificate plugins carefully.
For each third-party plugin, a clear decision must be made:
- Needed and Ready: The plugin is essential for operations and its maintainer has confirmed compatibility with Moodle 5.0.
- Needed but Waiting: The plugin is crucial, but its maintainer has not yet released a Moodle 5.0 compatible version. In this case, the upgrade may need to be postponed, or an alternative solution found.
- No Longer Needed: The plugin is obsolete or serves no current purpose. These plugins should be removed from the site before the upgrade to eliminate potential dependency conflicts.
Issues Other Sites Hit Upgrading to Moodle 5.0
Administrators who upgraded early have already reported where 5.0 bites. Each item below comes from a public forum thread or Moodle’s own upgrade notes. Most surfaced on a staging copy, which is exactly why the rehearsal matters.
These are the issues that keep coming up:
- Analytics still pointing at a removed backend: Upgrades and admin pages failed with a “class not found” error for the PHP machine learning backend. The lasting fix in that forum thread was changing the analytics setting, or switching analytics off, before upgrading.
- Question banks that look empty: Moodle 5.0 moves question banks into a new structure through background tasks. On one site an outdated third-party question type broke that task, and every bank looked empty until it was patched (forum thread). Moodle fixed a related bug in 5.0.2.
- A migration error that forced a rollback: Another administrator hit a database error in the same question bank task. They rolled back to 4.5 and chose to wait for a later release (forum thread).
- A database that no longer qualifies: Moodle 5.0 needs MySQL 8.4 or MariaDB 10.11, so MySQL 8.0 sites cannot upgrade in place. In the same thread, meeting that meant rebuilding the server first. The full list is in the Moodle 5.0 release notes.
- CAS members with no way in: With CAS out of core, the only CAS add-on in the plugins directory would not install, because it depended on the removed plugin. One university reported about 9,000 accounts behind that block. Admins restored sign-in with the separately maintained CAS plugin (forum thread).
- Atto that would not reinstall: Sites keeping the Atto editor found the reinstall failed until the plugin was packaged exactly as Moodle expects. Moodle’s upgrade notes also advise deleting an outdated plugin’s code rather than uninstalling it, so its data survives.
- Custom themes that will not compile: Moodle 5.0 is the first release on Bootstrap 5. The popular Boost Union theme had to drop a style variable that stopped its styles compiling, per its changelog. A custom or child theme needs the same check on the copy.
None of these is exotic. Each is a dependency on something 5.0 changed, and each is far cheaper to find on a copy than on the live site during renewals.
Who Decides What Happens to Each Dependency
While the technical team or upgrade provider can identify dependencies, the decisions about what happens to each one should not be made in isolation. These decisions impact member services and educational offerings. So the people who know which courses and member journeys rely on each item make the call.
Defining Roles and Responsibilities
Clear roles ensure that decisions are informed by both technical feasibility and organizational priorities. Furthermore, this also establishes accountability. An agreed-upon plan helps to manage expectations and streamline the upgrade process effectively.
The decision-making process typically involves several key roles:
- Upgrade Provider: This individual or team, often a host, partner, or contractor, is responsible for producing a comprehensive list of all removed components, stored settings, and third-party plugins the site still depends on. They provide the technical insights.
- Education or CE Lead: This person understands which courses, programs, and member journeys rely on specific Moodle functionalities. They decide for each dependency whether it should be kept, replaced with a Moodle 5.0 compatible alternative, or retired because it is no longer relevant.
- Accountable Executive: A senior leader must approve the final dependency list and the proposed actions. This executive gives the go or no-go for the upgrade. They also confirm the plan for any necessary fallback.
Establishing a Rollback Strategy
Before any upgrade, it is critical to settle who has the authority to call for a rollback. This person should also ensure that a pre-upgrade copy of the site remains untouched. This untouched copy serves as the definitive rollback position.
This strategy is a crucial part of emergency backup and migration strategies for Moodle. Additionally, access to robust Moodle support options can also be invaluable during this planning phase.
What “Ready to Upgrade” Looks Like
A Moodle site is truly ready for a 5.0 upgrade when several conditions are met. These conditions move beyond mere technical checks, focusing on the real-world experience of members and staff. The test is whether members can still do what they came to do.
Successful Rehearsal and Member Journey Validation
The primary indicator of readiness is a complete rehearsal on a full copy of the site. This rehearsal must conclude with no dependency errors. Furthermore, every item on the pre-upgrade dependency list must have a clear decision and an assigned owner.
Crucially, readiness also means that the core member journeys work flawlessly on the upgraded copy. This includes:
- Signing In: Members can log in without issues.
- Enrolling in Courses: The enrolment process for CE courses functions correctly.
- Completing CE Courses: All activities within a course behave as expected.
- Receiving Certificates: The system successfully issues certificates upon course completion.
A simple login test only proves the site is up. It does not confirm that members can complete a course or receive their certificate. Therefore, comprehensive testing, including scenario-based validation, is essential.
This can be significantly enhanced through automated testing strategies for Moodle upgrades. Should issues arise during testing, a clear strategy for fixing Moodle upgrade issues must be in place.
Strategic Moodle Upgrade Management
Mindfield runs Moodle upgrades for professional associations, starting with a dependency audit of removed components, stored settings and third-party plugins. We rehearse the upgrade on a full copy of the site, so a dependency error stops a test run instead of a renewal period. Before go-live we test the member journeys that matter: signing in, enrolling, completing a CE course and receiving the certificate. If your association is planning a move to Moodle 5.x, talk to us about the audit first.
Frequently Asked Questions (FAQs)
This article may contain conceptual illustrations to help support the article content.
