Moodle video plugins: what each plugin type does, and why video needs four of them

An administrator uploads a video plugin ZIP and Moodle refuses it, naming a dependency nobody mentioned on the page they downloaded it from. The quieter version costs more: the install goes through, video plays in the activity it was added to, then somebody pastes a video into a forum reply and gets raw text back.

Both failures come from the same place. Moodle plugin types are a division of labour, the prefix on a plugin's name tells you which division it belongs to, and video crosses several of those lines at once. We learned that building the FastPix Moodle integration, which ended up as four plugins, and the prefixes turned out to be a rougher map than we assumed: tiny_ looks like a sibling of local_, mod_ and filter_, and it isn't one.

What follows is what each position owns, why tiny_ sits a rung below the others, seven questions to ask of any plugin, and a dependency chain the installer won't take out of order.

Scope the job before you shortlist

Putting graded video into a Moodle course looks like one job and is really five. Something holds the credentials and talks to the video platform, teachers add an activity and grade it, and a player renders wherever Moodle formats rich text. Authors want an editor button rather than a short code, and watch data has to reach the gradebook in a shape Moodle understands.

Write those five down before you open a plugin page, because each lands on a different part of Moodle's architecture, and the part decides where the code lives and when Moodle calls it. Shortlisting the other way round, by reading plugin pages and hoping one covers everything, is how a site gets video that works in an activity and dies in a forum reply.

What are Moodle plugin types?

Moodle plugin types are the fixed positions a plugin can occupy, each with a directory in the source tree, a set of callbacks Moodle will invoke, and an answer to when its code runs. The plugin types table on moodledev.io lists 56 and describes every one, so the type itself is documented; what no table tells you is which combination a capability needs.

Local plugins carry the prefix local_ and hold site-wide services: credentials, an HTTP client, a cache, a webhook endpoint, scheduled tasks. A local plugin has no page in a course and no presence in the editor, so it is invisible to teachers and load-bearing for everything above it.

Activity modules carry the prefix mod_ and are what a teacher adds to a course section. An activity owns its database tables, settings form, view page and gradebook and completion entries, so anything graded or backed up with the course needs one.

Text filters carry the prefix filter_ and run over text after Moodle renders it, spotting a token in any field that goes through the formatting pipeline and swapping it for markup. That is how one embed mechanism reaches every text area at once.

Editors are the type named editor, at /lib/editor, and they supply the text editor itself rather than anything inside it. That distinction matters more than it sounds. Counts also move between releases, so rather than trusting 56 forever, run the core_plugin_manager script published on that page against your own site.

Is tiny_ a Moodle plugin type?

No, and this is the bit we got wrong in our own first write-up. tiny_fastpix reads like a sibling of local_fastpix, mod_fastpix and filter_fastpix, so we described it that way, and the table disagrees with us. The row for text editors is editor, at /lib/editor, and tiny has no row at all, because TinyMCE plugins are subplugins of editor_tiny, namespaced tiny_[pluginname] under /lib/editor/tiny/plugins.

The contrast that makes it concrete is atto, Moodle's older editor, which does hold its own row at /lib/editor/atto/plugins. Same shape on disk, different standing: an Atto plugin is a plugin type, a TinyMCE plugin is a subplugin of one, so our family spans three plugin types plus one subplugin type. Read a prefix as a hint about where code sits, then check the table, because the prefix won't tell you which rung you're on.

Why video needs four plugins

Five jobs, four plugins, and our Moodle family works as a specimen because it's installable today and Moodle itself enforces the ordering rather than a README asking politely.

Read down the third column and the split explains itself. Credentials can't live in the activity, because the filter and the editor button need them too, and token signing can't live in the filter, which runs on every page and has no business holding a key. So mod_fastpix never talks to FastPix directly, and every call leaves through local_fastpix.

The division has a visible edge, and it's the one place we expected to fudge and couldn't. filter_fastpix won't embed a private or DRM video at all, because those need short-lived tokens refreshed during the session, and a token baked into a forum post goes stale within the hour.

Wiring that split yourself is where the time goes, and one credential copy per feature is the wrong answer that looks fastest on day one. Ours is documented per plugin: local_fastpix, mod_fastpix, filter_fastpix, tiny_fastpix.

