Maintenance life cycle
Keeping themes and extensions alive: upgrades, compatibility, security fixes and retirement.
25 pages
- The maintenance life cycle: start here The map for keeping a theme alive after its first release - following Exponential releases, upgrade testing, per-release accessibility, CSP and performance audits, security fixes, deprecation, end of life, handover…
- Upgrade testing, step by step The routine for testing a theme against a new Exponential release - update the test installation, clear caches, walk the page list, compare overrides, check the error log, audit, and record the result.
- Following Exponential releases Where to watch for changes that affect a theme - the changelogs in doc/changelogs, release tags and GitHub releases of the repository, the upgrade notes in doc/eng-us/bc, project news and RSS - and a weekly routine.
- A compatibility matrix Keep a table of which theme versions were tested with which Exponential, PHP, server engine and database versions, and the browsers and widths you check - how to fill it honestly and where to publish it.
- PHP version compatibility Keep a theme's PHP code (operators, modules, classes) working on every PHP version Exponential supports - PHP 8.0 is the oldest, PHP 7.4 usable without support - with php -l per version, what typically breaks, and how…
- Declaring compatibility Tell users and tools which Exponential and PHP versions a theme release works with - composer.json require, the README's requirements, extension.xml dependencies and the release notes - consistently.
- An upgrade test environment Set up a place to test a theme against new Exponential and PHP versions - a separate installation installed with Composer, demo content, the theme as a Git checkout, and a way to reset it - never a live site.
- Comparing your overrides with the standard templates Find out whether the standard templates you copied into your theme changed upstream - list your copies, diff them against the new release, and merge fixes (especially escaping and accessibility fixes) into your versions.
- JavaScript library upgrades (jQuery 4, no YUI) Bring a theme's JavaScript up to date with the libraries Exponential ships - jQuery 4.0.0 with Migrate and jQuery UI 1.14.2 through ezjscore, YUI removed - what to search for, what to replace, and how to test.
- Removing inline scripts and styles Move a maintained theme toward a strict Content Security Policy - find inline script blocks, event handler attributes, javascript: links and style attributes, move them into files and data attributes - following how the…
- A CSP audit for every release Check before each release that the theme still works under a strict Content Security Policy - report-only mode on a test siteaccess, the browser console, a grep for inline code, and external resources.
- A performance audit for every release Check that a release did not make the theme slower - page weight, number of requests, image sizes, layout shift and largest contentful paint on the page list - and compare with the previous release.
- Security fixes in themes The security problems a theme can have - unescaped output, output in the wrong context, inline script injection, links opening other sites, exposed settings - how to find them, and a real fix from a published theme.
- Handling security reports What to do from the moment a security report arrives - acknowledge, reproduce privately, assess, fix, release, credit - and what to do when the report arrives in a public issue.
- Publishing a security release Release a security fix for a theme - fix, version, tag and release first, then describe the problem plainly with affected versions and the action users must take, and tell the channels where your users are.
- Keeping dependencies up to date Keep the libraries, fonts, icon sets and extensions a theme depends on current - an inventory, where updates are announced, testing an update, and checking licenses again.
- A deprecation policy Decide and publish how your theme retires settings, templates, view modes and operators - announce, keep working, warn, remove in a later step - so users have time to adapt.
- Deprecating a setting or a template Step by step - rename a theme setting while still reading the old name, replace a template while keeping an include of the old one, and remove both later - with the changelog entries for each step.
- Breaking changes and the next major version When a theme change forces users to act - removed templates or settings, a raised minimum version, a redesign - group it, move a higher version position deliberately, write an upgrade guide, and keep the previous line…
- Transferring the repository and the Packagist package Move a theme's GitHub repository and Packagist package to a new owner without breaking installs - GitHub's transfer and redirect, the package name question, Packagist maintainers and the update hook.
Documentation license
This documentation is free documentation, licensed under the GNU Free Documentation License 1.3 or later.
Exponential Copyright © 1998-2026 Exponential Foundation and 7x