[RFC] Pre Upgrade checker not compatible extensions that could break the upgrade

[zero-24]

Problem identified

As mention here and here an not compatible extension enabled at the upgrade process could lead to an bricked site.

That list includes

• system plugins (e.g. onAfterRoute)
• authentication plugins (possibly used to authenticate a Super User in the upgrade process)
• twofactorauth plugins (possibly used to authenticate a Super User in the upgrade process)
• user plugins (e.g. onUserLogin)
• actionlog (e.g. onUserAfterLogin)

Proposed solution

Right now we have the pre upgrade checker already that lists all extensions that are compatible and that are not compatible and where we don't know whether they are compatible.

The proposed solution is to do two things:

• Improve the texts for the pre upgrade checker (based on RFC hardened update report #30930)
• Implement a dedicated error message with SU confirmation that there might be extensions that brick the sites.

Improve the texts for the pre upgrade checker

Change Update Information Unaviable to Compatibility Unknown
Change Extension does not use the Joomla update system or the developer has not provided no compatibility information to These extensions does not use the Joomla update system or the developer has not provided no compatibility information. Proceed with caution. We recommend to disable the extensions before continiue the upgrade.

Change Please update these extensions before updating Joomla to These extensions have aviable updates usually they must be updated before you continue upgrading Joomla.

Implement a dedicated error message with SU confirmation that there might be extensions that brick the sites.

Process proposal

• Once an user hits the Install update button in com_joomlaupdate
• Log that we are now checking the compatibility informations
• Joomla checks the compatibility informations for all non-core: system, authentication, twofactorauth, user and actionlog plugins
• Log the extensions checked
• Joomla collects all extensions that require an update or does not provide any compatibility informations
• Log the result of that check with th list of possible incompatible extensions
• -> When there are no possible incompatible extensions found
• -> Log that there has not been any incompatible extensions found and that we now proceed with the upgrade
• -> proceed with the upgrade
• Where there are incompatible extensions found issue an error
• Log the mention extensions
• Redirect to an dedicated page that list that extensions and request that extensions to be disabled for the time of the upgrade
• -> Allow that page (and so the upgrade process) to be aborted at that point.
• -> Log that the upgrade process has been aborted
• Require an SU to confirm that he still wants to proceed with the upgrade
• Log that this list of extensions have been confirmed by a Super User and that we now proceed with the upgrade
• -> Proceed with the upgrade

Implemention proposal

Add the code to check for the compatibility information in the install task of the controller: https://github.com/joomla/joomla-cms/blob/3.10-dev/administrator/components/com_joomlaupdate/controllers/update.php#L119 or create an dedicated precheck task and make sure that is executed as first step.

In order to get the compatibility information split the method fetchExtensionCompatibility into two where one does only generate the JSON for a given set of extension IDs and the original one still returns the JSON for the pre upgrade checker.

Clarifications

When an possible affected plugin is part of an package we should check whether that package is compatible with 4.x or not and not the plugin directly as that plugin does not have a dedicated update server.

Next steps

• Mark this issue as release blocker for 3.10-dev
• Collect feedback from the other involved people
• Agree on an implementation / process
• Prepare and send a PR against 3.10-dev
• Write a document page with the details of what this message is about and make sure that page is also linked from the new page in the backend
• Test & provide feedback on that given PR
• Merge the PR into 3.10-dev

Mentions

@alikon
@nikosdion
@GeraintEdwards
@infograf768
@brianteeman
@HLeithner
@Fedik
@wilsonge
@richard67
@ceciogit
@softforge

Questions

• Is the list of extension types complete or do this list miss an possibly affected extension type?
• Is there anything we have to take care of or can do for 3rd Party tools that trigger the upgrades, so they can warn the people too? (@GeraintEdwards @SniperSister @rdeutz @PhilETaylor) -> Idea: We could implement an public method that returns the possible affected extensions so you can document and show them in your tools? Do you have other ideas and/or can share some insights here? Or do you already have that kind of informations and do not require additional information from com_joomlaupdate to implement an similiar message into your tools?

Thanks :)

[nikosdion]

I have so many misgivings, starting with reporting extensions without update streams and all the way to how simplistically you are approaching compatibility. You sound like you have no idea how complicated Joomla extension updates are or what are the challenges of updates out there in the real world. Have you ever done support for mass distributed extensions used by hundreds of thousands of sites? I have and I am SHOCKED at your proposal. It is shooting your own feet!

Let's take Akeeba Backup for example.

It's delivered as pkg_akeeba (Akeeba Backup package) which has an update site (https://cdn.akeeba.com/updates/pkgakeebapro.xml). The update site is marked as Joomla 4 compatible.

However, the package is NOT executable code. It installs the following individual extensions:

• com_akeeba (Akeeba Backup). The main component.
• file_akeeba (CLI scripts, pro version).
• plg_quickicon_akeebabackup (Quick Icon plugin).
• pig_system_backuponupdate (Backup on Update plugin).
• plg_actionlog_akeebabackup (Action Log plugin).
• plg_installed_akeebabackup (Installer plugin).

