Moodle Plugin Development

Moodle is extensible in a way most learning platforms are not, and that is the main reason to choose it. The catch is that a plugin written carelessly becomes a liability at the next major version – it blocks your upgrade, and eventually somebody has to pay to remove it. We build plugins that do not do that.

How we build

Everything we write follows the official Moodle coding style and uses core APIs rather than working around them. In practice that means:

• Core APIs, not direct SQL against core tables. The database schema changes between versions; the APIs are the contract that does not.
• Proper database installation and upgrade steps, so your plugin migrates cleanly instead of needing a manual fix on every site.
• Capabilities and access checks on every entry point, because “the link is hidden” is not access control.
• Privacy API implementation, so the plugin declares what personal data it stores and participates in data export and deletion requests.
• Language strings for all output, never hard-coded English in the code.
• You get the source. It is your plugin, in your repository, and another developer can pick it up. No black box, no lock-in.

What we have actually built

Rather than list plugin types in the abstract, here is the shape of recent work. Client names are withheld, but these are real builds solving real complaints:

• Bulk quiz marking. A single page that puts an entire cohort’s short-answer responses side by side so a trainer marks correct/incorrect in one pass, instead of clicking through attempt after attempt. Built because marking a 60-person cohort through the stock interface was taking a full day.
• Cross-category completion reporting. A report that spans course categories – which core reporting does not do well – with inline editing so a trainer can correct a completion state without leaving the report.
• Prerequisite course gating. An availability condition that blocks marking in a child course until the parent course is complete, so assessors cannot accidentally sign off out of sequence.
• Enrolment-relative availability. A condition that opens activities a set number of days after enrolment rather than on a fixed date – the thing you need when learners start on rolling intakes rather than in a term.
• Canvas to Moodle migration tooling. Courses, users, grades and completion state moved across from Canvas LMS, with reconciliation so nothing lands silently missing.
• Role-based landing pages. A dashboard that shows a learner, a trainer and an administrator three genuinely different views, instead of one page with most of it hidden.
• Attempt correction for managers. A controlled way for an authorised manager to fix a quiz attempt’s dates or a wrongly recorded answer, with the change logged rather than done invisibly in the database.
• Assessment due-date reminders. Scheduled reminder emails for quizzes, matching the behaviour Moodle already has for assignments.

Plugin types we work in

Across those builds and others, the plugin types we work in most: activity modules, blocks, local plugins, report plugins, availability conditions, enrolment and authentication plugins, question types and question behaviours, admin tools, and themes (usually a Boost child theme rather than a from-scratch build, because child themes survive upgrades and from-scratch themes do not).

Before you commission a plugin

The most useful thing we do is sometimes talk you out of one. Three checks we run first:

1. Does core already do this? Moodle has a lot of features that are switched off or buried. Configuration is free; a plugin is not.
2. Does a maintained plugin already exist? The Moodle plugins directory has thousands of entries. If a well-maintained one fits, use it – we will help you evaluate whether it is actually maintained.
3. Will this survive? If a requirement fights the way Moodle works, the plugin will need rewriting at every major version. We would rather redesign the requirement than sell you a recurring problem.

If a custom build is genuinely the answer, you get a written scope with the behaviour, the assumptions and the version compatibility target before anyone writes code.

Upgrades and ownership

Plugins we build are tested against the Moodle versions you actually run, and re-tested ahead of each major upgrade as part of ongoing maintenance. If you host with us, that testing happens on your staging clone before the upgrade reaches production. If you host elsewhere, we will still do it – we just need access to a staging environment.

Related services

Plugin work usually sits alongside broader custom development, integration with your other systems, and managed hosting. If a plugin is slowing your site down rather than a server problem, start with our notes on diagnosing Moodle page load issues.