Recent changes
Wednesday November 04 2026
-
Theme assets, the packer and CSP Updated Markdown page
Load a theme's stylesheets, scripts, images and fonts the way Exponential expects - frontend lists, ezcss_load and ezscript_load, the ezjscore packer, ezimage - so they are fast and pass a CSP.
-
Themes and siteaccesses Updated Markdown page
Which site uses which theme - SiteDesign, AdditionalSiteDesignList and StandardDesign per siteaccess, themes that build on other themes, one theme for several sites, and how to see the chain a siteaccess really uses.
-
Themes are extensions Updated Markdown page
Why an Exponential theme is packaged as an extension with a design folder, what that gives you over editing the kernel's design folders, and how a theme relates to designs, siteaccesses and the design chain.
-
Where the designers' help continues Updated Markdown page
The designer help goes much further than this book: the template language, theme design, theme extensions, distribution, sales and life cycle. A map from each chapter of Part 6 to the pages that continue it.
-
Part 7: Releasing your extension Updated Markdown page
Part 7 of the book: release an extension so others can rely on it - version numbers, permanent tags, metadata bumps, Composer and Packagist, changelogs, GitHub releases, packages, tests, and a checklist.
-
Announcing a release Updated Markdown page
Tell the people who use your extension about a release - the GitHub release itself, share.exponential.earth, the project page on projects.exponential.earth, ezpedia - what to write, and what to leave out.
-
Bumping ezinfo.php and extension.xml Updated Markdown page
Every release raises the version inside the extension - ezinfo.php, extension.xml, and composer.json or filelist.md5 where present - to exactly the release's number, in the commit the tag points at, never after.
-
Changelogs Updated Markdown page
Write a changelog users can act on - grouped by Added, Updated, Fixed, Removed and Renamed, assembled from the commit messages since the last tag, upgrade notes first - and keep an old extension's changelog.
-
Choosing the next version number Updated Markdown page
Look up what is already published before you pick a version - fetch the tags, sort them as versions, compare with GitHub releases and Packagist - so you never reuse a number, with the commands and the sorting trap.
-
Composer and Packagist Updated Markdown page
Register an extension on Packagist so sites can install it with composer require - the composer.json it needs, submitting the repository, how versions come from tags, and how users install and update it.
-
filelist.md5 and the upgrade check Updated Markdown page
Extensions that ship share/filelist.md5 are read by the admin's file consistency check; every release must refresh the checksums of changed files, or the check lists them as modified. How to keep it right.
-
GitHub releases and release notes Updated Markdown page
Turn a pushed tag into a GitHub release - title, notes from the changelog, what to attach and what not - with the gh command and the rule that a published release is never edited to change what it delivers.
-
Packages (.ezpkg) and the package creator Updated Markdown page
The other way to distribute: .ezpkg packages made with the package creator in the administration or ezpm.php - extension exports, content class exports, site styles - and when to use them next to Composer.
-
Tags and releases are permanent Updated Markdown page
Why a pushed tag and a published release can never be moved, replaced or re-cut - Packagist and every installation keep what they first saw - and what to do instead when a release went out wrong.
-
Testing before a release Updated Markdown page
What to run before you tag: lint on the oldest and newest PHP, the extension's tests, metadata checks, a clean install from the repository with Composer, and every feature by hand - a tag cannot be corrected.
-
The maintenance life cycle Updated Markdown page
An extension's life from the first release to the last - supported versions, following PHP and kernel releases, deprecating before removing, branches for old versions, and ending maintenance honestly.
-
The Packagist webhook Updated Markdown page
When Packagist shows an old newest version although the tag is on GitHub, the repository is missing its Packagist hook. How to see that, how to set it up, and how to bring the package up to date once.
-
The release checklist Updated Markdown page
The whole release of an extension on one page, in order - choose the number, bump the files, changelog, test, tag, push, GitHub release, Packagist, announce - each step linked to its chapter.
-
Versioning rules Updated Markdown page
What the numbers of an extension's version mean, the rule that the last position keeps counting (1.0.9 is followed by 1.0.10), when to raise a higher position, and how Composer reads the numbers.
-
Part 8: Reference of built-in features for extension authors Updated Markdown page
Part 8 of the book: a reference of the kernel classes, template features, settings, commands and directories extension authors use most, with signatures taken from the source and links to the full documentation.