Inside Drupal LMS: Architecture, Entities and Developer Experience

The stack a real deployment runs on

The reference development stack for Drupal LMS is deliberately boring, which is exactly why it is easy to hire for and cheap to host in Hong Kong:

Drupal LMS 1.2.4 was released on 7 October 2026 and is covered by the Drupal security advisory policy, so stable releases receive coordinated security response. The project is maintained by Tag1 Consulting, with initial and ongoing development by the American Federation of Teachers, and reports 208 reporting sites.

The entity model

Drupal LMS is built on Drupal's configuration-driven entity system, which is what makes it modular: everything is a bundle of a base entity type plus configuration.

The status entities are the reason progress tracking in Drupal LMS is a first-class modelled concept. Progress is recorded as data, not inferred from reports — so a three-year student record is queryable without any vendor-specific export format.

Activity types and what they permit

Activity types are bundles of lms_activity. The published set covers a genuinely wide range of assessment:

• select_single — single choice question
• select_multiple — multiple answer question
• true_false — true/false question
• free_text — written response
• file_upload — file submission
• webform — a Webform form as an activity
• xapi_tincan — an xAPI/Tin Can activity
• no_answer — information-only block
• *_feedback variants — select_single_feedback, select_multiple_feedback, true_false_feedback, free_text_feedback — which return per-response feedback

The *_feedback variants matter more than they look. Immediate per-response feedback turns an activity from a grading event into a learning event, which matters for micro learning and for formative assessment inside a course.

Events, messages and notifications

LMS Messages integrates with Drupal's Message module to send notifications on LMS events. The published message types give a clear picture of the workflow the ecosystem expects:

• lms_messages_new_request — a membership request was submitted
• lms_messages_approved_request — a request was approved
• lms_messages_rejected_request — a request was rejected
• lms_messages_answer_comment — a comment was added to a learner answer
• lms_messages_course_evaluation / lms_messages_course_evaluated — evaluation submitted / learner evaluated

For an enterprise approval workflow — the external-training scenario where an employee requests a course and a manager approves it — those first three message types are the whole cycle. An approval workflow with no notification is a workflow that stalls in an inbox.

Groups: courses, classes and cohorts

Drupal LMS uses Drupal's group module with two group types: lms_course for course groups and lms_class for class subgroups within a course. This is the mechanism behind both school class structures and enterprise cohort-based programme delivery — a Year 10 class, a management development cohort, a department-wide compliance group.

The DDEV development stack

For local development and new-project scaffolding, the ecosystem recommends a DDEV-based starter kit. DDEV gives a containerised, reproducible environment with no local PHP or database installation required.

git clone git@github.com:graber-1/drupal_lms_ddev.git
cd drupal_lms_ddev
ddev start
ddev composer install
ddev composer update drupal/lms
ddev composer si      # standard install
ddev composer sid     # install with demo content + developer console

The two install scripts are worth noting. si runs a minimal site install with existing config. sid additionally runs a Drush command called lms-ctt ("create test training" with simple passwords) and installs the developer console — producing a site with populated test content, which is exactly what you want when demonstrating to a client or onboarding a new developer.

The reference configuration is explicit: php_version: "8.4", database: mariadb 11.4, webserver_type: nginx-fpm, nodejs_version: "16", with a Selenium standalone Chrome container for browser testing and Tugboat configured for per-branch preview environments.

Drupal 11 OOP hooks and quality tooling

Drupal 11 moves hooks out of procedural files and into attributed OOP hooks. This is what a custom module hook declaration looks like:

 [
      'variables' => ['data' => NULL],
    ],
  ];
}

The quality toolchain is part of the deal, not optional:

• PHPUnit (9, 10.5 or 11) — unit, kernel and functional tests
• PHPStan with deprecation rules and strict rules, plus a baseline for pre-existing issues
• PHPCS / PHPCBF with Drupal coding standards
• config_inspector for configuration change detection

And because Drupal LMS is itself a fork, contributing upstream is a normal workflow: clone into web/modules/contrib/lms, add your fork as a remote, work on an issue branch, and open a merge request. The module tree ships its own phpcs.xml, phpstan.neon and phpunit.xml.

Why this matters to an HK buyer

You are not buying a black box. You are buying GPL code on a mainstream CMS with a documented entity model, published contributed modules, a named maintainer, and a standard toolchain. Concretely, for a Hong Kong organisation:

• No seat licensing means a school with 1,200 students or an enterprise with 8,000 staff carries no per-user licence line.
• Published module list means you can see exactly what exists and what does not, instead of trusting a vendor feature matrix.
• Portable content — SCORM, xAPI, H5P and YAML packages all move out with you.
• Full database access and standard export, because it is your database.
• Hiring pool — Drupal and PHP skills are not niche, unlike some proprietary LMS skill sets.