These individual extensions DO NOT have their own update sites and they should never do. They MUST be all be upgraded at the same time. That's why we have the package extension type to begin with. With your suggestion these individual extensions would appear as incompatible with Joomla 4 whereas the Akeeba Backup package would appear compatible.

At the very least you would have to check which extensions belong to which package and remove them from the report. Otherwise you are doing a disservice to Joomla users and 3PD developers and you'll end up with everyone ignoring Joomla's compatibility report.

Things get more complicated when extensions are removed from package type extensions. Joomla currently has no way to let developers uninstall obsolete extensions when upgrading the package. My solution is to call the uninstallation code manually from my package's post-installation script. This works, except when Joomla fails to uninstall the extension for any reason. To work around that I disable the obsolete extension before trying to uninstall it. What happens if a disabled but not uninstalled extension is left behind? Do I get users asking me about a plugin I discontinued 7 years ago but is still lurking on their site because Joomla failed to uninstall it? This is very important for me because the time I spend on stupid support like that cannot be automated.

Moreover, what happens on sites which cannot access the update stream for any reason (typically a firewall)? Does Joomla now report my PERFECTLY Joomla 4 COMPATIBLE EXTENSIONS as "incompatible" because Joomla failed to retrieve the update information?! This is idiotic. Why blame me for something I haven't done just because your network code failed.

This is a mess. Joomla needs to be perfectly clear about which extensions:

• have update streams, the update streams can be read, the stream is J4 compatible
• have update streams, the update streams can be read, the stream is NOT J4 compatible
• have update streams, the update streams can be read, the stream does not declare J4 compatibility
• have update streams, the update streams cannot be read
• do not have update streams and do not belong to a package
• do not have update streams, but belong to a package with an update stream which can be read, the stream is J4 compatible
• do not have update streams, but belong to a package with an update stream which can be read, the stream is NOT J4 compatible
• do not have update streams, but belong to a package with an update stream which can be read, the stream does not declare J4 compatibility
• do not have update streams, but belong to a package with an update stream which cannot be read
• do not have update streams and do not belong to a package

This is impossible to convey in a meaningful manner. Instead, you can not report extensions belonging to a package which leaves us with reporting extensions which are either a package OR do not belong to a package and:

• have update streams, the update streams can be read, the stream is J4 compatible (J4 Compatible)
• have update streams, the update streams can be read, the stream is NOT J4 compatible (J4 Incompatible – must disable)
• have update streams, the update streams can be read, the stream does not declare J4 compatibility (Unknown compatibility – proceed with caution)
• have update streams, the update streams cannot be read (Cannot retrieve compatibility information: network error)
• do not have update streams and do not belong to a package (Unknown compatibility – proceed with caution)

You also need to consider that extensions may have more than one update sites and each update stream may provide conflicting information. In this case you need to define an override order:

J4 compatible OVERRIDES J4 incompatible OVERRIDES no compatibility information.

Further to that, we may have extensions which are out of date. The out of date version may be J4 incompatible (or have no information) but the new version is J4 compatible. These extensions should be added under a different header (Must update for J4 compatibility).

The problem with the last category is that you may have paid extensions the user cannot update. This is something you cannot convey to the user so hopefully the user will figure it out.

Furthermore, what is Joomla 4 compatibility at this point in time? I have been working on J4 compatibility since alpha 2. OK, the alphas changed all the time and I couldn't guarantee compatibility beyond the actual alpha I worked on. Then betas were out. The extensions I had Joomla 4 Beta 1 compatible would not work on beta 2. I had to make a different release. Up to and including Joomla 4 beta 4 (latest at the time of this writing) they work. What if compatibility breaks in say beta 5 and I don't have time to fix it before the stable? Is my extension reporting itself Joomla 4 compatible really J4 compatible or is it not? I won't really be able to tell you until the stable is out. This beats the point of the compatibility report since even my OLD version that was only beta 1 compatible would show a passing mark in the report.

And that's just Joomla compatibility. What about PHP versions? If someone has PHP 7.2 they could run Joomla 4 but not necessarily the updated versions of different extensions. For example, there might be an extension that is compatible with Joomla 3 on PHP 5.6 to 7.2 but only compatible with J3 and J4 on PHP 7.3 and later.

You are all treating the compatibility report as something simple and straightforward when it's anything but. You have failed to consider even those fairly obvious things I described above.

So this RFC gets a big fat -1 from me. I would much rather see it removed altogether. The only realistic option for users is to make an inventory of their installed extensions and their versions, then check the developers' sites about the J4 compatibility status. What would make most sense is:

• A field in the manifests pointing to the extension's PHP and Joomla version compatibility information.
• An extension inventory page which excludes core extensions and extensions belonging to a package, as well as the PHP version the server is running under. The compatibility info link should be visible next to each extension. Also show if there's an update available and what is the latest J4 compatible version regardless of PHP version compatibility.

The human user could then decide how to proceed. Anything else WILL be misleading for a lot of users.

[zero-24]

Hi,

thank you for your promt feedback.

