Moodle Services

Start here: match your situation to the work

A symptom is easier to name than a service. Find the row that sounds like your week, then read that section.

Moodle setup and launch

A first install is mostly decisions, not commands. The release line you start on decides how long you can sit still. Moodle 5.2 shipped on 20 April 2026, with general bug fixes to 19 April 2027 and security fixes to 4 October 2027. Moodle 5.3 is the next long term support release, dated 5 October 2026 and carrying security fixes to 1 October 2029. If you intend to leave the site largely alone for two years, starting on the LTS line is usually the right call.

The build covers the stack, the site and the first courses: a LAMP or LEMP server sized for your concurrency, 64-bit PHP 8.3 or 8.4 with the sodium extension present and max_input_vars raised to at least 5000, TLS, a moodledata directory outside the web root, tested backups, and SMTP that reaches Outlook and Gmail rather than the spam folder.

One structural point trips up anyone whose last install was on 4.x. Since Moodle 5.1 the web-facing code lives in a public subdirectory, so your virtual host document root must point at /path/to/moodle/public and not at /path/to/moodle. Moodle enforces it rather than degrading quietly: the index.php left behind in the project root exists only to throw a rootdirpublic error if you aim the web server at the wrong level. config.php, moodledata and the CLI scripts all sit outside public on purpose.

Cron is easy to leave off a self-installed site, and Moodle wants it every minute. Note that the restructure did not move the command line tools — they are still at admin/cli in the project root, not under public:

* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null

Install that as the web server user rather than as root — crontab -u www-data -e on Debian and Ubuntu — so scheduled runs do not scatter root-owned files through moodledata that the web server then cannot write to.

Then the decisions that are cheap to make now and expensive to retrofit: authentication, enrolment flow, roles and capabilities that match how your organisation works, and a category structure that still makes sense at 300 courses.

Upgrades and version migration

Upgrade work arrives in two shapes: years behind and nervous, or one version behind and blocked by a plugin. The second is where the risk sits, because the fragile part of an upgrade is third party code rather than core.

Two facts shape every plan. There is a floor on where you can jump from — Moodle 5.1 upgrades directly from 4.2.3 or later, and 5.2 from 4.4 or later — so an older site needs a staged hop through an intermediate release before it can reach the current line. And platform requirements move with the version, so an upgrade is frequently a server project wearing a Moodle costume.

Each row is that version's own floor, not a general rule: 4.5 will run on PostgreSQL 13, 5.2 will not. Oracle is the one to check for separately, because it stopped being a supported database from Moodle 5.0, so an Oracle-backed site has a database migration standing in front of everything else.

Read the 4.5 row carefully, because its label flatters it. LTS is a real designation, but 4.5's general support ended on 6 October 2025 and it now receives security fixes only, until 4 October 2027 — the same day 5.2's security support ends. Staying on 4.5 buys planning time, not extra runway. If you want to move once and then stop thinking about it, the target is 5.3, from 5 October 2026.

The directory restructure is the part that catches people coming from 4.5. Because Moodle 5.1 moved everything web-accessible into public, a 4.5 to 5.1 or 5.2 upgrade is not just a code swap: the document root has to be repointed, and every contributed or custom plugin you carry across has to be placed in the new tree rather than where it used to live. Budget web server configuration time into the maintenance window. This is the step that turns a code swap into an afternoon of server work when nobody has planned for it.

The method never changes: clone production to staging, upgrade there, record what breaks, fix it, then repeat against live inside a window with a restore path ready. On the day it looks like this, run as the web server user — admin/cli/upgrade.php says as much in its own help text.

php admin/cli/maintenance.php --enable
php admin/cli/uninstall_plugins.php --show-all
php admin/cli/upgrade.php --non-interactive
php admin/cli/check_database_schema.php
php admin/cli/checks.php --type=security -v
php admin/cli/purge_caches.php
php admin/cli/maintenance.php --disable

Nothing in that sequence stops to ask a question, which is the point when the window is short. The --non-interactive flag is what keeps the upgrade from sitting on a yes/no confirmation until somebody notices, and --show-all only lists the plugin inventory rather than removing anything, so it is safe to run first and read.

How plugin compatibility gets audited before anything is scheduled is set out on the Moodle upgrade service page.

Server and platform migration

Moving Moodle means moving three things together: the code directory, the moodledata filestore and the database. Break the relationship between them and you get a site that loads but has lost every uploaded file — worse than one that does not load at all.

