Closing the Gaps: Making Joomla Harder to Ignore
Part 2: Finding the Gaps
Written by: Jason Crimmel

In Part 1, I argued that Joomla! can have a strong Core and still be harder to choose when ordinary project requirements are not covered well enough by the ecosystem around it. That leads to the next question: if the gaps matter, how do we actually find them?

I don't think an empty category in the Extension Directory is enough to call something a gap. A meaningful gap is not simply a product that Joomla! does not have. It is a place where real work keeps becoming harder than it should be, often enough that Joomla! itself becomes harder to use or recommend.

Start with what people are actually trying to do

What I have learned to watch for is repetition: the same awkward workaround turning up in projects that otherwise have little in common. Finding the gaps is less about inventing ideas than learning to notice where the same friction keeps returning.

The question makes more sense to me when I start with the job rather than the feature list. Real projects do not arrive as lists of extension names. They arrive with a job that somebody needs the site to handle.

A gap often becomes visible when Joomla! gets that job most of the way there and then stops. The site may already know who the user is and what that person is allowed to do, yet completing the task still requires staff intervention or a trip into another system. That last awkward step can tell us more than the name of any missing feature.

This is why I think it is useful to follow the workflow rather than start with the software. Watch what the person is trying to accomplish from beginning to end. The interesting point is where a routine process suddenly becomes fragile, manual, or dependent on knowledge that only the person who built the site possesses.

That has changed the question I ask. Instead of asking whether Joomla! has a particular feature, I ask whether the person can complete the actual job cleanly. If the answer changes halfway through the workflow, that transition is worth understanding.

Sometimes I follow the workflow and realise there is no gap at all. An outside service may genuinely be the better architecture, or the requirement may be so specialised that custom development is the right choice. Finding gaps is not about forcing every activity inside Joomla!. It is about recognising when a compromise has become the normal answer to an ordinary problem.

Listen for the sentence after "but"

One of the simplest signals is a sentence many of us have heard in one form or another: "Joomla! can do it, but..."

What follows "but" tells us where the compromise lives. Perhaps the project depends on custom code nobody wants to own long term, or perhaps the only useful extension stopped moving several Joomla! generations ago. In other cases, the workflow simply leaves Joomla! before it is finished. Different endings, same warning: the platform gets close, and the last step still has to be improvised. So, many times, the words after "but" are often the most revealing.

Of course, not every "but" is a gap. Joomla! will always encounter unusual requirements that belong in custom work. I start paying closer attention when the same qualification keeps appearing in unrelated projects or from people who reached it independently.

I pay particular attention to support conversations because people usually describe the problem in front of them, not the condition of the ecosystem. Someone trying to upgrade may discover that one dependency has no path forward. Somewhere else, an agency may be searching for a replacement because the old workaround can no longer be justified. Neither conversation proves a gap, but each tells us where to look. When the same problem keeps being described from different directions, the pattern becomes harder to dismiss.

Look where the same friction keeps returning

What gets my attention is when the same awkward answer turns up somewhere else. An agency may discover that it has custom-built essentially the same workaround for several clients. Months later, support questions can reveal that users are struggling with the same weak point for the same reason. By then the issue is no longer just one project's inconvenience; it is a pattern worth investigating.

This is also why I think user groups matter. They put people in the same conversation who might otherwise never compare notes. One person may describe a problem a developer has never encountered while somebody else in the room has been dealing with it for years. That exchange does not prove the ecosystem needs a new extension. It simply makes repeated friction easier to see. For me, repeated is the key word. One request tells us what one person needs. Recurrence tells us where to start paying closer attention.

A solution can exist and the gap can still be real

Part 1 touched on ageing extensions, but I think this deserves more attention because it changes what a gap can look like. Sometimes nobody forgot to build the solution. The solution existed, people used it, and Joomla! moved forward while that part of the ecosystem did not.

I was reminded of that at the Joomla! London User Group meeting on 15 September 2026. I had joined mostly to listen, and Hannes Papenberg was demonstrating a process for bringing an older Joomla! 3 version of an extension towards Joomla! 6 with Rector/JRector, PHPStan and JoRobo. The tooling was interesting, but the larger point stayed with me: a useful capability can disappear from practical use even though the code once existed and may still exist somewhere today.