At the very least you would have to check which extensions belong to which package and remove them from the report. Otherwise you are doing a disservice to Joomla users and 3PD developers and you'll end up with everyone ignoring Joomla's compatibility report.

I have not checked with akeeba products but I would expect the pre upgrade checker to take care of that if not this is a bug that should be fixed.

Moreover, what happens on sites which cannot access the update stream for any reason (typically a firewall)?

I would say we can't do many about that right? Other than tell the user to check everything manually. When this is not implemented yet thats another issue to be solved.

This is impossible to convey in a meaningful manner. Instead, you can not report extensions belonging to a package which leaves us with reporting extensions which are either a package OR do not belong to a package and:

We have a field for that right? So every extension developer can mark extensions beeing part of a package. (since 3.7.0: #12977)

You also need to consider that extensions may have more than one update sites and each update stream may provide conflicting information. In this case you need to define an override order:

What would be a good override order in your opinion? When there are two update server with different informations? The best bet would bet to take what JUpdate would return as this is used within the extension updater too and take that or add such extension to the unknown list. As it seems even the extension dev does not know whether that extension is compatible or not.

Furthermore, what is Joomla 4 compatibility at this point in time? I have been working on J4 compatibility since alpha 2. OK, the alphas changed all the time and I couldn't guarantee compatibility beyond the actual alpha I worked on. Then betas were out. The extensions I had Joomla 4 Beta 1 compatible would not work on beta 2. I had to make a different release. Up to and including Joomla 4 beta 4 (latest at the time of this writing) they work. What if compatibility breaks in say beta 5 and I don't have time to fix it before the stable? Is my extension reporting itself Joomla 4 compatible really J4 compatible or is it not? I won't really be able to tell you until the stable is out. This beats the point of the compatibility report since even my OLD version that was only beta 1 compatible would show a passing mark in the report.

The point at this point here (this specific RFC) is does your extension break the upgrade process and brick the site? No than the proposed check here can pass for that extension.
At this point it seems to be mostly using removed code in critical plugins once that is not happening the upgrade path is safe and that is the point for this additional check. In generall you should only mark your extensions 4.x compatible when they are but please can you tell me what changed between the betas that resulted into akeeba not beening compatible anymore?

And that's just Joomla compatibility. What about PHP versions? If someone has PHP 7.2 they could run Joomla 4 but not necessarily the updated versions of different extensions. For example, there might be an extension that is compatible with Joomla 3 on PHP 5.6 to 7.2 but only compatible with J3 and J4 on PHP 7.3 and later.

Yes and for that we also have a field in the update.xml file same applies for database types and versions supported by that extension.

So this RFC gets a big fat -1 from me. I would much rather see it removed altogether.

I disagree, this is not intended to solve all possible upgrade issues but to help with the information shared by the developers. This is intended as starting point for the manuall process as mention by you.

The only realistic option for users is to make an inventory of their installed extensions and their versions, then check the developers' sites about the J4 compatibility status. What would make most sense is:

Yes and the pre upgrade checker in my opinion is a starting point here where you can get that lists you should check first, this is also documented in the pages that explain the pre upgrade checker.

From a migration perspective, it is my belief that the Pre-Update Check should be used a guide. You'll want to have a second tab open with Extensions→Manage→Manage open in order to uninstall any extensions or check who they're authored by so you can contact third-party extension developers on the migration path they've established to migrate their extensions.

https://docs.joomla.org/Pre-Update_Check#Summary

A field in the manifests pointing to the extension's PHP and Joomla version compatibility information.

You mean another remote XML file or hardcoded in the extensions.xml or something different?

An extension inventory page which excludes core extensions and extensions belonging to a package, as well as the PHP version the server is running under. The compatibility info link should be visible next to each extension. Also show if there's an update available and what is the latest J4 compatible version regardless of PHP version compatibility.

Thats in a large part what the pre upgrade checker does already, right?
I'm not sure what compatibility info link you mean? I'm not sure whether an link to the update.xml would help the users?

The human user could then decide how to proceed. Anything else WILL be misleading for a lot of users.

Yes agree and that is what i tried to make happen here. Add possible incompatible extensions that could brick the site before the upgrade to the super users attention. And let him take the decision.

[Fedik]

I think the idea is good in general.

Regarding PHP, (DB etc), it not a new issue, In my opinion the extension should follow minimum Joomla requirement. If it cannot follow then it cannot be marked as compatible.
I agree that it could be a good improvement here, but not critical. Most easy solution here just to raise php minimum to 7.4 at least.

[nikosdion]

I have not checked with akeeba products but I would expect the pre upgrade checker to take care of that if not this is a bug that should be fixed.

AFAIK it's not broken now but with your proposal it would break for the reasons I explained.

I would say we can't do many about that right? Other than tell the user to check everything manually. When this is not implemented yet thats another issue to be solved.

I disagree. Joomla can report which extensions' updates it couldn't retrieve INSTEAD OF listing them as incompatible (which is what would happen with your proposal).

We have a field for that right? So every extension developer can mark extensions beeing part of a package. (since 3.7.0: #12977)

We do, but your proposal seems to not be taking it in into account. You need to take it into account is what I am saying.

What would be a good override order in your opinion?

I already answered that in my previous comment: J4 compatible OVERRIDES J4 incompatible OVERRIDES no compatibility information.

The best bet would bet to take what JUpdate would return as this is used within the extension updater too and take that or add such extension to the unknown list.

Absolutely not! You CAN NOT trust JUpdate. It will always report the first update stream it can read. Look, I consider the fact that Joomla allows multiple update streams to be completely asinine. This was implemented in 1.6 as a means for Joomla to be able to provide two update streams, current version and next version, which would be read in tandem. Stupid idea leading to a stupid feature with a stupid implementation but it is what it is.

As it seems even the extension dev does not know whether that extension is compatible or not.

And who's to blame for that? That's right, the Joomla project! We entered a "beta" where features are added and changed left and right. That's not a beta. That's an alpha. We are trying to work around the Joomla project's idiocy. Berating us from trying to do that is kinda shitty.

The point at this point here (this specific RFC) is does your extension break the upgrade process and brick the site?

Frankly, I cannot know that because Joomla keeps making API changes throughout the beta and RC periods. It also doesn't follow PHP's version_compare semantics for alpha and beta versions which means I cannot target specific Alpha/Beta versions. So someone could have a Joomla 3 site with an extension of mine that's compatible with J4 Beta 1 (which SHOULD have been written as 4.0.0.b1) but not J4 stable (which should be written as 4.0.0). So, no idea, mate.

At this point it seems to be mostly using removed code in critical plugins once that is not happening the upgrade path is safe and that is the point for this additional check. In generall you should only mark your extensions 4.x compatible when they are but please can you tell me what changed between the betas that resulted into akeeba not beening compatible anymore?

Why don't you read my release notes? Biggest problem was that somewhere between beta 1 and beta 2 the InputFilter constants' names changed, making it a breaking change. This necessitated an emergency fix in FOF where I am not using hardcoded numbers devoid of context instead of InputFilter::TAGS_BLACKLIST and InputFilter::ATTR_BLACKLIST.

There are other smaller issues like the way setRedirect changed but this may have been the case in beta 1 too.

Of course the template changing every few months didn't help either. But that's a visual issue, not a biggie. The InputFilter was the major problem, breaking all of my extensions.

Yes and for that we also have a field in the update.xml file same applies for database types and versions supported by that extension.

An ill-documented field I found by accident that almost nobody uses? Yes.

But you COMPLETELY missed the point. If the currently installed version is J4 incompatible and the next version of my software IS compatible with J4 but requires a newer PHP or DB version the user is told that my extension is not J4 compatible WHICH IS A LIE!

You make ME look bad, after I've put 100s of hours trying to work around your arbitrary, never-ending changes, just because you can't figure out a way to tell the user "hey, this extension CAN be Joomla 4 compatible but you need to update your server shit as well". THIS is what makes us 3PDs tell our clients that Joomla is broken and the information presented to it is not to be trusted.

I disagree, this is not intended to solve all possible upgrade issues but to help with the information shared by the developers. This is intended as starting point for the manuall process as mention by you.

It fails at this objective! If you cannot handle all of the ways that real world sites install and update real world extensions – including common failure modes about updates – the information you are presenting is misleading and confusing the user.

I'll say this again until it registers with you. For example, if my update XML says that Example Extension v.8.0.0 is J4 compatible but requires PHP 7.3 and your interface says in a categorical manner that Example Extension is incompatible with J4 because JUpdate considers the update inapplicable (because the server currently runs PHP 7.2) you are spreading false information about my software.

The problem is not the information I provide. It's the way it's used by Joomla. The way it's phrased can even be used as the basis for a libel suite.

You mean another remote XML file or hardcoded in the extensions.xml or something different?

Hardcoded in the extension's manifest, not the update server.

Thats in a large part what the pre upgrade checker does already, right?

ABSOLUTELY NOT. Right now it tells you which update servers could be reached and reported that an extension is J4 compatible. The wording is misleading, not all extensions are listed and there is no indication as to who is the developer and where to find the latest compatibility information. It's useless. I've done a migration. The one extension that was incompatible was lost in a sea of useless and misleading information. Note that I am someone who knows what he's doing and I still missed the infinitesimal signal through the abundant noise.

I'm not sure what compatibility info link you mean? I'm not sure whether an link to the update.xml would help the users?

Oh, really? Have you ever talked to real world users? You and me are NOT a representative sample. We are the aberrations, the anomalies, the people who know WTF they are doing. The average user can't be bothered playing detective.

A user sees that an extension might not be J4 compatible. What do they do? Right now, they don't know. Maybe they'll look up the developer's or extension's name on Google. Hopefully they will come to the developer's site. They will use the Contact page. 3PDs have to waste time to point them to their published Joomla, PHP etc compatibility information (all of us have that information for our extensions).

What I propose is that the extension's XML has a link to that page on our site which says what is the compatibility status of our extension. The user sees that an extension might not be compatible with Joomla 4 along with a "further information" link. No more wondering what to do. Click the link, find out what gives. Maybe the dev uses it to link to a page explaining that J4 compatibility is underway. Maybe they want to convey that they won't be maintaining their extension anymore. Maybe they want to say that their extension is J4 compatible BUT requires a newer PHP/DB version. Not all of that can be conveyed programmatically and there's no point tasking the poor user with trying to divine that information. WHY PLAY DETECTIVE WHEN WE CAN PROVIDE A LINK?

Yes agree and that is what i tried to make happen here. Add possible incompatible extensions that could brick the site before the upgrade to the super users attention. And let him take the decision.

Then change the language on that page to reflect the intention. Your proposal takes vague language and makes it sound like "This is the One Absolute Truth" when it's most definitely not the case.

[zero-24]

I think the idea is good in general.

Thanks :)

Regarding PHP, (DB etc), it not a new issue, In my opinion the extension should follow minimum Joomla requirement. If it cannot follow then it cannot be marked as compatible.

Minimum PHP version of Joomla is always the base to be installed or used as Joomla 4.x wont run on anything lower than 7.2.5. That minimum field should be used when the PHP minimum is higher than 7.2.5

I agree that it could be a good improvement here, but not critical. Most easy solution here just to raise php minimum to 7.4 at least.

I'm not sure what you mean here? Raising the PHP minimum for 4.x has been suggested (inclding by me) but has not been accepted and is now fixed to 7.2.5. Extensions are free to choose anything above 7.2.5 for sure :)

[Fedik]

I'm not sure what you mean here? Raising the PHP minimum for 4.x has been suggested (inclding by me) but has not been accepted and is now fixed to 7.2.5

There a changes and new features between 7.2 > 7.3 > 7.4 that may produce issues. Extension that working fine on 7.2 may have an issue on 7.4, and vice versa, when extension use new features of 7.4 it will fail on 7.2.

Raising the PHP minimum may reduce possibility of such incompatibility.
I meant that it is more easy to implement than to code a version check :)