What Moodle plugin dependencies enforce

A plugin declares its dependencies in version.php, and Moodle checks them before the upgrade runs rather than after, which is the whole point: a dependency you can violate is a suggestion, one the installer applies is part of the design. mod_fastpix can't be installed alone, so Moodle blocks it and names the plugin it wants until local_fastpix is there, reproducible on a test instance in five minutes.

Install order falls out of it: foundation first, then whatever sits on top, in any order. An upgrade to the foundation can change what the dependents require, so the check runs again every time. A typed family also lets you take part of it, which is why our Moodle docs cover the foundation and the activity alone, a pairing that still gives a course graded video.

Seven questions before you install

No plugin directory page answers these, and all seven are answerable in an afternoon from the plugin's documentation.

1. Which positions does it install, and in what order? A family means a dependency chain, and you want that order before you touch the site.
2. Does it add scheduled tasks to Moodle cron? Anything ingesting webhooks depends on cron whether its page says so or not.
3. Does it need infrastructure you don't already run? A shared cache or a queue turns a plugin install into an ops change, which goes through a different approval.
4. Does it bundle third-party libraries? Bundled libraries become your patching problem, and two plugins shipping different versions of one library is a support ticket.
5. Does it declare capabilities, or gate everything on the admin role? A plugin with no capabilities can't be delegated, so a teacher who needs upload rights gets the whole site.
6. Is it a Privacy API provider? Undeclared per-user columns are quietly left out of a GDPR export.
7. What does a course backup actually contain? A backup that drops per-user rows gets discovered during a restore, the worst moment.

The same seven, answered

We wrote the checklist to hold us to it as hard as anyone else, so every answer below is checkable in our Moodle docs.

Positions and order. Four plugins across three plugin types and one subplugin type, foundation first, with Moodle enforcing the order. The requirement is Moodle 4.5 LTS or later and PHP 8.1 or later, tested through 8.3. Treat 4.5 as our floor rather than your target, because moodledev.io now marks it unsupported for general bug fixes and 5.3 is the current LTS.

Cron. local_fastpix receives the webhook and Moodle cron drains it, alongside tasks that sweep stale upload sessions, prune the webhook ledger and rotate the signing key. A video stuck on "Preparing your video" is the visible symptom of cron not running, worth knowing before anyone files a bug.

Infrastructure. One requirement, and the one an admin is most likely to skip: local_fastpix needs a shared Moodle Universal Cache backend, meaning Redis, Memcached, or the file store on a single-server install. Our circuit breaker and rate limiter keep state there and need every PHP worker reading the same copy, so getting it wrong shows up as a slow site rather than a named error.

Third-party libraries. One bundled library, firebase/php-jwt under BSD-3-Clause, and no runtime Composer dependencies, so that's one thing to watch when a security advisory lands and nothing to resolve at install time.

Capabilities. mod/fastpix:uploadmedia covers uploading and sits with editing teachers by default, mod/fastpix:viewallattempts opens the Watch report, and mod/fastpix:graderoverride corrects a flagged attempt. Three decisions instead of one admin switch.

Privacy. Both plugins ship full Moodle Privacy API providers, and the activity declares every personal-data column in its attempt table: watch progress, seek count, fraud count, completion state and session timestamps. Export and per-user delete run from Moodle's standard data-request screen.

Backup and restore. A backup captures the activity settings, the per-user attempt rows and the asset reference, and leaves the video bytes with us, so a course of lecture recordings still backs up at the size of a course. Restore it onto a site pointing at a different account and the activity shows "Video unavailable", expected rather than a fault.

Install local_fastpix first

The order is the only real decision here and it costs a minute. Put local_fastpix on the site, paste in the API key and secret, then press Test connection until it returns Authenticated, which is the moment the credential problem is solved for every plugin above it. Add mod_fastpix when teachers need a graded video activity, then filter_fastpix and tiny_fastpix when authors want a video in a forum post without leaving the editor.

Our Moodle docs carry the per-plugin reference, and the install, use and grade walkthrough covers the teacher side. Playback needs an account behind it, and you can run the whole chain on staging on the free plan first.