Why Moodle theme development needs a plan before the first colour change
Moodle theme development means creating or adapting a theme so that a self-hosted Moodle site matches your brand, layout and accessibility standards. A team usually needs it when the default look does not fit the institution or organization, when staff and learners need a consistent experience across courses, or when accessibility review finds problems that styling alone can fix. The work touches templates, stylesheets and theme configuration, so it is worth planning before anyone changes a colour. The first thing to plan is what a theme can actually change in the release you target. Moodle ships major releases every six months, in April and October, and minor point releases every two months, so core templates and styles are not static. Theme code that overrides core output can break when those files change, which means every override needs a reason and an owner. Confirm the exact templates and style sources you plan to touch against the release your site will run, not against an older example you found online.
Version choice is the second decision. Moodle 5.3 removes the Classic theme from core, so a team that built its plan around Classic needs to start from a supported base instead. Navigation has also moved toward React in parts of the interface, which means some areas are controlled by components rather than by Mustache templates or SCSS. Before committing to a design, list every screen the brand must cover, then check with the release notes whether each area is themeable through templates, through settings, or only through other means. Treat any gap as a scope item, not a surprise at the end of build.
Your hosting and upgrade path also shapes the theme. Moodle 5.1 requires the web server document root to point to the new /public directory, and a theme that works on a local test setup can behave differently once the server is configured correctly. Sites on older releases may need to move through intermediate versions before they can take a current theme, and the minimum PHP and database requirements for each release affect the test environment. Ask whether the theme will be built as a child theme of a supported base, how it will be tested after each point release, and who will merge core changes into it over the following years.
Accessibility belongs in the plan from the start, not in a final audit. Colour contrast, focus visibility, keyboard navigation and the structure of templates all depend on decisions made early in the design. Set a written standard that names the accessibility criteria your organization must meet, then ask your team or partner to show how each criterion will be verified on the target release. Keep in mind that a theme can improve presentation but cannot repair course content, so agree in advance which responsibilities sit with the theme project and which sit with content authors.
Which parts of Moodle a theme controls and which it should leave alone
A Moodle theme can shape layout, styling, templates, scripts, strings and settings, but each of these layers has its own upgrade risk. The cards below describe what each extension point is for and where it tends to break when Moodle moves to a new release, so you can decide what belongs in the theme and what should stay in core.
Theme folder structure and config file
Every theme lives in its own folder under the theme directory, and its config.php file declares the theme name, parent theme, layouts and region mappings that Moodle reads at runtime. Changes here control which page layouts exist and where blocks can sit. Check the config keys and layout names against the developer docs for your target release, because renamed or removed layouts cause pages to render with missing regions after an upgrade.
Parent and child theme inheritance
A child theme inherits templates, styles and language strings from a parent theme and overrides only the files it defines. This keeps brand changes small and lets core updates reach the parent without rewriting your work. The risk is silent drift: a child that copies large parts of a parent becomes a fork that must be re-merged on every release. Confirm which parent theme your target release supports and keep overrides to the smallest set of files.
Mustache templates for page and renderer output
Mustache templates define the HTML that Moodle outputs for pages, blocks, and renderer-driven components such as course lists and activity headers. Overriding a template gives you direct control over markup, but it also freezes that markup at the version you copied. When a core template changes its variables or structure in a later release, your override may drop content or break accessibility attributes. Compare each overridden template against the core version during every upgrade test.
SCSS and the variables it exposes
Moodle compiles SCSS through Bootstrap-based variables and theme-level stylesheets, so brand colors, typography and spacing can usually be set through exposed variables rather than by overriding selectors. Prefer variables for branding and reserve selector overrides for gaps the variables do not cover. Overrides that target internal class names or deep component markup are the most common cause of visual breakage after a release, so verify the variable list and compiled output for the release you plan to run.
JavaScript modules in the theme
Themes can ship JavaScript modules for behavior such as menu toggles, accessibility helpers or small interface enhancements. Moodle loads these as AMD modules, and core's JavaScript build changes between releases as frontend code moves toward React-based components. Keep theme scripts thin, avoid patching core modules by name, and test each script with keyboard navigation and a screen reader on the target release. Where a core feature is now a React component, confirm whether a theme script still has a supported hook.
Language strings and their overrides
Language strings control labels, help text and messages shown to users. A theme can override individual strings so that terminology matches your institution, which is a low-risk change when it is limited to wording. The risk comes when an overridden string key is renamed or removed in core, leaving the old wording in place or showing raw keys. Keep a list of every overridden string and review it against the release notes for each upgrade.
Theme settings and presets
Theme settings expose options such as logos, footer text, and color choices through the admin interface, and presets bundle a set of those values for reuse. Settings are stored in the database, so they survive code updates, but a setting that is removed or renamed in a new theme version can leave orphaned values. Document each setting, its default, and the preset it belongs to, and confirm the settings API for your target release before building on it.
Child theme, fork or new build: which option fits your brand and upgrade plans
This table compares three ways to build a Moodle theme: a child theme on a maintained parent, a team-owned fork, and a new theme from scratch. Read each row against your branding depth, upgrade cadence and accessibility obligations. The main takeaway is that the more of core's template and SCSS surface you own, the more work every Moodle release brings you.
| Decision factor | Child theme of a maintained parent | Forked parent theme owned by your team | New theme built from scratch |
|---|---|---|---|
| When it fits | Branding is mostly colors, fonts, logos and light layout changes on a parent the vendor or community still maintains | Parent has most of what you need but you must change structure or behavior the child cannot override | Brand requires a distinct layout system, or no maintained parent meets your accessibility and design needs |
| Cost to maintain across Moodle releases | Lowest recurring effort; re-test overrides after each parent update and each Moodle major | Highest ongoing effort; you merge upstream parent changes into your copy at every release | Recurring effort covers the whole theme, including core template and API changes, on every release |
| Handling upstream accessibility fixes | Inherited when you take parent updates; confirm the parent's accessibility policy and release cadence | Manual: you must review and port each upstream fix into your fork | Entirely your responsibility; you must test against the accessibility standards your institution has adopted |
| Core template set your team must track | Only the templates you override, plus the parent's overrides | Every template you change, plus every upstream template change in the parent | All templates you use, which is most of the standard layout set |
| Classic-based code in scope | Not applicable to new work; Classic left core in 5.3, so confirm the parent does not depend on it | Only if the fork starts from Classic; plan a migration path before upgrading past 5.2 | Do not start from Classic; build on a supported core theme or your own base |
| Ownership of the code | Shared with the parent maintainer; your code is limited to the child | Your team owns it, including security and compatibility fixes | Your team owns it entirely |
| What to confirm before choosing | Parent's support status for each Moodle release you plan to run, and its license terms | Staffing for merges at each six-monthly major and point release | Who will review accessibility, and how theme testing is scoped in your quote |
How the theme build runs from brand brief to a tested release
The sequence starts from the Moodle release the theme will run on and ends with a theme tested on the page types learners and teachers use most. Each step closes with a check, so the team can confirm the work is finished before the next step begins.
Confirm the target Moodle release and requirements
The platform owner fixes the Moodle release the theme will target, then records its PHP, database and web server requirements from the release notes for that version. In Moodle 5.1, for example, the web server document root moves to the /public directory, which changes how the theme is deployed and tested. Confirm the support window for the release against your own support plan. Done when the team has a written requirements sheet, signed off by the platform owner, that lists the release, PHP version, database version and document root.
Set up a development environment that matches production
The platform engineer builds a non-production Moodle instance on the target release, using the same PHP version, database engine, web server layout and cache setup as production. Theme work depends on compiled assets and cache behavior, so a local setup that differs from production hides problems until late. Keep the theme code in version control and deploy it through the same path used for production. Done when a clean install of the target release loads the default theme and the site can be rebuilt from scripts.
Agree the brand and accessibility brief
The product owner, the brand team and an accessibility lead agree what the theme must change: colors, typography, logo placement, layout of the dashboard and course pages, and the contrast and focus behavior the brand must meet. Write the brief as testable statements, such as a named color pair that must pass a contrast check or a visible focus indicator on every interactive element. Confirm which accessibility standard your institution applies and who signs it off, since the brief sets what the later tests check. Done when the brief is approved in writing and each requirement has a named test.
Choose the parent and child theme structure
The theme lead selects the core theme the new theme will inherit from and places all brand work in a child theme, so core files stay untouched and each upgrade becomes a matter of re-testing the child. Confirm that the chosen parent still ships in the target release, because Moodle 5.3 removes the Classic theme from core. Record the decision and its reasons in the repository readme. Done when the child theme installs on the dev site, appears in theme selection and renders the parent's pages without errors.
Build SCSS variables and then component styles
The front-end developer sets brand values as SCSS variables first, covering color, font and spacing, so the palette and typography change in one place. Component styles for navigation, course cards, forms and buttons follow, written against those variables with no hard-coded colors. Run a clean build of the compiled CSS from a fresh checkout, then confirm it compiles without errors and that the output matches the approved palette on the dev site with caches purged. Done when the clean build succeeds and the compiled output has been checked against the brief.
Override only the templates that need changes
The developer copies into the child theme only the Mustache templates and renderers the brief requires changing, leaving everything else inherited from the parent. Each copied file carries a note recording the parent release it was taken from. Where navigation is rendered in React in the target release, confirm the supported extension point in the release documentation before copying anything. Before merging, review a template diff against the parent release line by line, so upstream changes are carried forward on purpose. Done when the diff has been reviewed and every override maps to a line in the brief.
Add language strings and theme settings
The developer adds language strings for new labels, footer text and logo alt text, and exposes the settings an administrator should be able to change, such as logo upload, primary color and footer links. Keep brand text in language files so wording can be changed without code edits. Done when a language string check shows no missing strings for the theme and an administrator can change each exposed setting and see the change on the dev site.
Test the theme across page types and keyboard input
The QA lead runs a scripted pass across the page types learners and teachers use most: the dashboard, a course page, an activity page, a quiz attempt, a gradebook view, the login page and a mobile viewport. Include a keyboard-only pass through a course page, checking that focus order follows the layout and that focus indicators stay visible. Log defects against the brief's requirements and retest after each fix. Done when every page type has been signed off on the target release and the test record is attached to the release ticket.
What makes a Moodle theme project take longer or cost more
This table lists the main drivers of effort in a Moodle theme project and how each one can be kept under control. Read each row as a scope decision: the cost rises with the number of items agreed, so fixing the list early is the most effective lever. Most projects that overrun do so because pages, languages or sites were added after the design was approved.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of templates overridden | Each overridden Mustache template or renderer must be copied, edited and retested after every Moodle upgrade, so overrides are the main recurring maintenance load. | Override only what the design cannot achieve with SCSS, settings and presets. Review the override list at each design sign-off and record the reason for every one. |
| Depth of navigation and dashboard changes | Navigation and dashboard work touches many roles and layouts. From Moodle 5.3 onward, the Classic theme is no longer in core, so the team must check how navigation and dashboard components behave in the current theme. | Agree a fixed list of navigation states and dashboard views for each role. Treat any new view as a change request with its own estimate. |
| Course formats and activity types needing styling | Each course format and activity type has its own markup and styles, and each one needs a test pass for layout, colour contrast and mobile view. | Style the core formats and the activity types in active use only. Leave rarely used plugins on the default styling and document that decision. |
| Accessibility conformance target | A stated conformance level sets how many pages, components and states must be tested with assistive technology and how many fixes are needed. A vague target such as accessible in general tends to expand during testing. | Name the conformance level, the pages in scope and the test tools in writing before design starts. Ask the partner to confirm which checks are included in the fixed scope and which are extra. |
| Number of languages and right-to-left support | Each language adds translation strings, font and spacing checks and layout tests. Right-to-left support changes the layout direction across the theme, not only the text. | Limit the first release to the languages required at launch. Confirm whether right-to-left support is in scope and list the locales to test. |
| Number of sites or tenants sharing the theme | A theme shared by several sites needs a common base, per-site settings and a test run on each site, which adds configuration and regression work. | Build one base theme with site-level settings and presets rather than separate themes. Agree which sites receive each release and in what order. |
| Integration with SSO and portal pages | Login pages, identity provider screens and portal pages outside Moodle must match the theme. Each external page adds design and testing work and depends on other teams' release dates. | List the login and portal pages in scope and confirm which ones the identity team controls. Keep external pages on the brand standard without custom code where possible. |
| Release gap between current and target Moodle version | A large gap means more templates, APIs and styles may have changed, and the theme may need rework before it runs. Changes in PHP and database requirements also affect the upgrade path. | Check the theme against the target release early, using the release notes for each version in the gap. Plan the theme port with the platform upgrade rather than after it. |
How the theme differs on a single server, a clustered deployment and an air-gapped network
On a single server, the web node, PHP and moodledata all sit on one host. Compiled theme CSS is written to local disk and served from the same place it was built, so a theme change is visible as soon as the cache is refreshed. The main risk is that the change appears to work while the web server still points at the wrong directory or the cache is stale.
- Build location: Compile SCSS on the server or on a staging copy with the same PHP and Node.js versions, then confirm the output lands under the site's own directories.
- Cache location: Compiled CSS and theme revision data are held in the Moodle cache area under moodledata, so the site controls those files directly.
- Invalidation: Purging the theme cache from the administration pages, or changing the theme revision, forces a fresh compile on the next page load.
- Dependencies: Node.js and the npm packages required by the build are installed on the same host, usually once per release, and should be pinned with a lock file.
- Asset path: From Moodle 5.1, the web server document root must point to the /public directory. Confirm the asset path on your web server, or theme files may fail to load or expose directory listings.
Before each theme release, test the compile and cache purge on a staging copy that uses the same web server configuration as production.
When several web nodes sit behind a load balancer, each node must serve the same compiled theme. Moodledata is normally on shared storage, so a file written by one node is readable by the others, and cache state must be consistent across nodes. A build run separately on each node can produce different output, so most teams compile once in a build pipeline and deploy the same artifact everywhere.
- Build location: Compile in a single build job, then deploy the output to all web nodes so every node serves identical CSS.
- Cache location: Compiled CSS sits in moodledata on shared storage, and the shared cache stores used by the cluster must be confirmed in your setup with the Moodle documentation for multi-node sites.
- Invalidation: A cache purge or theme revision change must reach every node. Test that a change made through one node appears on all nodes within the same request cycle, and check for stale CSS served from a node's local cache.
- Dependencies: Node.js and npm packages are fetched by the build pipeline from your package registry or mirror, and the web nodes do not need build tools installed.
- Asset path: Confirm on each node, and on the load balancer health checks, that the document root points to /public for Moodle 5.1 and later.
Before a theme release, run a rolling deployment on a test cluster and confirm that every node returns the same stylesheet version.
On an air-gapped or restricted network, the build cannot reach public package registries during compilation. Every SCSS dependency must be available inside the network before the build starts, so the team needs an approved way to bring packages in and a clear record of what was brought in. Compilation may happen inside the network with an internal mirror, or outside it with only the compiled output transferred in.
- Build location: Choose between compiling inside the network with approved packages or compiling in a connected environment and transferring the compiled CSS and assets through your approved media process.
- Cache location: Compiled CSS is cached in moodledata on the restricted host or cluster, the same as in other models, so cache paths should be checked after each transfer.
- Invalidation: Purge caches after importing new theme files, and record the theme revision so that auditors and administrators can match a running site to a specific build.
- Dependencies: Use an internal npm registry mirror or a pre-downloaded, versioned package set with checksums. Confirm with the build tooling vendor exactly which package sources the build fetches, including any fallback to public sources.
- Asset path: Confirm the document root points to /public on Moodle 5.1 and later, and that the web server does not attempt to fetch anything from external sources when serving theme files.
Before accepting a theme build into the restricted network, confirm the dependency list, checksums and asset paths in a rehearsal that has no outbound internet access.
Keeping theme code, assets and third-party scripts under control
A Moodle theme runs with the same trust as the rest of the server, so its code, the assets it loads and the settings that feed it all deserve the same review as core changes. The cards below cover where theme risk enters the site and what the team should check before and after each change.
Review theme code like server code
Theme PHP, renderer overrides, mustache templates and JavaScript execute inside the Moodle application with its database and file access. Treat every change as a code change: peer review, a named owner, and a check that templates do not print unescaped user data. Ask the theme developer which parts are custom and which come from a parent theme, because inherited code still runs on your server.
Vet fonts, analytics and embedded scripts
Fonts, tag managers, analytics snippets, chat widgets and video embeds each send requests to a third party and can read page content. List every external origin the theme loads, record the business reason for each, and remove anything without an owner. Where practical, self-host fonts and icon sets so learners' browsers do not contact outside servers on every page view.
Adjust content security policy for theme scripts
A content security policy restricts which scripts, styles and images a page may load. Theme changes that add inline scripts, new CDNs or external stylesheets can be blocked after go-live or force weakening the policy. Agree the allowed sources with the theme developer before build, test the pages with the policy enforced, and prefer hashed or nonce-based exceptions over broad wildcards. Confirm current Moodle support for these settings in the release you run.
Control uploaded logos and images
Administrators upload logos, favicons and background images through theme settings, and those files are served to every visitor. Restrict accepted file types to the image formats the theme needs, set a maximum file size, and check that the stored file is served with a safe content type. Confirm which validation Moodle performs for each setting and which checks the web server or a file scanning step must add.
Sanitize HTML in theme settings
Some theme settings accept free-form HTML, for example footer text, custom headers or announcement banners. Anyone who can write that field can inject script into pages that other users see, including administrators. Limit these fields to trusted roles, use the HTML cleaning Moodle applies to formatted text, and test with script and event-handler payloads before each release. Where a setting does not need markup, use plain text.
Restrict who can change theme settings
Theme settings change the appearance of every course and login page, so they should not sit with general site administrators by default. Assign the relevant capabilities to a small named group, separate design approval from technical deployment, and log who changed which setting. Ask the partner to document the role model as part of the handover.
Track theme changes in version control
Keep theme source, SCSS, templates, language strings and build configuration in a repository with reviewed merges and tagged releases. Record the theme version alongside the Moodle version it was tested against, so a later core upgrade can be traced to a known theme state. Store the compiled output and settings export with the release record, and make rollback a documented step.
How to test a Moodle theme before users see it
A Moodle theme should pass a fixed test plan before any user sees it, and the plan should cover the screens where a theme mistake does the most damage. Start with visual regression. Capture baseline screenshots of the dashboard, a course page, a representative set of activity pages (quiz, assignment, forum and a SCORM or H5P package if you use them), the grader report, and the main administration screens such as site administration and the theme settings page. Run the same captures after every change to the child theme's SCSS, templates or renderer overrides, and review pixel differences by hand. Automated diffing tells you that something moved; a person decides whether the movement is a defect.
Accessibility checks need two layers. Automated scanners catch a useful share of issues such as missing alternative text, low colour contrast and missing form labels, but they cannot judge whether a focus order makes sense or whether a custom menu announces its state. Choose the accessibility standard your organization has committed to, record which success criteria it maps to, and then run manual passes: a keyboard-only walk through login, navigation, a quiz attempt and grading, and a screen reader pass with at least one common reader on the browsers your users run. Log every finding against the criterion it affects so the result can be shown to an auditor or procurement team.
Responsive checks should use the devices your learners actually use, not a generic list. Test narrow phone widths, tablets in portrait and landscape, and a laptop at a reduced zoom level, since zoom is a common setting for users with low vision. Confirm that the navigation drawer, course index, block regions and long activity titles remain usable at each width. Then verify caching. After a theme change, purge all caches from the administration screens, confirm the CSS is rebuilt from the current SCSS, and check that the browser receives the new stylesheet and not a cached copy. Also check that the theme revision or the CSS cache key changes when the theme is updated, so stale styles do not persist on some nodes.
The failure test is the one most teams skip. Deliberately break a template, remove a required image or font file, and introduce a syntax error in one SCSS partial in a staging copy. Your pipeline or pre-release checklist should detect each failure before release, through a failing build, a failing render test or a visible check on the staging site. Next, confirm safe fallback. Remove the child theme from a copy of the site and confirm that the parent theme loads without errors. Then change the parent theme version in a sandbox and check which overrides still apply and which templates have drifted. Record the results, because they decide how much maintenance your child theme will need.
The pre-upgrade test starts when a new Moodle release reaches release candidate status, not after the upgrade is scheduled. Run the full plan above against a copy of production with the new core version, using the PHP and database versions that release requires. Check your child theme against the changed templates and renderers in the release notes for that version, and confirm that the document root and web server configuration still serve the theme assets correctly. Ask your theme developer or partner to state in writing which tests were run, which findings were fixed, and which were accepted as known issues. Keep this report with the upgrade plan so the next release starts from a documented baseline.
Questions teams ask before building or adapting a Moodle theme
Is a child theme enough for a Moodle brand refresh?
A child theme is often enough for colours, fonts, logos, favicons and light layout changes, but it does not cover every page. A child theme inherits the parent's templates, language strings and SCSS, then overrides only what you change. Once you need new page layouts, changed course or dashboard templates, or new navigation behaviour, the override list grows and each override must be tested after every Moodle release. Before deciding, ask for a list of the templates and pages you expect to change, and confirm which parent theme your target Moodle version ships. A written scope should name those templates and pages so you can see where a child theme stops being enough.
How does removing Classic in Moodle 5.3 change theme work?
If your theme was built on Classic or depends on its templates, you need a supported parent theme before you move to Moodle 5.3, which removes the Classic theme from core. Check three things: which parent your theme inherits from, whether any plugins override Classic templates, and whether your overrides touch navigation, which has moved to React in newer releases. Test the theme on a staging copy of 5.3 with your real course content and roles. Sites upgrading to 5.3 must already run Moodle 4.4 or later, so an older theme may need work in two steps. Ask the partner to list every Classic dependency found in the audit before estimating the rebuild.
Do we need our own Moodle developer or can we hire one for a fixed scope?
You can hire a partner for a fixed scope, but you still need an internal owner who signs off design, accessibility decisions and content acceptance. The partner builds the theme against a written scope, and your team confirms each milestone. Keep at least one administrator who can install the theme, clear caches, and read the change log after upgrades, because a fixed-scope project ends at handover. Ask whether the delivery includes documentation for your administrators, a version-control copy of the theme, and a support option for upgrades. Most engagements are fixed-scope and agreed in writing before work starts, so the scope document is where ownership and handover are settled.
What does a Moodle theme project need from our side?
The project needs decisions and access more than it needs code from you. Prepare these items before work starts:
- Brand assets: logo files in vector format, colour values, font files with licence terms, and any brand guidelines.
- Accessibility target: the standard and level you must meet, plus who signs off on accessibility testing.
- Test users: named people for each role, such as student, teacher, manager and administrator, who can review pages and report problems.
- Staging access: a staging Moodle site with administrator rights so the theme can be installed, tested and reset.
- Inventory: current theme, plugin list, custom templates and integrations.
Without these, reviews slip and rework rises, so ask for a dated list of what you must provide in the written scope.
How do theme upgrades fit the six-monthly Moodle release cycle?
Moodle ships major releases in April and October and minor point releases every two months, so a theme must be retested on a regular cadence. Each major release can change parent templates, SCSS variables or core APIs that your theme overrides. The practical approach is to keep overrides small, follow the parent theme's documented extension points, and run a staging upgrade before each production upgrade. Long-term support releases give you a longer window on one line, but security support still ends on fixed dates, so check the support table for your version. Moodle 5.1 also moved the web server document root to the /public directory, which affects how the theme is deployed. Ask the partner how upgrade testing and theme fixes are scheduled and billed.
What drives the cost of a Moodle theme project?
The cost follows the written scope, so the main drivers are scope size and risk. The number of templates and page types you change is the largest factor, followed by the depth of navigation work and any React-based changes. The accessibility target adds test rounds and remediation, and brand asset readiness affects how many review cycles are needed. Plugin overrides, custom plugins and integrations add work because each must be tested after upgrades. Costs fall into one-time build work and recurring work such as upgrade testing, fixes after each release and maintenance. Ask every quote to show the templates and pages covered, the accessibility target, the number of review rounds, the test environments, and which upgrades are included or priced separately.
What to hand over and monitor after the theme goes live
A theme is only maintainable if the people who inherit it can see what was changed, why it was changed, and how to undo it. Before the project closes, ask for a handover package that contains the source repository with the theme code and step-by-step build instructions, so your own administrators or a future partner can rebuild the compiled CSS and JavaScript without the original author. The repository should hold the child theme only, with no edits to Moodle core, and the build instructions should name the Node and tooling versions used. Confirm that the package builds from a clean checkout before you accept it.
Ask for a register of every overridden template, with one line per file explaining the reason for the override and the Moodle release it was written against. This register is the first thing a reviewer needs when a core template changes in a future release, because each override is a point where the child theme can silently drift from core. Pair it with SCSS variable documentation that lists each brand variable, its default, where it is used, and which core variables it replaces. A reader should be able to change a brand colour or font without searching the entire stylesheet.
The handover should also include a style guide and component inventory: buttons, cards, course tiles, navigation items, forms and notification patterns, with the markup or Mustache template each one uses. Accessibility test results matter here as much as visual sign-off. Request the test method, the tools and assistive technologies used, the pages covered, and a list of open issues with severity and owner. Be clear that these results are the delivering team's testing, not an independent audit. If your organization needs formal conformance evidence, plan that as a separate assessment.
Write a rollback procedure before the first production change is retired. It should state how to switch the active theme back to the previous version or to Boost, where the previous build artifacts are kept, and which cache purge commands are needed. Test it on staging. For operations, the main recurring task is a theme review against each Moodle release. Moodle issues minor point releases in February, April, June, August, October and December, and major releases in April and October. Schedule a short review of the register of overrides and the open accessibility issues after each of these point releases, and run the checklist before any site upgrade goes to production.
Confirm whether ongoing theme support is covered by a retainer or billed separately, and what it includes: template changes after core updates, accessibility fixes, and response times for production defects. Ask for the review checklist and the support terms in writing, so that the first post-upgrade problem does not become a scope argument. Also agree who owns the repository and the build pipeline after handover, and who is authorized to deploy the theme to production.
How DeployOpen works on this
DeployOpen scopes Moodle theme work in writing before build starts, then builds the theme in your own infrastructure as a child theme so core upgrades stay manageable. Each engagement ends with documented handover to your team and an agreed route for ongoing support.
How we scope
- The written scope names the brand assets, page layouts and Moodle pages the theme will cover before any code is written.
- We confirm your target Moodle release, since theme templates and navigation behavior differ between supported versions.
- We agree which accessibility checks apply and which assistive technologies and browsers the theme must be tested against.
How we build
- We build the theme as a child of a supported core theme, keeping overrides to templates, language strings and SCSS that you actually need.
- Templates, SCSS and JavaScript changes are reviewed against the navigation and page layouts used by your courses and admin pages.
- Accessibility testing covers keyboard navigation, color contrast and screen reader behavior on the pages your learners and teachers use most.
How we hand over
- You receive the theme code in your own repository, with a readme covering installation, the document root and the override inventory.
- The handover documents each template override and the reason for it, so future upgrade reviews can judge whether it is still needed.
- Your administrators and theme maintainers get a walkthrough of the build, the test results and the steps to reproduce a deployment.
How we support
- Ongoing support for the theme is available as a retainer, covering reviews after Moodle releases and fixes to theme regressions.
- Support scope is set in writing, including which Moodle versions are covered and how change requests are logged and priced.
- Where a new Moodle release changes theme templates or removes a core theme, we agree the upgrade work as a separate scoped item.