[richard67]

You mean another remote XML file or hardcoded in the extensions.xml or something different?

Hardcoded in the extension's manifest, not the update server.

We need this indeed for packages not coming with an update server but being updated with the "Upload & Install" or the "Install from Folder" method of the extensions manager.

But for packages with an update server we might not want to download the package and extract the manifest for each check.

So I think we need compatibility information about CMS, PHP and database versions at both places, in the extension's manifest and in the XML on the update server.

[zero-24]

I have not checked with akeeba products but I would expect the pre upgrade checker to take care of that if not this is a bug that should be fixed.

AFAIK it's not broken now but with your proposal it would break for the reasons I explained.

Ok good to know. Will update the bits about extension packages in the inital proposal.

I would say we can't do many about that right? Other than tell the user to check everything manually. When this is not implemented yet thats another issue to be solved.

I disagree. Joomla can report which extensions' updates it couldn't retrieve INSTEAD OF listing them as incompatible (which is what would happen with your proposal).

hmm with the proposed texts here it would be found under Compatibility Unknown. But fine for me to have another list too. But I would like to branch that out to a dedicated Issue / PR as this has nothing to do with the proposal here other than such extensions would popup in the please check them before updating list too.

We have a field for that right? So every extension developer can mark extensions beeing part of a package. (since 3.7.0: #12977)

We do, but your proposal seems to not be taking it in into account. You need to take it into account is what I am saying.

I'm sorry will make that clear in the above proposal.

What would be a good override order in your opinion?

I already answered that in my previous comment: J4 compatible OVERRIDES J4 incompatible OVERRIDES no compatibility information.

I disagree. When there are that multible update servers why should we try to find the right versions when even the developer does not seem to have clear information via the update.xml?

The best bet would bet to take what JUpdate would return as this is used within the extension updater too and take that or add such extension to the unknown list.

Absolutely not! You CAN NOT trust JUpdate. It will always report the first update stream it can read. Look, I consider the fact that Joomla allows multiple update streams to be completely asinine. This was implemented in 1.6 as a means for Joomla to be able to provide two update streams, current version and next version, which would be read in tandem. Stupid idea leading to a stupid feature with a stupid implementation but it is what it is.

Well the problem I see here is that JUpdate (without extra logic) is used in the extension updater. So when we would go that path we would have to also use the same logic in com_installer.

As it seems even the extension dev does not know whether that extension is compatible or not.

And who's to blame for that? That's right, the Joomla project! We entered a "beta" where features are added and changed left and right. That's not a beta. That's an alpha. We are trying to work around the Joomla project's idiocy. Berating us from trying to do that is kinda shitty.

It was about inconsistend information in the update.xml, meaning that xml file should include whether they are compatible or not and it should not on us to define an override path and decide whether that information we choose?
I'm not blaming the extension devs for having to patch between beta releases.

The point at this point here (this specific RFC) is does your extension break the upgrade process and brick the site?

Frankly, I cannot know that because Joomla keeps making API changes throughout the beta and RC periods. It also doesn't follow PHP's version_compare semantics for alpha and beta versions which means I cannot target specific Alpha/Beta versions. So someone could have a Joomla 3 site with an extension of mine that's compatible with J4 Beta 1 (which SHOULD have been written as 4.0.0.b1) but not J4 stable (which should be written as 4.0.0). So, no idea, mate.

version_compare should work correctly with 4.0.0-beta1 vs '4.0.0' or I'm missing something? https://3v4l.org/gnuRN

At this point it seems to be mostly using removed code in critical plugins once that is not happening the upgrade path is safe and that is the point for this additional check. In generall you should only mark your extensions 4.x compatible when they are but please can you tell me what changed between the betas that resulted into akeeba not beening compatible anymore?

Why don't you read my release notes?

I'm not using your software ;)

Biggest problem was that somewhere between beta 1 and beta 2 the InputFilter constants' names changed, making it a breaking change. This necessitated an emergency fix in FOF where I am not using hardcoded numbers devoid of context instead of InputFilter::TAGS_BLACKLIST and InputFilter::ATTR_BLACKLIST.

There are other smaller issues like the way setRedirect changed but this may have been the case in beta 1 too.

Of course the template changing every few months didn't help either. But that's a visual issue, not a biggie. The InputFilter was the major problem, breaking all of my extensions.

Yes I agree this was a breaking change but we did our best to document and inform our developers about that change.

Yes and for that we also have a field in the update.xml file same applies for database types and versions supported by that extension.

An ill-documented field I found by accident that almost nobody uses? Yes.

Well it is documented what can be improved in the docs? I know a few extensions that use that field but you also only have to use it when you want to upgrade the PHP minimum from Joomla's right?

But you COMPLETELY missed the point. If the currently installed version is J4 incompatible and the next version of my software IS compatible with J4 but requires a newer PHP or DB version the user is told that my extension is not J4 compatible WHICH IS A LIE!

You make ME look bad, after I've put 100s of hours trying to work around your arbitrary, never-ending changes, just because you can't figure out a way to tell the user "hey, this extension CAN be Joomla 4 compatible but you need to update your server shit as well". THIS is what makes us 3PDs tell our clients that Joomla is broken and the information presented to it is not to be trusted.

I disagree, this is not intended to solve all possible upgrade issues but to help with the information shared by the developers. This is intended as starting point for the manuall process as mention by you.

It fails at this objective! If you cannot handle all of the ways that real world sites install and update real world extensions – including common failure modes about updates – the information you are presenting is misleading and confusing the user.

I'll say this again until it registers with you. For example, if my update XML says that Example Extension v.8.0.0 is J4 compatible but requires PHP 7.3 and your interface says in a categorical manner that Example Extension is incompatible with J4 because JUpdate considers the update inapplicable (because the server currently runs PHP 7.2) you are spreading false information about my software.
The problem is not the information I provide. It's the way it's used by Joomla. The way it's phrased can even be used as the basis for a libel suite.

Well partly the result is correct. As that extension is not compatible with the current hosting setup. Thats not an issue with the extension but with the hosting setup. When this is not clear (I have not tested such case yet) this sounds like an bug to me and should be fixed outside of this RFC.

You mean another remote XML file or hardcoded in the extensions.xml or something different?

Hardcoded in the extension's manifest, not the update server.

Thats in a large part what the pre upgrade checker does already, right?

ABSOLUTELY NOT. Right now it tells you which update servers could be reached and reported that an extension is J4 compatible. The wording is misleading, not all extensions are listed and there is no indication as to who is the developer and where to find the latest compatibility information. It's useless. I've done a migration. The one extension that was incompatible was lost in a sea of useless and misleading information. Note that I am someone who knows what he's doing and I still missed the infinitesimal signal through the abundant noise.

• Ok so the woding is misleading and can be improved, suggestions?
• What extensions are missing (only the core should not be listed)
• Adding the developer / author field to the additional information sounds good to me and link to the author site once aviable?
• I have no patent solution for the noise part but I'm happy for suggestions.

I'm not sure what compatibility info link you mean? I'm not sure whether an link to the update.xml would help the users?

Oh, really? Have you ever talked to real world users? You and me are NOT a representative sample. We are the aberrations, the anomalies, the people who know WTF they are doing. The average user can't be bothered playing detective.

Agree, that is still the idea of the pre upgrade checker while i acknowledge that it is not perfect.

A user sees that an extension might not be J4 compatible. What do they do? Right now, they don't know. Maybe they'll look up the developer's or extension's name on Google. Hopefully they will come to the developer's site. They will use the Contact page. 3PDs have to waste time to point them to their published Joomla, PHP etc compatibility information (all of us have that information for our extensions).

What I propose is that the extension's XML has a link to that page on our site which says what is the compatibility status of our extension. The user sees that an extension might not be compatible with Joomla 4 along with a "further information" link. No more wondering what to do. Click the link, find out what gives. Maybe the dev uses it to link to a page explaining that J4 compatibility is underway. Maybe they want to convey that they won't be maintaining their extension anymore. Maybe they want to say that their extension is J4 compatible BUT requires a newer PHP/DB version. Not all of that can be conveyed programmatically and there's no point tasking the poor user with trying to divine that information. WHY PLAY DETECTIVE WHEN WE CAN PROVIDE A LINK?

Makes sense and sounds like a good addition to me. But in my opinion should be branched out of this specific issue here.

Yes agree and that is what i tried to make happen here. Add possible incompatible extensions that could brick the site before the upgrade to the super users attention. And let him take the decision.

Then change the language on that page to reflect the intention. Your proposal takes vague language and makes it sound like "This is the One Absolute Truth" when it's most definitely not the case.

Well the updated strings are comming from Brian's RFC proposal and i have taken them as i think they better fit the information we have a that point. But this is the point here getting feedback like yours so we can improve the texts and make them more clear, I'm open to suggestions.

[zero-24]

I'm not sure what you mean here? Raising the PHP minimum for 4.x has been suggested (inclding by me) but has not been accepted and is now fixed to 7.2.5

There a changes and new features between 7.2 > 7.3 > 7.4 that may produce issues. Extension that working fine on 7.2 may have an issue on 7.4, and vice versa, when extension use new features of 7.4 it will fail on 7.2.

Agree when they use 7.4 features that extensions should raise the minimum php version. So that extension can not be installed in 7.2.

I'm not sure how we can aproach issues with future PHP versions. Maybe a last tested PHP Version and raise an message when you install this extension on a not tested PHP version?

Raising the PHP minimum may reduce possibility of such incompatibility.
I meant that it is more easy to implement than to code a version check :)

