All Text is strengthened
When status is unknown you have to either click to disable the extension or click to confirm you are ignoring the warning before continuing

I like the new texts. Can we do a PR for that already?

As for the buttons I'm not that good in JS to build such a thing and right now that result of the checker is not stored somewhere so we would need to save the decision to ignore or disable the extension somewhere.

So you cannot update if there is any extension in the Yellow update required section and there is any extension in the compatability unknown section if the user hasnt either disabled or accepted the warning

I'm not sure whether we should block the update because of errors / warnings there as you said failed extensions are totally fine but only the upgrade should not be fubar.

So i would go with a check for system plugin from that list and than block the update with an captive login + a general warning or error once there are other extensions not marked ready for 4.x

When status is update required you have to click to update before continuing

Hmm depending on how the developer wrote the extension it might be possibe that this extension only runs on 4.x so you have to update after the upgrade to make it work.
I have been told that some Developers still plan to maintain a 4.x only version of the extension that is not going to work on 3.10.

What do you think?

result of the checker is not stored somewhere so we would need to save the decision to ignore or disable the extension somewhere.

Absolutely they need to be stored so that you can see a list of what was disabled etc and what needs to be updated once you are in j4

if you have a j4 only extension (that's already exists in j3) it's likely that you have to uninstall the extension.

Reason for this is that the extensions developer have to delete the old files manually... so a lazy developer who doesn't like to create an intermediate version (a version that can be upgraded but doesn't look good in j4) may also don't think about people try to upgrade with a disabled extension and install the new version in j4.

ymmv

I still think just write a warning and let handle the uninstall/disable to the user. For example disabling a system plugin can lead to an unusable site.

if you have a j4 only extension (that's already exists in j3) it's likely that you have to uninstall the extension.

Reason for this is that the extensions developer have to delete the old files manually... so a lazy developer who doesn't like to create an intermediate version (a version that can be upgraded but doesn't look good in j4) may also don't think about people try to upgrade with a disabled extension and install the new version in j4.

You can have version 1.0.0 running on 3.x and 2.0.0 running on 4.x only.
And i would say when you coose to do a re implementation you should think about an migration path. Whether that is upgrading to an intermediet version upfront or right after the core upgrade.
Both i think are valid szenarios

ymmv

?

I still think just write a warning and let handle the uninstall/disable to the user. For example disabling a system plugin can lead to an unusable site.

Yes that is my proposal too but i would issue an error not 'just' a warning. ;-) We can there ask for confirmation that they know what they are doing and suggest to disable all system pluigins (or better anything that is not marked to be compatible).

result of the checker is not stored somewhere so we would need to save the decision to ignore or disable the extension somewhere.

Absolutely they need to be stored so that you can see a list of what was disabled etc and what needs to be updated once you are in j4

Hmm as for the updates they should come up in the updater after the upgrade is done too. I'm not sure whether we have to store them.

As for the disabled extensions they should be re enabled case by case by the site administrator right? When we enable all the site (but not the Upgrade) might be broken already right?
So when we go this path here we might want to show a list of extensions disabled by the pre upgrade checker.

Hmm as for the updates they should come up in the updater after the upgrade is done too. I'm not sure whether we have to store them.

Good point I forgot that

So when we go this path here we might want to show a list of extensions disabled by the pre upgrade checker.

yes

This is looking promising. I think it would be good to get Geraint involved as he was involved with the final build of this but has further developed it in Yoursites.

It's just a drawing - no code behind it and definitely beyond my skillset

yes @brianteeman just a drawing but i think the concept is lovely. it reminds me "prestashop updates UX"

somebody here with the skills can tell me if that part can be ajax?

This is looking promising. I think it would be good to get Geraint involved as he was involved with the final build of this but has further developed it in Yoursites.

When you ask Geraint about it please tell him to contact me before he starts coding so we define the solution upfront. As right now we have different proposals to solve this issue floating around and no definitive solution defined yet. ;-)

yes @brianteeman just a drawing but i think the concept is lovely. it reminds me "prestashop updates UX"

Can you share more details with us on that?

somebody here with the skills can tell me if that part can be ajax?

I'm no JS guru but as far as I know yes this can be done with ajax.