MoodleCloud to self-managed hosting is one of the migrations I have done, onto AWS. MoodleCloud does offer a site export of the database and files from your portal, though the site goes into maintenance mode while the export runs and a large database can take hours, and migration assistance is not part of the subscription. Where an export cannot be used, course backups restored individually are the fallback, with users, cohorts and grade history handled separately. On a job of this shape the work that decides the outcome is the unglamorous part: a rehearsal on the target server before anyone commits to a date, a URL rewrite pass, fresh cron, mail deliverability retested from the new IP address, and DNS TTL lowered in advance so a rollback takes minutes rather than a day.

IOMAD multi-tenant LMS

If you sell training to companies, run franchises, or serve departments that must not see each other's learners, one plain Moodle with clever categories will eventually fail you. IOMAD is the open source route to real tenancy: separate companies with their own branding and domains, delegated company administrators, licence based enrolment and tenant-scoped reporting.

IOMAD's documented target is a release three months after each Moodle release, and the published record runs wider than that. IOMAD 4.5 arrived in February 2025 against Moodle 4.5 in October 2024; IOMAD 5.0 in July 2025 against Moodle 5.0 in April 2025; IOMAD 5.1 in March 2026 against Moodle 5.1 in October 2025. Three to five months, in other words, and a build for the newest Moodle release is not guaranteed to exist on the day you want it — so check the IOMAD releases page for your intended Moodle target before you commit to it, not after. IOMAD 4.5, released in February 2025, is marked long term support, which is the line to choose if you would rather move rarely. That cadence, not core Moodle's, sets your upgrade pace.

The commercial alternative, Moodle Workplace, is licensed software available only through Moodle Premium Certified Partners and Service Providers — a standard Certified Partner is not authorised to sell or implement it either. Hooknot Digital is not a Moodle Partner of any tier and does not resell Workplace. Start with how multi-tenancy on IOMAD works, or the head-to-head in IOMAD versus Moodle Workplace.

Custom Moodle plugin development

The first question is whether you need a plugin at all. Plenty of requirements are already met by a core setting, a maintained plugin from the plugins directory, or a change to roles and capabilities, and I will say so before quoting build work.

When a plugin genuinely is the answer, it gets built the way Moodle expects: correct plugin type and frankenstyle name, version.php with real dependencies, schema changes through install.xml and the plugin's own upgrade.php rather than raw SQL, capabilities in access.php, strings externalised, scheduled tasks registered through the task API, and a privacy provider so your site stays reportable under GDPR. That discipline is what lets a plugin survive your next upgrade instead of becoming the thing that blocks it.

Six plugins are in development here — Engagement Mailer, Flexi Enrol Dates, Admin Insights Dashboard, Learner Timeline Dashboard, Moodle LEMP Auto-Installer and Moodle Completion Doctor. None of them is released, so nothing described above depends on them.

Custom reports and SQL

Moodle has had a drag-and-drop report builder in core since 4.0, and for many requests that is the correct tool — no code, exports to CSV, XLSX and PDF, schedulable to an audience. I build there first.

What gets escalated is the reporting report builder cannot express: cross-tenant licence consumption, quiz attempt behaviour, activity-level engagement over time, compliance windows depending on dates in three tables. That work runs through the Ad-hoc database queries plugin (report_customsql), which executes one query on a schedule and emails or publishes the result, so your operations team gets a Monday morning CSV instead of a standing request to you. Heavy queries run off-peak, and every query uses Moodle's {tablename} placeholder syntax rather than a hardcoded prefix, so the report survives being moved to another site.

One caveat if you are heading for the newest core: the plugins directory entry for report_customsql lists support up to Moodle 5.1 and carries no 5.2 badge, so on a 5.2 site read its current version badge first and prove it on staging before anyone builds a reporting routine around it.

WordPress and Moodle integration with SSO

The usual shape: WordPress is the marketing site and the checkout, Moodle is the classroom, and a customer who has just paid is asked to create a second account. Every extra account to create is a place to lose someone who has already handed over money.

There is no single correct integration, and the direction of trust matters more than the protocol name. Moodle core's OAuth 2 support makes Moodle the client: auth_oauth2 and the OAuth 2 services page consume an external issuer — Google, Microsoft, Nextcloud, or a custom one you configure by hand. So if an external identity provider already owns your logins, or WordPress fronts one, that is a core-only job with no contributed code involved. Making Moodle itself the identity provider is the other direction, and core cannot do it; that needs a contributed OAuth 2 server plugin such as local_oauth2, which is a heavier commitment and one more dependency to carry through every upgrade.