Rainsing Joomla's php minimum or do we talk about extensions here?

[Fedik]

Rainsing Joomla's php minimum or do we talk about extensions here?

Joomla ;)

[zero-24]

You mean another remote XML file or hardcoded in the extensions.xml or something different?

Hardcoded in the extension's manifest, not the update server.

We need this indeed for packages not coming with an update server but being updated with the "Upload & Install" or the "Install from Folder" method of the extensions manager.

But for packages with an update server we might not want to download the package and extract the manifest for each check.

So I think we need compatibility information about CMS, PHP and database versions at both places, in the extension's manifest and in the XML on the update server.

I'm not sure whether we should have two places with compatibility informations. Who would get priority in a conflict? And could't point an update server to a newer version with different compatibility informations?

That the current installed extension is compatible with the current setup should be prove by the fact that it could be installed and your extension is not broken right now. But I'm happy to be proven wrong.

[zero-24]

Rainsing Joomla's php minimum or do we talk about extensions here?

Joomla ;)

Well I persoanlly agree with you that we should raise the PHP minimum. I have even suggested that myself to production months ago. But the php and system minimum versions are fixed now to what we have and what production has decided on. (PROD2020/025)

Even with php 7.4 as minimum the same issue would come up with PHP 8.0. beeing around the corner right?

