Moodle Plugin Types Explained: What to Build and When

Almost everything in Moodle is a plugin, and every plugin has a type. There are dozens of Moodle plugin types, and each one is a contract: a fixed folder, a set of files Moodle expects to find, and a defined place where the plugin appears and gets called. Pick the right type and Moodle does half the work for you. Pick the wrong one and you fight the platform for the life of the feature.

The type also cannot be changed later without a rewrite and a data migration. So the choice deserves an hour of thought before a developer writes a line. This guide covers the types you are most likely to need, the pairs that get confused, and the cases where the right answer is no plugin at all.

See what configuration can do first

A good share of the requests that reach us as "we need a custom plugin" can be met with settings Moodle already has. Before you commission anything, check this list:

• Who can see or do what: a custom role, or a capability override in one course or category.
• Extra data on users or courses: user profile fields and custom course fields, both created in site administration.
• Rules about order and access: activity completion combined with "Restrict access" conditions on activities and sections.
• Enrolling groups of people: cohorts with the cohort sync enrollment method.
• A report for managers: the report builder under Site administration > Reports > Custom reports.
• Embedding another tool in a course: the External tool activity, which speaks LTI.
• Colors, fonts and small layout changes: the settings of the Boost theme, including its Raw SCSS fields.

The second check is the Moodle plugins directory. If a maintained plugin does most of what you need, installing it beats building. Judge it by three things: whether it lists your Moodle version as supported, when it was last released, and how its maintainer responds to reported issues.

How Moodle plugin types work

Each type lives in its own folder and has a short prefix. A plugin's full name, which Moodle developers call its component name, is the prefix, an underscore and the plugin's own name. The forum activity is mod_forum and sits in mod/forum. The manual enrollment method is enrol_manual in enrol/manual. From Moodle 5.1 these folders sit inside the public directory of the code base.

Whatever the type, a plugin carries the same core files. version.php declares the component, its version, the Moodle version it requires and any plugins it depends on. lang/en/ holds its text. The db folder defines its tables (install.xml), upgrade steps, capabilities (access.php), event observers (events.php), scheduled tasks (tasks.php) and web service functions (services.php). The type then adds its own required pieces on top. The official list of plugin types documents each one.

The types you will meet most often

Type	Prefix	Use it when
Activity modules	mod	Learners do something inside a course that needs its own page, settings, grades or completion
Blocks	block	You want a small panel of information or shortcuts on the dashboard or a course page
Local plugins	local	Site-wide logic has no natural home in another type
Authentication plugins	auth	People sign in through an external identity source
Enrolment plugins	enrol	Something outside the course decides who is enrolled, and for how long
Themes	theme	The look, layout and templates need to change
Reports	report	Admins or teachers need a view of site or course data
Course formats	format	The course page itself should be laid out differently
Admin tools	tool	Administrators need a utility: an import, a clean-up, a bulk operation
Availability conditions	availability	You need a new rule for restricting access to activities and sections
Question types	qtype	Quizzes need a kind of question that does not exist yet
Quiz access rules	quizaccess	A quiz needs extra conditions on when or where it can be attempted

The names are Moodle's own, which is why "enrolment" keeps its British spelling. Many more types exist for narrower jobs, such as text filters, repositories, gradebook reports and assignment submission types. The same reasoning applies to all of them: find the type whose contract already describes your feature.

The choices that get confused

Activity module or block

Build an activity when the feature belongs to a course, has its own data for each instance, and should be graded, tracked for completion and included when the course is backed up or duplicated. Activities are the most work of any type for exactly those reasons: backup and restore, gradebook integration and completion support all have to be written.

Build a block when the feature shows something and stores little. The classic mistake is a block that grows forms, tables and workflows until it is an application squeezed into a side panel. If the first sketch has more than one screen, it is probably not a block.

Local plugin or a standard type

Moodle's developer documentation is direct about this: the recommended way to add functionality is a standard plugin type, and local plugins are for what does not fit one. Good uses are event observers that push completions to an HR system, custom web service functions for a mobile app or portal, and scheduled tasks that sync data. A local plugin that draws course content or user-facing pages is usually an activity, a block or a course format in disguise.

Authentication or enrollment

These are separate on purpose. Authentication answers "who is this person". Enrollment answers "which courses are they in, with which role, until when". A single sign-on plugin should create and update the account and stop there. Rules such as "everyone in the sales department gets the product course" belong in an enrollment plugin, or in a cohort that an enrollment method follows. Mixing the two tends to produce slow logins and enrollments nobody can explain.

Theme or plugin

A theme changes how Moodle looks. It should not decide what Moodle does. When business rules creep into theme templates and renderers ("hide this button for partner users"), they vanish the day someone switches or updates the theme. Put the rule in a plugin or a capability, and let the theme only present the result.

Report plugin or custom report

A report plugin gives you full control and its own page. Often you do not need that. A plugin of any type can register its tables as a data source for the built-in report builder, after which administrators assemble, filter, schedule and share reports themselves. That is less code to maintain, and the people who read the reports can adjust them without a developer.

What every plugin costs after launch

Writing the plugin is the smaller part of its cost. Moodle ships a major release twice a year, and each custom plugin has to be checked against it, since APIs are deprecated on a published schedule and then removed. Plugins that store personal data need a privacy provider so that data export and deletion requests include them. Activities need backup and restore kept in step with their tables. And nothing custom appears in the Moodle mobile app unless the plugin adds mobile support.

Two rules follow. Keep the number of custom plugins small, and never solve a problem by editing core files. A core change is overwritten by the next upgrade, or worse, it blocks the upgrade. We describe that check in planning a Moodle upgrade.

Deciding what to build

Write the requirement as one sentence about a person: "a line manager sees which of their staff have an expired certificate". Try to meet it with configuration, then with a plugin from the directory, and only then with custom code. If you reach custom code, name the type before you ask for a quote, or ask the developer to justify the type they propose. A good answer mentions where the feature appears, what data it stores and how it behaves in backups and upgrades.

Small, well-typed plugins are a reasonable job for an in-house PHP developer who learns Moodle's conventions. Activities, question types, enrollment logic tied to payments and anything that syncs with another system repay experience. That is the work our Moodle plugin development team does, alongside Moodle customization where settings and an existing plugin are enough, and integration work where the plugin's job is to talk to another system.

Frequently asked questions

Can one Moodle plugin be two types at once?

No. A plugin has exactly one type. A feature that needs, say, an activity and a block is shipped as two plugins, and one declares the other as a dependency in its version.php so Moodle installs them together.

Do custom plugins survive a Moodle upgrade?

The files and data stay, but the plugin has to be compatible with the new version. Before each major upgrade, test every custom plugin on a copy of the site with developer debugging on, and fix the deprecation notices it produces.

Is a local plugin the easiest type to build?

It has the fewest required parts, which is why it gets overused. Easy to start is not the same as right. If the feature has a screen inside a course, a standard type will save work later, because Moodle supplies navigation, permissions and backup behavior for it.

Will a custom plugin work in the Moodle mobile app?

Not automatically. The app shows core features and plugins that include mobile support. If learners use the app, say so at the start, because adding mobile support to an activity is a separate piece of work.