Where course content must appear inside another platform, Moodle's enrol_lti “Publish as LTI tool” plugin paired with the LTI authentication plugin admits learners without a second login, and LTI 1.3 Advantage adds deep linking, grade passback and roster sync.

Where the flow is commercial, the real subject is usually not the login at all but the purchase event: payment confirmed in WordPress, enrolment created in Moodle, welcome mail sent once, and one agreed answer for what happens on a refund. I have built a WordPress and Moodle integration with single sign-on, and I will map these options against your stack rather than reaching for whichever one I built last.

Rescue and emergency support

Broken Moodles fail in a small number of ways. An upgrade stopped halfway. A plugin was deleted from disk while still installed. PHP was bumped underneath a Moodle that cannot run on it. A disk filled, or the database ran out of connections under load.

Rescue starts with evidence: a snapshot before anything is touched, then error logs, config.php, disk and database state read in order. Recovery is usually one of a few routes — finishing a stalled upgrade from the CLI, restoring missing plugin code so an uninstall can complete cleanly, correcting a schema mismatch that check_database_schema.php exposes, or rolling back to the snapshot.

One detail worth knowing before you need it: if the database is unreachable, the usual CLI route into maintenance mode is unavailable too, because it writes a setting to the database. Creating a climaintenance.html file inside moodledata by hand puts the site behind a holding page with no database involved, which is a gentler way to stop traffic than pulling the virtual host. Afterwards you get a written account of what happened, so the same failure does not return next quarter.

Custom theme and front-end work

Most theme requests are not a new theme. They are a child theme of Boost, or configuration of a mature parent such as Boost Union, which lists support for Moodle 4.0 through 5.2 and gives you extra block regions, login page control and branding without touching template code. Moodle 5.2 redesigned the login and multi-factor authentication pages, exactly the sort of change that quietly undoes bespoke CSS on upgrade day. I have built a Moodle training site on a commercial theme, so I will also say plainly when buying a premium theme is the cheaper path. What I avoid is unmanaged CSS pasted into site settings, invisible to whoever inherits the site.

Ongoing maintenance

Moodle ships point releases on a roughly two-month cycle, and an unpatched LMS holds real personal data about real learners. Maintenance is the least glamorous service here and the one that prevents most of the rescue work above.

• Point releases applied on your current line, staged before live
• Plugin updates, and removal of abandoned plugins before they block an upgrade
• Backups verified by restoring them, not by confirming a file exists
• Health checks run across all three check types, because the CLI tool defaults to status only: php admin/cli/checks.php -v, then php admin/cli/checks.php --type=security -v and php admin/cli/checks.php --type=performance -v
• Cron and scheduled task health, including stuck ad-hoc tasks
• Database growth, log trimming and file storage review, with a short written note each cycle

Training and consulting

Sometimes the answer is not a project. Two hours with whoever administers your Moodle — roles and capabilities, gradebook, backup strategy, reading your own logs — removes more future cost than a month of billed work. Consulting also covers the decisions before a build: LTS or current release, IOMAD or separate sites, hosting sizing, whether the reporting you want justifies a plugin.

How an engagement runs

1. Audit. Read the actual site before promising anything: version, plugin inventory, server, database, backups, logs. Findings in writing, whether or not the project proceeds.
2. Stage. Nothing risky is proven on production. A staging copy carries the upgrade, migration or plugin first.
3. Ship. An agreed window, a rollback path in place before the first command runs, a checklist worked in order.
4. Improve. A settling period after go-live, then the follow-up work the audit flagged but the launch did not need.

You work with one person throughout. Hooknot Digital is a one-person studio, so there is no account manager relaying your problem, and it also means a limited number of projects at a time. More on how I work, with examples under recent work, and public reviews on my Fiverr profile.

How to start

Send three things: the Moodle version you are on, the hosting you are on, and one sentence describing what is going wrong. That is usually enough to tell you whether this is a two hour job or a two week one. Email rgrover@hooknot.com or use the contact page. If talking is easier, book the free thirty minute Moodle session and bring your site URL — admin credentials only once we have agreed to work together, never in a first email. I reply personally, usually within a working day; that is a habit, not a service level agreement.