[Fedik]

Even with php 7.4 as minimum the same issue would come up with PHP 8.0. beeing around the corner right?

yeah, that true

[richard67]

I'm not sure whether we should have two places with compatibility informations.

I'm not sure either. But it might be the only way to fix it for extensions without an update server without having to extract the manifest each time for such which do have an update server.

Who would get priority in a conflict?

If there is an update server which provides compatibility information, this should be used and trusted, and if there is no update server, the manifest of the installed extension should be used and trusted, we have nothing else in that case.

As far as I remember, the pre-update check shows if an installed extension is not compatible with J4 but there is an update available which is compatible.

The part of this check for the installed extension should always use the manifest of the installed extension and not rely to the information on the update server.

The update server's information should only be used for the "there is a compatible update available" part of this check.

So far for the pre-update check.

The extensions installer then should always check the information in the manifest before applying the update with whichever method. But this is not related to the pre-update check.

[zero-24]

I'm not sure whether we should have two places with compatibility informations.

I'm not sure either. But it might be the only way to fix it for extensions without an update server without having to extract the manifest each time for such which do have an update server.

Well extensions without any update server just will be moved to compability unknow as that is the thing right?

Who would get priority in a conflict?

If there is an update server which provides compatibility information, this should be used and trusted, and if there is no update server, the manifest of the installed extension should be used and trusted, we have nothing else in that case.

