This article is part of a two-part series written as an encouragement for the upcoming discussion about the very bright future of the Joomla project. Be sure to check out part 1 first!

Much of what I share below is born of many conversations with passionate Joomlers. I tend to remember great ideas well and often forget from where they came. If you hear your ideas or voice below, thank you for sharing your creativity and part of your Joomla story with me.

Stay Calm, Release On

If you are a client of interGen or have an existing Joomla website, don’t panic. Joomla 8 is not scheduled for release until mid-October 2029. This follows Joomla’s adherence to a release schedule first adopted in 2014. There is a major “new version” of Joomla released every two years. The two-year release schedule was first applied with the release of Joomla 4 in 2021.

Deconstruction

I took great pains in the first part of this series to talk about the distinctions between a major and minor point release in the semantic versioning of Joomla. I appreciate the patience of the group and of the people for whom, I am sure, semver is old hat.

I belabored the point to lay the groundwork for an idea I have heard discussed for years: during the Joomla installation process, users should be given the choice of installing “Joomla Standard” or “Joomla à la carte” (Joomla-carte?). Joomla Standard would ship with essentially the same basic functionality it currently has.

How many sites are really using com_banners, com_contacts, and com_newsfeeds? If I am generous, there are likely many sites that use one or two of those, but I wager almost none use all three.

The truth is that Joomla ships with all sorts of extensions that are only used a fraction of the time. The problem is that we don’t know which extensions are needed when, and because we don’t know, we just ship everything all the time. A long-time Joomla contributor once created an extension that at least hides all the extras. Check out “Joomla on Diet”, and be sure to click the “Online Joomla’s fat-remover plugin creator” button, for a nice description.

It’s outdated and can only hide the stuff, but it really illustrates how many extensions Joomla actually ships with.

So what about Joomla à la carte? It should ship with the bare minimum—and by that I mean the user manager for ACL and an installer. Everything else would reside as discrete extensions, optionally installable from this fun little corner of the Joomla Extensions Directory. I believe Joomla could run as a platform even without com_content. It’s easy to imagine web apps that don’t require public-facing content.

I do appreciate that it would be an incredibly heavy lift to extract each of the extensions from the underlying web of interdependencies (more on that shortly). However, a four- or five-year plan is the time to dream big.

One final item in this deconstruction of the CMS into its constituent parts: there should be a way to define a suite of extensions in something like Composer or a Dockerfile, in which you state what should be included in your Joomla à la carte installation.

Manifest Destiny

The second idea is really about establishing additional standards around the manifest.xml file that is part of every Joomla extension. In addition to the metadata, file structure, and parameters defined in the manifest, I would create standards around the following:

• Dependencies. This is somewhat an extension of the à la carte discussion above. How would things like tags, categories, or custom fields function in a modular, disarticulated Joomla? What if I have a shipping plugin for a particular e-commerce platform? Having a standardized way to declare the dependency on the platform could be beneficial.
• Changelogs. I know <changelogurl> exists, but should that pull into the admin interface automatically somehow?
• README. Should there be a standard for README.md or README.txt or README.php? I’m not sure about the security implications of different file formats. I know the description is there, but it might be nice to provide the additional context that is often part of a README.
• Agents.md. I’m going to say surprisingly little about AI in this post, but this is one huge exception. A large number of AI coding platforms provide contextual information through an agents.md file. This is an evolving concept, and Anthropic is the one glaring holdout (sticking with claude.md files), but every other major AI provider is embracing this standard.

Creating a standard for its inclusion in Joomla extensions would provide developers with a way to provide context for their extensions to interact with AI.

Again, I appreciate that extension developers can do any of the above already—it would just be nice to have documented standards for the best “Joomla” way to include these items. This would allow website builders an easy way to define their favorite suite of extensions and easily recreated that base package whenever they launch a new site. In theory, this site definition file could even include third party commercial extensions. If you have a developers license key for an extension, you include (in your carefully secured) installer file, press go, and have your new Joomla site set up and ready to go with everything you need, and nothing more.

What Is Joomla?

The idea of stripping back Joomla to the bare essentials of user management and an installer even calls the definition of “Content Management System” into question. It really becomes a platform that allows you to create anything.

I was recently struck by the fact that Joomla has a built-in event scheduler and workflow management as it relates to content workflows. It had me thinking about how close these two feature sets are to tools like make.com, n8n.io, windmill.dev, and sim.ai. I would not have mentioned these tools in this post were it not for having seen two really nice presentations at Joomla Users Group London last week.

What’s missing most from Joomla, compared with the tools above, is a better UX for managing workflows and an easier way to integrate different AI platforms into Joomla. Conveniently, there are Joomla Academy and GSoC projects that are addressing both of these issues very well.

As the Production Team gathers to discuss whatever other feature requests are put forward, the overarching idea is to deconstruct Joomla into a collection of extensions that are coded following a particular set of industry-standard best practices and coding patterns.

It raises the question: what should be supported moving forward as “official extensions”? I’m suggesting AI integrated workflows. People have suggested Joomla needing an official e-commerce solution à la WooCommerce. One of the Joomla Academy projects is centered around an official Joomla standard for Open Graph. Much of this runs afoul of competing with existing commercial Joomla extensions. When, if ever, should Joomla compete head-to-head with extension developers?

The increased flexibility that I’m recommending may complicate these questions. I would suggest that deconstructing Joomla into its constituent extensions would allow Production long-term flexibility to assess, on an ongoing basis, when official extensions should be added and supported and when they can be abandoned (e.g., the gmail authentication plugin). If they were handled as more modular extensions in core, it would allow independent developers to more easily pickup abandoned extensions.

It would also allow sub-teams within Production to focus exclusively on the maintenance of particular extensions.

My one principle for assessing what should be supported as “official” Joomla are any extensions where having a consistent set of expectations greatly enhances the platform’s ability to grow. This solidly includes things like categories, content, tags, and custom fields. I’m surprised that standards for contacts have not led to CRM or project-management solutions. How has Joomla survived 20 years without an established official standard for comments?

These are minor quibbles. Again a more modular Joomla would allow each "official" extension to succeed or fail based on the merits that it brings to the overall ecosystem.

Gratitude

All of the above is shared in the spirit of gratitude for everyone who has contributed to the CMS, past and present. I hope it is an encouragement to those gathering to dream and plan for its future. I am happy to help in whatever ways I am able. I eagerly look forward to hearing how Joomla will move forward together in the decades to come.