Two upgrades broke compatibility and both cost users

The First Break: From 1.5 to the 2.x Series

Joomla 1.5, released in January 2008, was the release that made the project credible as a platform rather than a hastily named fork. It introduced a proper MVC (Model-View-Controller) architecture, a templating engine that separated logic from presentation, and a plugin event system that gave extension authors real integration points. The ecosystem responded: by the time 1.5 reached the end of its long-term support period, thousands of extensions had been written specifically for it, and thousands of installations were built around those extensions.

The 2.x series began with Joomla 1.6 in January 2011, followed quickly by 1.7 and then 2.5, which became the designated long-term support release in January 2012. The architectural changes between 1.5 and 1.6 were substantial enough that extensions written for 1.5 did not run on 1.6 without modification. The database schema changed. The ACL (access control list) system was redesigned from a flat hierarchy to a proper nested-set model. APIs that extension authors had relied on were deprecated or removed.

None of this was irrational. The 1.5 ACL was widely criticised as inadequate for anything beyond simple public-private splits, and the new system gave site builders genuine permission granularity. The framework improvements were real improvements. But the upgrade path required extension authors to act, and not all of them did. Commercial developers who had sold 1.5-era components and received no further revenue from those sales had little financial incentive to rewrite for 2.5. Free extensions maintained by individuals who had moved on simply went dark. Site owners who depended on a component that was never ported faced a choice: rebuild the site with different extensions, or stay on 1.5.

Many stayed on 1.5. The release reached official end-of-life in April 2012, which meant no further security fixes from the core team, but the installed base did not vanish. Years later, vulnerability researchers and the Joomla Security Strike Team ↗ were still finding 1.5 installations in the wild, still publicly accessible, still running without patches. The 1.5-to-2.5 break did not just slow adoption of the newer version; it created a substantial population of abandoned sites that became targets.

There is a governance lesson embedded here that goes beyond release engineering. The project had no mechanism to compel extension authors to migrate, and no resources to do the migration work for them. The extension directory — the Joomla Extensions Directory, which had become the primary distribution channel for third-party code — carried compatibility flags, but a flag that says "not tested on 2.5" does not help a site owner who needs the functionality and has no alternative. The directory's listing rules shaped what users could find; they could not shape what extension authors chose to build.

The Second Break: From 3.x to 4.0

The 3.x series launched in September 2012 and eventually became the longest-running major version in Joomla's history. Joomla 3.10, released in August 2021, was the final 3.x release and served simultaneously as the end of the line and as a migration bridge, with a built-in tool intended to ease the move to Joomla 4.0, which had shipped the same month.

Joomla 4.0 was a genuine modernisation. The codebase adopted a dependency injection container, namespaced PHP following PSR-4 conventions, Bootstrap 5 for the administrator interface, and a Web Services API built on JSON:API specification. The minimum PHP requirement moved to 7.2.5, later 7.4, cutting away hosting environments that had been coasting on ancient server configurations. By any technical measure, 4.0 was a more defensible platform than 3.10.

It was also, again, a compatibility break. Extensions that used the old non-namespaced class structure, or that relied on deprecated core methods, required rewriting. The MooTools JavaScript library, which had been Joomla's bundled JS framework since the 1.5 era, was finally removed; extensions that had used MooTools APIs directly broke without modification. Template overrides — the feature that had made Joomla workable for agencies because it allowed output customisation without touching core files — required review because the underlying HTML structure in many views had changed.

The architectural changes between 1.5 and 1.6 were substantial enough that extensions written for 1.5 did not run on 1.6 without modification.

The extension ecosystem in 2021 was not the same organism it had been in 2012. The market for commercial Joomla extensions had contracted relative to its mid-2010s peak, in part because the CMS market overall had consolidated around WordPress and, at the enterprise end, Drupal. Developers who might have maintained a Joomla extension portfolio had in some cases moved on. The result was a replay of the 1.5-to-2.5 pattern: some commercial extensions received 4.0-compatible updates promptly, some were quietly discontinued, and some remained listed in the directory long after it was clear that active maintenance had stopped.

Joomla 3.x officially reached end-of-life in August 2023, two years after 4.0 shipped. The two-year overlap was a deliberate attempt to give the ecosystem time to migrate — longer than the window between 1.5 and 2.5 had been in practice. Whether that window was long enough is a matter of record: W3Techs data from 2024 ↗ showed a meaningful fraction of surveyed Joomla installations still running 3.x after its end-of-life date, a pattern consistent with the 1.5 afterlife.

What Both Transitions Share

The architecture behind each break was defensible. The governance around each break was not specifically designed to handle the downstream consequences in the extension economy, and that is the difference that mattered to users.

Extensions that used the old non-namespaced class structure, or that relied on deprecated core methods, required rewriting.

Both transitions assumed that extension authors were a coherent, responsive community with ongoing commercial or personal interest in their codebases. In reality, the extension economy had always included a substantial tail of one-version products: extensions built for a specific purpose, released, and then maintained only as long as the original author needed them. A major compatibility break does not reach that tail with documentation or migration tooling; it simply ends the extension's useful life.

The project's public documentation for both transitions was thorough. Andrew Eddie, one of the architects of the 1.5 framework, had established the technical writing culture that meant API changes were documented rather than quietly introduced. Migration guides existed. The problem was never information; it was the gap between information and action in a volunteer ecosystem where nobody could be compelled to do anything.

Both breaks also demonstrated that a CMS's real vulnerability is often the abandoned install — the site that did not migrate, whose owner has moved on, whose extensions will never be patched. Each release cycle Joomla ran produced some of those sites, and the compatibility breaks accelerated the production rate. That is the cost that appears nowhere in a release announcement and everywhere in subsequent security incident data.