Just had a really constructive conversation with Geraint and we totally understand Brians valid issues which do need to be addressed. This is an opportunity to really improve the user experience. Geraint has identified 3 areas that things could happen and be improved. Happy to facilitate a google meet any time if a 30 minute chat is needed to thrash it out

Hi @zero-24 SURE! here is a screenshot for prestashop updates (this screen is also called when users want update to next releases) sorry for italian backend language in screenshot.

Just had a really constructive conversation with Geraint and we totally understand Brians valid issues which do need to be addressed. This is an opportunity to really improve the user experience. Geraint has identified 3 areas that things could happen and be improved. Happy to facilitate a google meet any time if a 30 minute chat is needed to thrash it out

Yes please contact me with proposed dates and times that work for you so we can discuss and come back with an proposal here.

Hi @zero-24 SURE! here is a screenshot for prestashop updates (this screen is also called when users want update to next releases) sorry for italian backend language in screenshot.

Yes but what are the options on the right hand side other than upgrade? And what would be shown once the current plugin is not compatible with the next prestashop version?

here the hand side.

And what would be shown once the current plugin is not compatible with the next prestashop version?

Good question - i really do not know the answer...
i was talkin about "prestashop UX" in terms of functionality we already know what to show or not? i think the options gived by @brianteeman are cool -- compatibility unknow? "disable" - "go ahead and let it blow" | Update required ? "update it!"

here the hand side.

And what would be shown once the current plugin is not compatible with the next prestashop version?

Good question - i really do not know the answer...
i was talkin about "prestashop UX" in terms of functionality we already know what to show or not? i think the options gived by @brianteeman are cool -- compatibility unknow? "disable" - "go ahead and let it blow" | Update required ? "update it!"

Thanks!

I've been having a think about this.

I like the idea of beefing up the warnings and the idea of disable/ignore warning.

I'm wondering if we go a little further with this and add a 3rd option (which would be the default choice) of 'select an action' and then blocking the upgrade until the user has specifically toggled to 'ignore warning' or 'disable extension'.

Stepping back a little though I'm wondering if we could look at a more holistic approach. What we are aiming for is making the upgrade process straightforward and safe. I think there are 3 parts of this:

1. Prior to the upgrade
2. During the upgrade
3. After the upgrade

What is the best way to deal with these?

1. Prior to the upgrade

This proposal definitely helps here - getting the site into as neutral and safe a setup as possible prior to upgrade is a really important thing to do. Need to think of the best way to keep track of what was disabled during this process - possibly via a 'modified' time stamp in the extensions table to record the last time an extension was changed, upgraded or disabled??

2. During the upgrade

