Moodle Plugin Types Explained: Every Type and Its Directory

Moodle plugin types are the fixed categories of extension that Moodle core knows how to load: each type has a short frankenstyle prefix (such as mod, block or local) and one directory where every plugin of that type lives. Moodle 5.3 defines 45 plugin types in lib/components.json, keeps one more (mnetservice) in a deprecated list, and core plugins declare a further 18 subplugin types of their own. Pick the wrong type and your code either never loads or fights the APIs it needs.

This reference lists every type with its directory, explains how subplugins work, shows which types arrived or left in recent releases, and gives a short rule set for choosing the right one. Checked against the Moodle 5.3.0 source (lib/components.json, every core db/subplugins.json, core_component and core_plugin_manager) and the Moodle developer docs on plugin types, October 2026.

How Moodle knows which plugin types exist

Moodle does not scan the disk for anything that looks like a plugin. It reads a registry, then looks only in the directories that registry names:

• lib/components.json at the project root holds three objects: plugintypes (type to directory), subsystems (core areas such as core_course) and, when needed, deprecatedplugintypes or deletedplugintypes.
• db/subplugins.json inside a plugin declares that plugin's own subplugin types under a subplugintypes object, with directories relative to the parent plugin.
• core_component loads both, then caches the result. core_component::get_plugin_types() returns every type and its full path, get_plugin_list($plugintype) returns the installed plugins of one type, and get_subplugins($component) returns a parent's subplugin types.

A new plugin folder is installed when an administrator visits the Notifications page or runs admin/cli/upgrade.php. If you need the exact list for your own site rather than this article, the developer docs give a short CLI script that loops over core_plugin_manager::instance()->get_plugin_types() and prints each type, its plural name from plugintype_name_plural() and its directory.

From Moodle 5.1 the web-accessible code moved into public/, so every directory below sits under public/ on 5.1, 5.2 and 5.3. On 5.0 and earlier, drop that prefix. components.json in 5.3 stores the paths with the prefix, for example "local": "public/local".

The plugin types most projects actually use

Most custom work lands in about a dozen types. This table maps the common needs to the type that fits.

Every Moodle plugin type and its directory in Moodle 5.3

This is the full plugintypes object from the 5.3.0 lib/components.json, grouped by area. Directories are relative to public/.

A few of these surprise people. coursereport is still registered, but 5.3 ships no plugins in course/report; new course-level reports belong in report. editor covers whole text editors (TinyMCE and the plain textarea in 5.3), not editor buttons. h5plib holds versions of the H5P integration library, not H5P content.

Subplugin types: plugins inside plugins

Some plugins expose their own extension points. The parent declares them in db/subplugins.json, and the subplugin's component name uses the subplugin type as its prefix, for example assignsubmission_file. These are the 18 subplugin types declared by core plugins in 5.3.0:

Third-party plugins can declare subplugin types too, so a site with contributed plugins will show more than this list. Subplugin type names are global: each subplugin type name must be unique across the site, because Moodle maps the prefix alone, such as quizaccess, to one directory.

A subplugin is usually the cleaner choice when you extend one activity. A new quiz access rule belongs in quizaccess, not in a local plugin that hooks into quiz pages, because the quiz then calls your rule through its own API.

Plugin types added, deprecated and removed in recent releases

If you maintain plugins across several Moodle branches, these changes matter more than the full list:

In 5.3.0, mnetservice (public/mnet/service) is the only entry in deprecatedplugintypes, and there is no deletedplugintypes object. Deprecation is staged: in the first stage core stops calling plugins of that type through hooks, callbacks and events, though their classes and strings still load; in the second (deleted) stage, any installed plugin of that type blocks the site upgrade until it is uninstalled. Subplugin owners use the same stages through deprecatedsubplugintypes and deletedsubplugintypes. If you hit that block, our guide to an upgrade blocked by a deprecated plugin type walks through the fix.

Naming rules and frankenstyle component names

Every plugin has a frankenstyle component name: the type, an underscore, then the plugin's machine name, as in local_hrsync or block_myoverview. The machine name is checked by core_component::is_valid_plugin_name():

• It must start with a lowercase letter, end with a lowercase letter or digit, and contain only lowercase letters, digits and single underscores. The pattern is /^[a-z](?:[a-z0-9_](?!__))*[a-z0-9]+$/.
• Activity modules (mod) may not contain underscores at all (the check is /^[a-z][a-z0-9]*$/), and a module may not share its name with a core subsystem.
• qtype_random is reserved and rejected.
• Hyphens are never allowed. A plugin that fails these checks is silently ignored, which is a common reason a freshly copied plugin never appears on the upgrade screen.

The folder name must match the machine name, and the component name drives the class namespace (\local_hrsync\...), the language file (lang/en/local_hrsync.php) and configuration rows. One quirk: activity modules keep a bare language file name (lang/en/forum.php for mod_forum).

How to choose the right plugin type

A few rules settle most debates on a project:

1. Use the most specific type that has an API for your job. A new login method is auth, a new payment provider is paygw, a new AI model connector is aiprovider. The specific type plugs into the admin screens and callbacks core already has for that job.
2. Extend an activity through its subplugin type when one exists, rather than patching the activity or hooking into it from outside.
3. Reach for local when nothing else fits: integrations, scheduled sync jobs, event observers, web service functions and site-wide hooks. Do not use it to add a learner-facing course activity; that needs mod so it appears in the activity chooser, backup and restore, the gradebook and completion.
4. Use tool for admin-only utilities that live under Site administration, and report for read-only reporting screens.
5. Never edit core plugins. If a core plugin almost fits, look for a hook, a subplugin type or a theme override first, then a local plugin.

Some features span types. A typical HR integration is a local plugin for the sync and web services plus an auth plugin for login. Ship each as its own plugin, declare the dependency in version.php, and keep shared code in one of them.

To see what a site already has, open Site administration, Plugins, Plugins overview, or run php admin/cli/uninstall_plugins.php --show-contrib from the project root to list third-party plugins only. Our Moodle guide covers the rest of the development and administration topics, and the plugin compatibility guide explains what to check before a major upgrade.

How we can help

We build and maintain Moodle plugins of every common type, from local integrations and auth connectors to full activity modules and quiz access rules, and we audit contributed plugins before upgrades. See our Moodle plugin development service or the wider Moodle platform page.