As far as I remember, the pre-update check shows if an installed extension is not compatible with J4 but there is an update available which is compatible.

Yes

The part of this check for the installed extension should always use the manifest of the installed extension and not rely to the information on the update server.

The update server's information should only be used for the "there is a compatible update available" part of this check.

So far for the pre-update check.

Agree but I my opinion this makes the upgrade checks even more complex and I'm not sure whether this is worth the complexity. Given that extensions without any update server should be handled with care anyway.

The extensions installer then should always check the information in the manifest before applying the update with whichever method. But this is not related to the pre-update check.

I'm not sure where we would have to use that information in the extension installer?

[jiweigert]

Just to throw in something the pre-updatechecker maybe don't do:

Checking for removed core extensions / plugins, because the real world user of Joomla don't need the feature in his site and decided to install them.
Possible problem: Update scripts rely on informations in the DB (or filesystem), which are not existing anymore and therefor fail.

The reason is simply, that in 3.9, Joomla users CAN deinstall core-plugins and extensions, even it's not recommended or advised.

So assuming (by ignoring) that every system has all core plugins or extensions installed is a failing scenario which will happen.
And that lead to NOT hiding core extensions:

What extensions are missing (only the core should not be listed)

Better way is to check their existance in DB and filesystem and either re-install them gracefully or give the User an option to reinstall them.