There is always a risk that a system plugin could break the upgrade process and possibly leave a site 'trashed' (not experienced this scenario myself but have heard it can happen). Even for extensions marked as J4 compatible there is always a risk of a developer error or unexpected scenario :(

This may be a silly question, but, is there any reason for 3rd party plugins to be enabled during the Joomla upgrade process?? The script that loads the plugins, when called during the upgrade process, could disable all 3rd party plugins (possibly with the exception of plugins that trigger responses to upgrade specific hooks?). This wouldn't be disabling them permanently - just for the duration of the upgrade process. That way the upgrade process is clean and soley under the control of Joomla code.

3. After the upgrade

A system, content or other plugin (or module/component come to that) could stop a site from working after the upgrade succeeded. This could be true even if the developer has marked the extension as J4 compatible.

In YourSites we have a mechanism (using suitable error handlers) where a php error, that crashes a site, caused by a plugin or other extension can be identified and the source of the problem can then be disabled remotely. That isn't an option for the Joomla core but there may be a way we could incorporate a 'rescue mode'. A URL e.g. such as /administrator/rescue could offer a login (BUT with all system plugins disabled for the duration of the 'rescue' effort). We would, of course, need to think about how to deal with security addons that control access to the site based on IP address etc. We could possibly make this URL available AFTER a 500 error has been triggered (by using a suitable error handler), only to specific IP addresses, subject to 2FA etc.

The idea is to make it more straightforward to restore a broken site - may be a useful feature for Joomla independent of the upgrade process.

p.s. not sure if an ajax/json upgrade of an extension is a good idea - it would be extra work to handle all the possible resultant states e.g. extensions that run post install javascript or require user intervention. I think a popup/new window would be safer and easier.

I've been having a think about this.

I like the idea of beefing up the warnings and the idea of disable/ignore warning.

I'm wondering if we go a little further with this and add a 3rd option (which would be the default choice) of 'select an action' and then blocking the upgrade until the user has specifically toggled to 'ignore warning' or 'disable extension'.

Stepping back a little though I'm wondering if we could look at a more holistic approach. What we are aiming for is making the upgrade process straightforward and safe. I think there are 3 parts of this:

1. Prior to the upgrade
2. During the upgrade
3. After the upgrade

What is the best way to deal with these?

1. Prior to the upgrade

This proposal definitely helps here - getting the site into as neutral and safe a setup as possible prior to upgrade is a really important thing to do. Need to think of the best way to keep track of what was disabled during this process - possibly via a 'modified' time stamp in the extensions table to record the last time an extension was changed, upgraded or disabled??

Hmm yes and no we can not store it in the session as that might be trashed already. Also the database could be an issue as it could be that we disabled database access. We might write it to a protected file? I'm not sure whether we should disable and re enable them at all.

After i thourght more about it and based on the feedback we got from Nicholas i personally would no longer disable extensions automaticly but let the site admin choose to disable them. And than he can re enable them on by one and see what breaks. So we does not have to carry the ids around and also allow the site admin to choose what is best for that given site.

2. During the upgrade

There is always a risk that a system plugin could break the upgrade process and possibly leave a site 'trashed' (not experienced this scenario myself but have heard it can happen). Even for extensions marked as J4 compatible there is always a risk of a developer error or unexpected scenario :(

This may be a silly question, but, is there any reason for 3rd party plugins to be enabled during the Joomla upgrade process?? The script that loads the plugins, when called during the upgrade process, could disable all 3rd party plugins (possibly with the exception of plugins that trigger responses to upgrade specific hooks?). This wouldn't be disabling them permanently - just for the duration of the upgrade process. That way the upgrade process is clean and soley under the control of Joomla code.

As explained by Nicolas in the other issue you could have a system plugin that is adding / loading a database handler once you disable that your site and upgrade is broken too.

3. After the upgrade

A system, content or other plugin (or module/component come to that) could stop a site from working after the upgrade succeeded. This could be true even if the developer has marked the extension as J4 compatible.

Yes but what should we do about an extension explizit marked as compatibel but is still breaking the update?

To be fair this is nothing new this is a issue that exists since all versions that have com_joomlaupdate i guess or atleast since we have the finalise step in the updater and till now nothing breaks. Now with 4.x this comes up as major changes has been done that also affect system pluigins.

In YourSites we have a mechanism (using suitable error handlers) where a php error, that crashes a site, caused by a plugin or other extension can be identified and the source of the problem can then be disabled remotely.

Yes the problem here is that the site still needs to be loaded. But that is no longer the case once the upgrade failed once. It is a nice feature for sure. Similiar things are used in WP too.

That isn't an option for the Joomla core but there may be a way we could incorporate a 'rescue mode'. A URL e.g. such as /administrator/rescue could offer a login (BUT with all system plugins disabled for the duration of the 'rescue' effort). We would, of course, need to think about how to deal with security addons that control access to the site based on IP address etc. We could possibly make this URL available AFTER a 500 error has been triggered (by using a suitable error handler), only to specific IP addresses, subject to 2FA etc.

The idea is to make it more straightforward to restore a broken site - may be a useful feature for Joomla independent of the upgrade process.

Yes but i would branch out this rescue mode as a different feature request for 4.1. As for the upgrade it does not help given at the time this could kick in the site is aready fubar. ;-)

But it is a nice feature for more general php errors that broke the site. WP got the way that they check the stack trace and only disable the extension that causes the problem so all other pluigins still run including possibly auth and system plugins.

p.s. not sure if an ajax/json upgrade of an extension is a good idea - it would be extra work to handle all the possible resultant states e.g. extensions that run post install javascript or require user intervention. I think a popup/new window would be safer and easier.

I agree therfore my suggestion for a dedicated message once system plugins are detected that could break the site upgrade (as we don't know whether they are compatible or not) and with a 'are you sure' and 'please disable this extensions' message. That asks with an captive login for SU access data.

Please find here a RFC regarding the issue discussed here: #31042

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