Checklist for Starting a New Moodle or Totara Plugin

Summary: This guide gives you a practical pre-build checklist for starting a Moodle or Totara plugin with the right access model, data lifecycle rules, event handling, backup scope, and documentation from day one.

Its purpose is simple: avoid design mistakes that only become obvious during upgrades, deletes, restores, or long-term support. If you make these decisions early, the plugin is much easier to maintain later.

Start with the platform conventions

Follow Moodle coding style and the standard plugin structure from the beginning. That keeps your code easier to review, easier to upgrade, and easier for another engineer to support later.

If you drift from platform conventions early, you usually pay for it in every future release.

Model access with capabilities, not role names

Do not hardcode role shortnames into your plugin logic. Roles vary from site to site. Capabilities are the stable way to express who may do what.

Before you write UI or business logic, define:

• which actions require a capability check
• whether those checks apply at system, course, module, or another context level
• which operations should be visible, hidden, or blocked for different users

Design the data lifecycle before you design the tables

If the plugin stores references to users, courses, enrolments, or other Moodle entities, decide how those references behave when the underlying records change.

Typical questions to answer up front:

• What happens if a user is deleted or suspended?
• Should related rows be removed, soft-ignored, or rebuilt?
• Should hidden or deleted courses still appear in plugin output?
• Do learner-facing screens need to exclude invisible courses explicitly?

These are architecture decisions, not cleanup tasks for later.

Define your event strategy early

If the plugin depends on changes elsewhere in Moodle or Totara, use events in the relevant places instead of relying on manual repair or periodic guesswork.

Examples include:

• cleaning up dependent data when a source record is removed
• reacting to enrolment or completion changes
• keeping reporting or integration state in sync

Decide whether backup and restore support is part of the feature

If the plugin stores meaningful course, activity, or user-facing data, backup and restore is often part of the feature, not an optional extra. Retrofitting it later is usually expensive because the data model and restore assumptions are already set.

Ask explicitly:

• Should this data travel with course backup and restore?
• What identifiers need remapping during restore?
• What happens if dependent entities are missing in the target system?

Document the plugin while you build it

A useful README.md is not just repository decoration. It should explain what the plugin does, what it depends on, how it is configured, and what custom behaviour or assumptions support teams need to know about.

At minimum, document:

• installation and configuration steps
• capabilities and expected roles
• cron or scheduled task dependencies
• events, web services, or external integrations
• known customizations and site-specific assumptions

Use this as the minimum pre-build checklist

• follow Moodle coding style and plugin structure
• define capabilities instead of using role shortnames
• decide data lifecycle behaviour for referenced entities
• use events where state needs to stay synchronized
• plan backup and restore scope early
• document custom behaviour and operational assumptions

Solin specializes in Moodle and Totara plugin development, maintainability, and long-term support. Need help? Contact us.