As you know, the Joomla! Update component handles updating the Joomla core CMS files. But did you know that your extensions can have an impact on how you experience it, and whether the information it provides is correct?
Every time you update Joomla between two major versions (e.g. 4.x to 5.x), or two minor versions (e.g. 5.0 to 5.1) it attempts to perform an extensions compatibility check. You may be surprised to see a lot of extensions seemingly fail that check and wonder what's going on.
The short story is, Joomla! is lying to you.
A full extension compatibility check would require installing the extension on the new Joomla version and doing a complete evaluation of its features with and without the “Behaviour - Backward Compatibility” plugin enabled. It also needs to be done across different PHP versions, on both clean and updated installations of Joomla, across different web servers and database servers and so on and so forth. This is between impractical and impossible to automate, let alone do it for all of your extensions before you update Joomla.
As a result, Joomla Update relies on a different set of assumptions to perform a kinda-sorta-but-not-really compatibility check:
Every extension must have an update site, or belong to a package which has an update site.
Every update site must have entries for the currently installed version of the extension, and any available future versions.
Every extension version in the update site must state its supported Joomla versions.
Certain plugin types such as system and actionlog will always be reported as potentially problematic even if their developers have tested them against the new Joomla version and marked them as compatible. Simply unconscionable.
As you understand from this set of assumptions, this Pre-update Check has a lot of limitations.
You must update extensions before trying to update Joomla. Otherwise, it's not guaranteed that your currently installed version will be listed in the update site.
The check only works if the extension uses the same update site for your current, and your intended updated version of Joomla. For example, if upgrading from Joomla! 3 to 4 the extension MUST use the same update site for both of its Joomla! 3 and Joomla! 4 versions (which might be completely different and incompatible piece of code!), and list both versions of the software in it. This is not always practical, leading to a false incompatibility notice.
A new version of your extension might work with the new version of Joomla!, but is not installable on your current version of Joomla!. This chicken-and-egg issue is especially prevalent when updating across major versions long past the new x.0 release, e.g. from 3.10 to 4.4 (instead of 3.10 to 4.0). The correct approach is to disable the extension, update Joomla!, install the new Joomla! version, and re-enable the extension.
Extension groups MUST be distributed in packages. If the extension is actually a number of interlinked extensions such as a component and some plugins (e.g. JCE), or a number of interlinked plugins (e.g. Akeeba SocialLogin), etc they MUST be delivered as a Joomla! extension package. Otherwise, they various interlinked extensions would appear as standalone extensions without any update information, and Joomla would consider them incompatible. This is a major problem since the majority of most popular Joomla extensions is still not distributed in packages. As a result, the information you get from Joomla Update's Pre-update Check are useless at best.
You MUST install the package ZIP file, NOT its contents. If you unzip a package file and install the various extensions it contains (component, plugins, modules, …) they will no longer be linked with a package. As a result, they will appear as standalone extensions without any update information, and Joomla would consider them incompatible. If you have done that, install the package without uninstalling the extensions you already installed. Joomla wil fix most of these orphaned extensions, the rest can be fixed with Onthos.
The information presented cannot be verified. Joomla cannot possibly verify that an extension claiming to be compatible with a certain Joomla version actually is. Moreover, the way the Pre-update Check works leads us developers to over-promise on the compatibility front to prevent Joomla from misleading you into believing our extensions are not compatible with newer Joomla versions when what it is actually meant to report is if the specific version you have is compatible without giving us developers the chance to tell you what is your update path.
Many plugins are reported as potentially incompatible which means nothing at all. All system plugins will appear as potentially incompatible. Why? Because an idiot core Joomla maintainer decided that instead of having a simple two-line notice at the top of the page that third party plugins may interfere in the update process (which is technically true) he would rather put a scary, badly worded message telling you that every single third party plugin may break your site.
Never try to satisfy the Pre-Update Check list to upgrade Joomla. It's pointless. It is designed to give both false positives (which scare you away from using third party extensions) and false negatives (which results in broken sites). You should ignore it completely.
Always check with the extension developers' sites to find out if they support the Joomla version you are upgrading to, and what is the recommended upgrade path.
If you really want to, you can use Onthos to find extensions without an update site, extensions assigned to no or the wrong package, packages missing their child extensions, and problems with update sites. Fixing those problems will help the Pre-Update Check show slightly better results – but still not to the point where it actually makes practical sense to use for anything other than wry amusement.
Some people will use what we just explained about how unreliable the compatibility check in Joomla! Update is to make the argument that WordPress does it better.
This, of course, is nothing but a steaming pile of bovine manure.
WordPress suffers from exactly the same problem. It has no way whatsoever to test the compatibility of any third party plugin with a newer version of WordPress. You know how it solves this problem? It lets the developers declare which are the supported WordPress versions, and up to which version of WordPress they've tested with. Just like Joomla.
As for the fabled "forever" WordPress backwards compatibility? It's a fable, alright. It does not exist. It has never existed – at least not to the extent it's relentlessly marketed and mindlessly regurgitated. It's more like how Joomla was throughout the 3.x series. WordPress does make massive changes which break plugins every couple of years, with zero warning (gee, that sounds familiar, doesn't it?). The difference is that the community won't complain that WordPress broke something, but instead crucifies developers for not magically knowing that a last minute change in WordPress would break their plugin in ways they could not predict or have time to react to.
Not every problem has a technical solution.
The correct way to approach core updates is for you, the site owner, to a. take backups before an update; b. check the developer's site of each extension to see if there are known issues with the new core version; and c. ideally use a staging-live workflow for updates.
Still, sites will break. No software update ever can be 100% safe. As I'm typing this in October 2025 the tech world is abuzz with yet another Microsoft Windows update which causes problems to its users. This time, SSDs with a certain controller chip get irreparably wiped out under fairly normal conditions (large volume data writes, like what happens when updating Windows). That's a multi-trillion dollar company with thousands upon thousands of engineers.
Likewise, Apple –another multi-trillion dollar company– has just released a major update to macOS, iPadOS, and iOS. Guess what? Its users are met with an incredible amount of bugs which would make even an alpha version of a new major Joomla version look terrifyingly stable in comparison. My favourite bug this first week of October 2025 is that a battery optimisation feature in macOS 26 is causing Electron-based apps –therefore, the majority of apps real users use in the real world– chew through battery like crazy because it causes macOS' compositor to redraw the entire application window dozens of times per second.
Again, these are multi-trillion dollar companies with thousands of engineers. Somehow, us tiny third party extension developer companies with headcounts in the single digits (and rarely anything above 1) do manage to actually do BETTER than these multi-trillion dollar companies when it comes to update quality.
So, I am asking: do we really need some convoluted compatibility check which overcomplicates things, confuses users, frustrates developers, and doesn't offer any value for issues which are far less serious and far less common than what the average user begrudgingly but otherwise meekly accepts from Big Tech? What is the added value? What is the problem being solved? Just because we can, doesn't mean we should.