Moodle services
Moodle theme development and UX design
All-in-One LMS designs and builds custom Moodle™ themes for organizations whose site still looks like a default install, or whose old theme is holding back an upgrade. The work is based on child themes of Boost: your brand, navigation, login page and course layouts, built so that core improvements keep flowing through.
What Moodle theme development is
Moodle theme development is the work of changing how a Moodle site looks and is laid out without changing what it does. A theme is a plugin in the theme folder that supplies styles written in SCSS, overrides of Mustache templates, layout files and, where needed, renderer overrides. Current practice is to build it as a child of Boost, Moodle's standard theme, so the child inherits everything it does not deliberately change.
The UX design half comes first. A theme project starts with what learners and teachers need to find on each page, and turns to color and typography after that.
Why theme projects start
A theme request usually has one of these behind it:
- The site has the default look and does not match your brand.
- People cannot find their courses, deadlines or grades without being shown.
- The theme was bought or built years ago and breaks on a current Moodle version.
- An accessibility requirement has arrived from a customer, a regulator or your own policy.
- The site runs Classic, which leaves Moodle core in version 5.3.
Three ways to change how Moodle looks
Not every project needs a new theme. This table is how we decide with you.
| Approach | What you can change | Upgrade consequence | Fits when |
|---|---|---|---|
| Configure an existing theme | Logo, brand color, preset, background and login images, raw SCSS, custom menu items. Templates and layouts stay as shipped | Settings are kept. Raw SCSS needs checking when markup or the Bootstrap version changes. A third-party theme must publish a release for your target version | Branding is the whole requirement |
| Child theme of Boost | Everything above, plus Bootstrap variables, overridden templates, layouts, renderers and your own theme settings | Inherits Boost's fixes. Only the files you overrode need comparing with core at each release | Most organizations. This is our default recommendation |
| Fully custom theme | Everything, including the front-end framework | You own every template and style. Each front-end change in core, such as the move to Bootstrap 5.3, has to be reproduced by your team | Rarely: a design system that cannot sit on Bootstrap, and a budget for permanent maintenance |
How a Boost child theme is built
A child theme is a small plugin. Its configuration file names Boost as the parent and tells Moodle where the theme's SCSS comes from:
// config.php of a child theme
$THEME->name = 'yourbrand';
$THEME->parents = ['boost'];
$THEME->sheets = [];
$THEME->scss = function($theme) {
return theme_yourbrand_get_main_scss_content($theme);
};
$THEME->rendererfactory = 'theme_overridden_renderer_factory';Everything else is added only where the design needs it. There are four places to work, and they differ in how much they cost to maintain.
SCSS and presets
Boost compiles its styles from SCSS, and its settings already expose a preset, extra preset files, a brand color and raw SCSS fields. A child theme adds SCSS in two positions. Code injected before the main styles overrides Bootstrap variables such as colors, fonts, spacing and corner radius. Code added after them holds specific rules.
Changing a variable is nearly always better than overriding rules, because one line restyles every component that uses it. Moodle caches the compiled CSS, so we switch on theme designer mode during development and off again before release.
Mustache template overrides
Most of Moodle's HTML lives in Mustache templates that belong to each component. A theme replaces one by placing its own copy at templates/[componentname]/[templatename].mustache, so an override of a wiki template sits under templates/mod_wiki/.
An override is a copy frozen at the version it was taken from. When core later improves the original, your copy does not receive the improvement. We override as few templates as the design allows, record each one, and compare them with core at every upgrade.
Renderers
Some output is assembled in PHP before it reaches a template. When the data itself has to change, the theme supplies its own renderer class, for example theme_yourbrand\output\core_renderer, and overrides the relevant method. This is the most powerful tool and the one most exposed to core changes, so it is used sparingly.
Layouts
Layout files define the page skeleton and block regions for each type of page. Moodle names the types, among them login, mydashboard, mycourses, course, incourse, frontpage and admin. A child theme replaces only the layouts it needs to and inherits the rest.
Bootstrap 5.3 in Moodle 5.0, and what it means for older themes
Moodle 5.0 upgraded Boost from Bootstrap 4 to Bootstrap 5.3. For any theme or plugin written earlier, that changes three things.
Class names changed. .sr-only became .visually-hidden, .ml-* and .mr-* became .ms-* and .me-*, .text-left became .text-start, .custom-select became .form-select, and the .badge-* color classes were replaced by .text-bg-*. Data attributes gained a prefix, so data-toggle is now data-bs-toggle. And Bootstrap's JavaScript no longer depends on jQuery, so theme scripts that called Bootstrap through jQuery need rewriting.
SCSS is affected too. Several mixins were removed, and media-breakpoint-down() now uses the breakpoint itself instead of the next one up, which quietly shifts responsive rules.
Moodle ships a backwards-compatibility layer that keeps much of the old syntax working until its final deprecation in Moodle 6.0. A Bootstrap 4 theme may therefore appear to work on 5.x. It is running on borrowed time, and the work is cheaper done on your schedule than under a deadline.
Accessibility
Moodle's developer documentation states that Moodle aims for WCAG 2.2 Level AA conformance and is audited by external accessibility specialists. The most recent accreditation it lists is dated 3 October 2025 and covers Moodle LMS 5.1, 5.0.3 and 4.5.7. The user documentation adds a caution: it cannot be said with complete certainty that any site based on Moodle is fully accessible.
That accreditation applies to core as audited. A custom theme changes colors, focus styles, heading structure and templates, which is exactly where conformance is won or lost. On every theme we check:
- contrast of the brand palette against WCAG 2.2 AA, including buttons, links and disabled states;
- visible keyboard focus on every interactive element;
- heading order and landmarks in each overridden template;
- screen-reader text, so that labels hidden visually are still present;
- text resized to 200%, and reflow on narrow screens.
Two things sit outside the theme, and we say so in the handover. Content uploaded by teachers, such as PDFs and images without alternative text, is not fixed by a theme. Third-party plugins bring their own markup and need their own checks.
Ask for a theme and accessibility estimate
Login page design
The login page is the first screen every user sees, and the one most often left untouched. Boost has a setting for a login page background image, which is enough for many sites.
Beyond that, the login layout has its own layout file with no block regions, and the login form template can be overridden in a child theme. That allows a brand panel, help text, a support link or a different arrangement of the form. We keep the form's function intact: error messages, the language menu and whatever sign-in options your authentication set-up adds.
Course page layouts and custom course formats
The course page is where learners spend most of their time, and two separate layers shape it.
The theme controls how course elements look: section headers, activity cards, spacing, icons and the course index. The course format controls how the course is structured. Moodle's standard formats are Custom sections, Weekly sections and Single activity, plus an older Social format that is switched off on new installs.
A custom course format is a plugin in course/format. Its base class extends core_courseformat\base, and it decides how the course main page appears in both viewing and editing mode, with its own output classes and Mustache templates. A format is the right tool when the structure changes: a grid of tiles, a learning path with one step open at a time, or a single-page layout for short compliance courses. When only the presentation changes, the theme is enough.
A course format is engineered and tested like any other plugin, which our plugin engineering page describes.
Dashboard and Moodle app styling
Dashboard. The Dashboard and My courses pages have their own layouts, so a theme can restyle them, but what they show is decided by blocks and reports. That side is covered on our dashboards and reporting page.
Moodle app. The Moodle app does not use your site theme. It can load a remote CSS file set in the mobilecssurl field of the Mobile appearance settings, which Moodle's developer documentation says is available only to sites with a Premium subscription for the app. The other options are compared on our Moodle app development page.
Moving an old theme to a current Moodle version
Themes are the most common reason an upgrade stalls. These are the breaks we see, by cause:
- Bootstrap 4 code. Class names, data attributes and jQuery-based scripts, as described above.
- A design from before Moodle 4.0. That release redesigned navigation and added the course index and the My courses page, so older themes have no styling for them.
- A child of Classic. Classic was removed from core in Moodle 5.3 and now has to be installed separately as an additional theme.
- The
publicfolder. From Moodle 5.1 plugins, themes included, sit insidepublic, so hard-coded paths in theme code stop working. - Stale template overrides. Copies taken several versions ago no longer match what core sends them.
- An abandoned parent. A third-party theme whose author stopped publishing releases.
We begin by reading the old theme: its parent, its overrides, its settings and its scripts. Then comes one decision. A theme that is already a child of Boost with few overrides is patched. A theme built on a retired parent, or carrying dozens of stale overrides, is rebuilt as a new Boost child, because that is less work than repairing it.
In a rebuild, the design is carried forward and the code is not. Colors, type, logo and page arrangements are reproduced on the new base, then tested on a staging copy of the upgraded site with your real courses. This is normally one workstream inside a Moodle version upgrade.
How a theme project runs
- Brief. You share brand guidelines, the current site and what people complain about. An NDA is signed before we receive access.
- UX review. We walk the main journeys on desktop and phone: sign in, find a course, see what is due, submit work, check a grade.
- Design. Mock-ups for the key pages: login, Dashboard, My courses, course page and one activity page.
- Build. The child theme is written in version control against a staging copy of your site.
- Testing. Accessibility checks, browser and device checks, and a code review by a second engineer.
- Demonstration. You approve the theme on staging before it is switched on for the live site.
- Handover. Theme code, an override register listing every replaced template and renderer, and notes for the next upgrade.
What drives cost and timeline
The number of page types that get their own design matters most, followed by the number of template and renderer overrides those designs require. A custom course format adds a plugin to the project. Each extra brand adds design and testing time.
On the technical side, the target Moodle version and the state of any existing theme set the starting point. Formal accessibility testing with assistive technology takes longer than automated checks alone.
A branded Boost child theme with a handful of overrides is usually a few weeks of work. A full redesign with a course format and several brands runs longer.
Why All-in-One LMS for theme work
The engineers who build our themes also run Moodle upgrades, so they know which shortcuts cause trouble two releases later. That is why we default to Boost child themes and keep an override register.
We will also tell you when you do not need us. If Boost's own settings cover the requirement, that is the cheaper answer. When the list goes beyond appearance into fields, roles or workflows, our Moodle customization page shows how those requests are sorted.
The theme belongs to you, with its source in your repository. It is one part of our wider Moodle development and design work.
Frequently asked questions
Should we buy a ready-made theme or have one built?
A ready-made theme is quicker to start with and suits sites that mostly need a better default look. You then depend on its author to release a compatible version for each Moodle release, and you carry features you may never use. A Boost child theme takes longer to produce, contains only what you asked for, and follows core directly.
Will a custom theme break when we upgrade Moodle?
A child theme of Boost inherits most core changes without effort. The parts that need attention are the templates and renderers it overrides, and any SCSS that relies on markup that changed. With an override register, checking them is a defined task at each upgrade. Themes with no parent, or with many overrides, need far more work.
Our theme was built for Moodle 3.x. Can it be updated?
Sometimes, but a rebuild is more common. Themes from that period often sit on the deprecated Clean or More parents, use Bootstrap 4 or earlier, and predate the navigation introduced in Moodle 4.0. We review the old theme first and tell you which route costs less. In a rebuild the visual design is kept and the code is new.
Can you make our Moodle site meet WCAG 2.2 AA?
We can build and test the theme against WCAG 2.2 AA and fix what the theme controls: contrast, focus, structure, labels and reflow. Whole-site conformance also depends on course content and third-party plugins, which a theme cannot repair. If you need a formal conformance statement, we recommend an independent audit after the theme work, and we fix what it finds.
Can different departments or clients have their own branding on one site?
Yes, within limits. Moodle has settings that allow a different theme for a course category or a cohort, and one child theme can carry several brand variants. That changes appearance only. It does not separate users, reports or administration, so client portals that need real separation should be planned as a multi-tenant set-up.
We use the Classic theme. What happens in Moodle 5.3?
Classic is no longer part of Moodle core in 5.3. It can be installed as an additional theme from Moodle HQ's repository, which has to be done before the upgrade runs if its settings are to be kept, but HQ has said it does not currently plan to maintain it actively. For most sites the safer plan is to move to Boost or a Boost child theme as part of the upgrade.
Get a theme that survives the next upgrade
Send us your Moodle version, your current theme and your brand guidelines. An engineer replies within one business day with the approach we would take and what we need to estimate it.