How to Choose a Joomla Extension: Spot Abandoned Ones in Five Minutes
The most reliable signal that a Joomla extension is abandoned? If the last stable version was released over a year ago, Joomla’s own security guidance explicitly warns you to consider the project abandoned and "find something else." Do not install old components. It’s that simple.
The One-Year Rule: Joomla’s Own Definition of an Abandoned Extension
If a Joomla extension has not received a new release in the last 12 months, treat it as abandoned. This is the clear, time-based avoidance rule that Joomla itself gives users in its security and performance FAQs. These official Joomla docs state that an extension with no releases in a year should be treated as abandoned and users should “do not install old components.”
Joomla’s FAQs are explicit: extensions that are “out of date or abandoned” are included among the documented bad practices for Joomla security, alongside poorly configured file permissions and having PHP’s register_globals enabled. In other areas, Joomla guidance is more specific. The official Joomla security guide in the user manual stresses the importance of keeping core, extensions, and templates consistently up to date. Sucuri’s Joomla security guide treats developer support and update activity as key signals of an extension’s trustworthiness.
While the one-year rule is clear, Joomla is more coy about the minimum expected update frequency. The best documentation provides is the checklist that if an extension has been dormant for over a year, it should be "considered abandoned and found something else", explicitly discouraging old extensions. There is no specific cadence for releases or patches for third-party Joomla extensions in the latest Joomla core documentation, developer guidelines, or in the Joomla Extensions Directory (JED) developer policies.
Stable Releases, Not Betas: Matching Extension State to Production Risk
Joomla’s official definition of abandoned excludes beta or alpha versions by default: its security FAQs make a point of warning users not to install any development releases on production sites. Do not install beta or alpha on production sites. This puts another quick visual check on developers: do not distribute beta or alpha on production sites.
Joomla documentation also distinguishes between stable, release candidate, beta, and alpha releases, distinguishing stable from these development states. The JED’s own guidance on vetting extensions matches this, spelling out the rule that users should “try to use the latest stable versions as much as possible” and restating unequivocally that beta or alpha releases should not be installed on production sites. While the comparison points are clear – a stable release is safer than a beta, a beta safer than an alpha – the documentation does not provide any specific criteria for evaluating beta or alpha quality, or any signals that could be read from GitHub or other issue trackers.
Update History and Changelogs: Reading Maintenance From the Timeline
If an extension with no updates in a year is abandoned, what does this tell you about one with a sparse update history in the JED or never an update through the Joomla updater? Prioritise extensions that are actively supported, and have relevant updates published in the JED or pushed through the Joomla updater in the last 12 months. This is Peter Martin’s specific advice in his Joomla security hardening guide, which notes that an extension that has never been updated through Joomla is “not stable, it is unmonitored.”
It’s not just presence that matters. Check whether the extension has regular, meaningful updates. One update years ago, or offering just Beta and Alpha, is not enough. A developer that publishes a changelog, responds to security reports, and updates frequently is one that intends to maintain the extension.
Joomla documentation does not take a formal position on using unanswered support forum threads or unpatched security reports as a maintenance signal. It does, however, recommend checking installed extensions “against the official Vulnerable Extensions List” and warns against out of date or abandoned extensions as a bad practice. That same guidance asks users to consider whether there is a support community for the extension.
To get under the release dates, Sucuri advises vetting an extension for a lot of user reviews with a high average rating. The tutorial is one of the few sources to name useful external signals: Sucuri also recommends finding clear terms of service and privacy policy, and verifying a physical contact address as concrete signs that the developer is accountable.
In practice, this means acquiring extensions from the official Joomla Extensions Directory, from well-established commercial developers, or from recommended developers in tutorials, rather than from unknown sites. A high average rating from a large number of individual reviews is a signal that the extension is trusted and popular, and that users have invested time in reporting bugs and requesting features.
Security Signals: Vulnerable Extensions List, Patches, and Policies
If looking for trusted third parties, referencing the list of reputable, commercial vendors of Joomla extensions is a good start. – using these vendor labels as an outside reference point is more transparent than depending on mostly unknown commercial ecosystem names.
Written terms of service, privacy policy, and policies for submitting vulnerabilities offer another signal of security seriousness. At a minimum, the site should have a policy in place to block unauthenticated users from installing or running extensions.A published vulnerability reporting and handling process is a minimum, but at least something visible and not just a security@email. The vendor's stated process is often the most meaningful: whether and how a vendor accepts vulnerability reports, makes patches, and notifies past users - instances where past vulnerability handling is documented are the most valuable sources.
Ultimately, the Vulnerable Extensions List (VEL) is the clearest answer to Joomla’s question of when to uninstall. If no patch is available, the official advice is to uninstall immediately. But even if a patch is available, that should be nearly automatic: downloading and installing it, immediately, at a minimum.
No specific studies were identified that point in general to the proportion of Joomla security incidents caused by abandoned extensions, or the proportion of extensions that reach each significant milestone (e.g. one year in maintenance, two, five). This is significant given that Joomla’s own guidance lists out of date or abandoned extensions as a bad practice, but without quantifying how much risk this represents compared to other potential issues like overly permissive directory settings or lack of a dedicated administrator.
Reputation and Support: Developer, Directory Listing, and Community
There is limited immediate, context-free visual access to most of these security signals. You’ll find some of the history, patches, and policies in the JED directory listing, under the “Support” and “About” tabs. The listing may link in to the vendor’s own site, changelogs, and issue tracker. Links to the developer’s public changelog, GitHub, or equivalent issue tracker, or at least to their policy pages for responding to issues and vulnerabilities, are important signals to verify.
The JED guidelines don’t explicitly rate the best sources of extensions as trusted, but the contained list of recommended vendors can offer meaningful signals. The directory listing may also show you who the vendor is, how long they’ve been active, and whether they’ve signed up for any of Joomla’s own programs for commercial vendors. Joomla’s strategy seems to be to signal seriousness via these familiar markers: an established JED badge, or membership of one of Joomla's programs, carries more weight than can be verified in a small listing.
You may need to look beyond the JED to verify these external signals, but the exercise is quick. Sucuri defines what matters: checking the changelog to see if the developer is "actively supporting" the extension, and whether the listing displays service terms, privacy policy, and contact information. This isn’t just a test of how the extension is maintained, but a broader test of the developer’s integrity and accountability. Suppose an extension publisher will not be transparent about incident response, or will not respond to vulnerability reports at all. In that case, it’s an easy decision not to trust the extension itself, whether or not the changelog is updated.
Cleaning House: Unused, Inactive, and Truly Abandoned Extensions
The logic of keeping your extension set updated applies just as strongly to uninstalling extensions that are no longer needed. Multiple Joomla security guides make the case that unused plugins and templates are still potential vulnerabilities and should be either disabled or removed. Joomlashack’s security checklist explicitly recommends deinstalling “anything you are not actively using,” while the 2026 practical guide brings it down to one clear word: uninstall. Having even disabled, inactive extensions is a security weakness to be avoided.
The JED’s Choosing Secure Extensions guide says briefly that you should "remove or disable" extensions that are "no longer required", but doesn't define "disabled" or suggest a regular routine for reviewing and removing inactive extensions. Sucuri's guide provides direction on assessing whether developers are actively supporting and patching an extension.
This is more than just a policy recommendation. This is the clearest indicator that Joomla and the community view the presence of inactive extensions as an ongoing, actionable weakness.
With above guidance in mind you can quickly vet your current installed extensions, removing anything unused, and compare with the VEL to see if you need to patch or uninstall. Extensions too old or too new, extensions updated or unpatched. But the process starts, not with the list, but with what you’re already using – removing any inactive extension is the first and most reliable security move of all.