It gave me another version of that "but" sentence: "Joomla! can do it, but the extension that does it is stuck on Joomla! 3."

I don't think an old extension is automatically a gap. Software reaches the end of its useful life, and sometimes that is exactly what should happen. The picture changes when people still depend on the capability after the maintained path has ended. If a site cannot move forward because one extension cannot move with it, that could give a reason to look at another CMS.

I also don't mean that every site has to move the moment a newer Joomla! release appears. Choosing to remain on a supported release for a while can be a sensible operational decision. Being unable to leave an old release because one dependency creates a hard ceiling is different. Sometimes the thing keeping a Joomla! site in the past is not Joomla! itself; it is one extension the site cannot afford to lose.

What encouraged me about the Joomla! London presentation was how much easier some of this work has become. Modernisation no longer has to mean manually rewriting every old pattern one line at a time. Refactoring tools and static analysis can work alongside automated testing and AI-assisted development, reducing much of the repetitive labour involved in bringing useful code forward. That does not create an obligation to preserve every old extension, but it does make abandonment less final than it once was.

That meeting also reminded me not to confuse finding a gap with deciding how to close it. A stranded extension might be worth modernising rather than replacing. Another project may need a clean migration path instead. Deciding what should be done comes later; at this stage, the important discovery is that a capability people still need has become difficult to use on current Joomla!.

Technically possible is not practically solved

I have also become wary of the phrase "Joomla! can technically do that." Part 1 argued that technical possibility and a practical solution are not the same thing. I think that distinction becomes even more useful when we are trying to recognise weak spots in the ecosystem.

After more than twenty years with Joomla!, I have seen enough to know that a skilled developer can make it do a remarkable amount. Joomla!'s flexibility, some site-specific code and an outside service can often make a difficult workflow work. That proves the platform is capable. It does not automatically mean the next agency can offer the same workflow without rebuilding the solution for itself.

The test I keep coming back to is what happens after the original developer steps away. If the setup cannot survive updates or failure without somebody remembering how all the pieces fit together, the technical capability may be real while the ecosystem answer is still weak.

That is also why "an extension exists" is not enough for me. A product can solve the headline feature and still leave the surrounding workflow awkward enough that the original problem remains. Compatibility with the current Joomla! version matters, but compatibility alone does not tell us whether the solution is usable or maintainable in the way real projects need.

I don't think the bar should be "someone clever can make it work." The bar should be whether an ordinary project can depend on the answer without turning the workaround itself into part of the project.

Nobody sees the whole ecosystem

The more I think about finding gaps, the less I believe any one developer or company can do it well alone. We each see Joomla! from the part of the ecosystem where we spend our time, which means we also inherit blind spots from that position.

My own view is incomplete too. Agencies encounter the pressure when requirements meet budgets and deadlines, while users feel the consequences after the handoff. Developers and support teams see recurrence over time, and a user group can bring those observations together in a way that exposes connections none of us saw separately.

That is one reason I value hearing from people in other parts of the community. A problem that looks unsolved from one corner may already have a strong answer somewhere else. Other times, an old solution may still be keeping real sites alive even though most developers have stopped thinking about it. Comparing those experiences helps distinguish an actual absence from a problem that is simply hidden from view.

The more I think about it, finding gaps feels less like a hunt for product ideas and more like a community habit. The useful contribution may be as simple as explaining where a project keeps breaking down and why the usual workaround is no longer good enough. Once the problem is visible, the people best positioned to help have a chance to recognise it.

Sometimes the best outcome is no new extension at all. The important work may be carrying forward a capability that should not have been lost. In another case, the supposed gap may already be solved and the real problem is helping people find that solution. What matters first is making the friction visible enough to understand what is actually happening.

Finding a gap is not the same as proving it matters

There is one problem with looking for gaps. After a while, you can start seeing them everywhere. A feature request can be interesting without representing a wider problem, and an abandoned extension does not automatically need a successor. Observation is only the beginning.

Finding one only tells me where to look next. It does not tell me whether the problem affects enough people to justify serious work, whether the current compromise is actually harmful, or whether somebody else has already solved it well. Those are questions of importance and judgement rather than discovery.

Part 3 – Which Gaps Matter? will focus on the next, harder question. Once we have found a gap, how do we decide whether it is important enough to solve?