I really hope, this will be included in the (Pre-)Updater, everything else is dancing on a rope without securitynet.

Just my 2c

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/31042.}

[zero-24]

Just to throw in something the pre-updatechecker maybe don't do:

Checking for removed core extensions / plugins, because the real world user of Joomla don't need the feature in his site and decided to install them.
Possible problem: Update scripts rely on informations in the DB (or filesystem), which are not existing anymore and therefor fail.

The reason is simply, that in 3.9, Joomla users CAN deinstall core-plugins and extensions, even it's not recommended or advised.

So assuming (by ignoring) that every system has all core plugins or extensions installed is a failing scenario which will happen.
And that lead to NOT hiding core extensions:

What extensions are missing (only the core should not be listed)

Better way is to check their existance in DB and filesystem and either re-install them gracefully or give the User an option to reinstall them.

I really hope, this will be included in the (Pre-)Updater, everything else is dancing on a rope without securitynet.

Just my 2c

Well when this would happen this is out of scope for this specific RFC so please open its own Issue. I'm also not sure how to easily reinstall removed core extensions. When you have such install it could be possible after reinstall the core (from com_joomlaupdate) that you can than discover install them via com_installer. Would be great when you can check that and open an issue so we can keep track of that request.

[brianteeman]

Then change the language on that page to reflect the intention. Your proposal takes vague language and makes it sound like "This is the One Absolute Truth" when it's most definitely not the case.

Well the updated strings are comming from Brian's RFC proposal and i have taken them as i think they better fit the information we have a that point.

The proposal was just a starting point and an attempt to show we can improve things - it was not gospel

[zero-24]

Then change the language on that page to reflect the intention. Your proposal takes vague language and makes it sound like "This is the One Absolute Truth" when it's most definitely not the case.

Well the updated strings are comming from Brian's RFC proposal and i have taken them as i think they better fit the information we have a that point.

The proposal was just a starting point and an attempt to show we can improve things - it was not gospel

Agree the same is mine. And I'm sorry that this sounded as this is the one absolute truth this was not the intention.

[GeraintEdwards]

Sorry for my lack of earlier response to this RFC - been snowed under and then when I was ready to dive in yesterday I had an internet outtage :( Thank you @zero-24 for your work on this.

A few observations:

1. Compatibility checking already takes account of extensions that are part of a package i.e. we don't check for plugin compatibility if that plugin ispart of a package. Any checks on plugin compatibility in this RFC should use the same mechanism to assess if the developer has 'said' they are compatible with J4. However there are a couple of complications to consider

• A package can theoretically be part of another package,
• Some extensions list the update server for the package within the component manifest (probably dating from the days before packages existed within Joomla) i.e. when you upgrade the component its actually the package that updates. At present this type of compatibility is ignored and treated as no update information available.
• An extension that was installed as part of a package but is no longer part of the current installable package could cause a problem (as @nikosdion mentions). As present the update compatibility checker doesn't do a double check on for this type of orphan package. This check could be done via the extension's manifest_cache or via manifests/package/pkg_extension.xml file directly if required?

2. We need to remember to treat extensions that offer a J4 compatible version that AREN'T J3 compatible as a special case. It may well be wise to advise the user to disable these extensions BEFORE the upgrade and to upgrade the extensions and re-enable them AFTER the Joomla upgrade. If they choose not to do so they need to go through the same super approval as mentioned above.

3. I like the idea of identifying the plugins that could be called during the upgrade finalisation step, checking if they are marked as 'compatible' or part of a 'compatible package' and then requiring the site manager needing to make the specific choice to carry on with an upgrade if they choose to leave these 'enabled'

4. @nikosdion has a good point about conflicting update information. It would be good to get/construct a specific example of this to test the current update compatibility checker in Joomla 3.10

With regards to updating services - I personally don't envisage any problems with taking account of this type of pre-upgrade checking during the update process. A public method that allows us to determine the relevant 'incompatible' plugins would be helpful.

[GeraintEdwards]

I'm taking a look at this to pull together a PR within the next week.

Once we have some code to look at we can hopefully iron out concerns people may have.

[GeraintEdwards]

I am attaching a patch file here as a prelude to a full PR.

UpdateCheckerPluginChecksAndWarnings.zip

You can use the sample extensions from #29524 if you need extensions to check against.

Please note that I've also added handling for an update server that throws and error or timed out - in default.js there are some commented lines 174-183 to simulate this scenario.

If this looks like it could be a runner solution I'll put together a PR.

[zero-24]

Closing as there is now a PR from @GeraintEdwards at: #31200. Thanks!