hmm seems I'm missing something? I have installed the demo extensions as mention above + this plugin of my own: https://github.com/zero-24/plg_system_advancedredirect/releases/tag/1.0.3 (it does not yet have a 4.x compatible version via the update.xml)

That extensions are also correctly listed here:

But the Live Updater still looks the same and does not mention the plugins?

You installed the packages from above and enabled their system plugins?

Ah i have just installed that plugins without enableing them. Once enable they show up as expected ?

@brianteeman can we please get your feedback on the new process + the texts proposed here? Thanks!

@GeraintEdwards Thanks for that PR i think this is a good step forward.

What do you think about the idea to allow the plugins to be disable on the Live Update tab similiar to the RFC that Brian did?

The basic idea would be to change the table you did here:

To something like this (sorry very bad paint skills on my side)

And all plugins checked there get logged & disabled as first step here: https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_joomlaupdate/controllers/update.php#L107

The idea of disabling selected plugins is good but there are potential downsides:

• We would need to distinguish between plugins to disable temporarily (with the session, if the session data is safe??) to be re-enabled on completion and those that should be disabled permanently.
• The user may not realise that disabling a plugin could have unforseen consequences - the site may be inaccessible after the upgrade completes.
• Is it possible that disabling the plugins at the start of the upgrade process could cause the site to die?? Not sure as I've not checked which plugin triggers are fired after this point? onAfterRender etc??

Language comments-

• Some good catches. Thanks
• 'impossible' vs 'not possible'. To me 'impossible' has an air of permanence where, in reality, simply trying again could resolve the issue (e.g. problem was caused a timeout). Happy to go with the majority view though.

The idea of disabling selected plugins is good but there are potential downsides:

• We would need to distinguish between plugins to disable temporarily (with the session, if the session data is safe??) to be re-enabled on completion and those that should be disabled permanently.

Anything checked here should be disabled permanently. As we can not be sure that the session is passed over.

• The user may not realise that disabling a plugin could have unforseen consequences - the site may be inaccessible after the upgrade completes.

Well he accepted that but now the upgraded site is not bricked so he can come back and fix the issues. And I'm sure that when someone has a that critical plugin installed they check that upfront. I'm not sure whether we can do much more at this point.

• Is it possible that disabling the plugins at the start of the upgrade process could cause the site to die?? Not sure as I've not checked which plugin triggers are fired after this point? onAfterRender etc??

At that point where i suggested to disable the plugins that system events where executed already but all within the 3.x code so all should be fine. The problem is when they are expecuted in the middel of the upgrade process but at that time they are no longer active when checked.

Language comments-

• Some good catches. Thanks
• 'impossible' vs 'not possible'. To me 'impossible' has an air of permanence where, in reality, simply trying again could resolve the issue (e.g. problem was caused a timeout). Happy to go with the majority view though.

Same for me. I have mention brian above so we can get his view on that strings form a native speaker perspective.

Geraint is correct.

We need to switch the extension checks and the system checks around or move extensions to its own tab because as it is right now anyone using a screen with <900px approx may not even know there is the extension section

It was only because I was looking for some strings that I see in the code that I realised that there was a popover

Suggestion

Can we add a button please or something to make it absolutely blatantly in your face obvious. Perhaps

general comment on strings. some people might prefer to use "may" instead of "could" - i have no preference

if possible we should talk about the website and not your site

We need to switch the extension checks and the system checks around or move extensions to its own tab because as it is right now anyone using a screen with <900px approx may not even know there is the extension section
re switching the ordering of the sections what about using 'More Detail'

e.g.
"Required PHP & Database Settings" Passed [More Detail]
"Recommended PHP Settings" Warning [More Detail]
the warning could highlight that output buffering is enabled

That could work as well

It was only because I was looking for some strings that I see in the code that I realised that there was a popover

Suggestion

Can we add a button please or something to make it absolutely blatantly in your face obvious. Perhaps

Good idea

On a separate note I think Joomla needs a 'house style' for 'information available' or 'action required' icons/buttons etc. As you say avilability of popovers/tooltips is not always obvious!

@brianteeman I've updated the code now.

1. I'm not happy with the 'more information' icon/button - I think it would be cleaner to indication within the yellow warning that some more information is available Not sure the best way for this to be clear and to look good
2. The chevron in the php settings is not rendered properly straightaway - This could be fixed by causing the preupdate checker to wait for DOMContentReady before starting. This is probably a good idea and will only delay things by a fraction of a second.

@zero-24 and @brianteeman

Any thoughts on the layout of the list of plugins and their packages on the 'live update' tab - we could try to present information about the author of the extension to display here and a link to the site (if available). Anything else?

Any thoughts on the layout of the list of plugins and their packages on the 'live update' tab - we could try to present information about the author of the extension to display here and a link to the site (if available). Anything else?

Yes I would propose to link the authorUrl / packagerUrl (for packages) with the author / packager (for packages). When there is no link than just the name, when there is no name but a link maybe fallback to "Developers website" with the URL when nothing is aviabe show that we have no information about the developer.

Any thoughts on the layout of the list of plugins and their packages on the 'live update' tab - we could try to present information about the author of the extension to display here and a link to the site (if available). Anything else?

Yes I would propose to link the authorUrl / packagerUrl (for packages) with the author / packager (for packages). When there is no link than just the name, when there is no name but a link maybe fallback to "Developers website" with the URL when nothing is aviabe show that we have no information about the developer.

I've done this now. It outputs the author and the authorUrl from the plugin manifest and if not available the equivalent values from the package manifest.

Start with J!3.10 alpha4-dev

• Install all plugin
• Enable plg

Before apply PR

### After apply PR


The plg are confermed but there are 2 allert red & 1 orange.

@GeraintEdwards taking a look at this today following your mention in BF@H channel.

When this is finally merged, please advise (if I don't spot it first) as I've added this to the Joomla 4 JCM series, and will also help with documenting the process on JDOCS.

I'm testing 3.10 on the skeleton build I use for implementing new sites (and my, there's a lot of extensions needing update compatibility information added) so it's got a considerable list of 405 extensions in the Manage list.

So performance issues aside, here's some feedback on what I've seen going through the comment history above.

• The "Update Required" section I think should come first in the list - Extensions identified as Update Required really should be updated first, as it's possible the update contains the Update Information, and they should be ideally updated regardless of what the Update Information availability is returned as).

• [More Detail >] was previously positioned to the right which I think looks better. Otherwise, it should go under the section title if not back on the right.

• With 405 extensions checked (less core) the groupings are quite lengthy. Would it be better to put each section in an accordion slider, so that then the results are presented in groups with the description for that section visible, and then an expand button to then open up the list?

• Is hiding the information that is displayed when you click on [More Detail >] worth hiding (is there history behind it?)

• Should the columns read left to right: Extension Name, Installed Version, Extension Type, Update Compatible Version, Currently Compatible Version, Update Compatible Version

• "Update Compatible Version" and "Currently Compatible Version" - compatible to what? Do we need to perhaps make these language strings more specific if this is what they actually refer to?
  Currently Compatible Version = Version compatible with Joomla 3.x
  Update Compatible Version = Version compatible with Joomla 4.x

On applying the current version of the patch, but before trying to install a test extension:

• the [More Detail >] links are no longer clickable.
• the Extensions Pre-Update Check did not automatically start when the patch was applied

I've then installed the test extensions, but as the pre-update check did not trigger, and could not be manually triggered, I couldn't see the results for the 6 test packages yet.

Start with J!3.10 alpha4-dev
...
The plg are confermed but there are 2 allert red & 1 orange.

Somehow the auto-running of the PreUpdateChecker was broken in my last commit :( This is now working

Thanks @particthistle

* The "Update Required" section I think should come first in the list - Extensions identified as Update Required really should be updated first, as it's possible the update contains the Update Information, and they should be ideally updated regardless of what the Update Information availability is returned as).

Danger is with 'Update Required' first is that users might not realise how serious things are? Maybe if they are hidden with accordion/toggle with number of affected extensions everything would be visible upfront.

* [More Detail >] was previously positioned to the right which I think looks better. Otherwise, it should go under the section title if not back on the right.

I had broken the auto-running of the checker - I have corrected this now and the [More Detail >] is back where is should be!

* With 405 extensions checked (less core) the groupings are quite lengthy. Would it be better to put each section in an accordion slider, so that then the results are presented in groups with the description for that section visible, and then an expand button to then open up the list?

I'm open to this idea or a toggle to minimise each block but I think they should be fully visible initially·

OR the number of affected extensions should be in each header at least.

What do you think?

* Is hiding the information that is displayed when you click on [More Detail >] worth hiding (is there history behind it?)

My initial thought was to have it all visible but it was suggested this could make it overwhelming to some users.

Is there a way to do a vote on this type of question in GitHub??

* Should the columns read left to right: Extension Name, Installed Version, Extension Type, Update Compatible Version, Currently Compatible Version, Update Compatible Version

Or
"Extension Name, Extension Type, Installed Version, Update Compatible Version, Currently Compatible Version" ?

Again how do we ascertain consensus?

* "Update Compatible Version" and "Currently Compatible Version" - compatible to what? Do we need to perhaps make these language strings more specific if this is what they actually refer to?
  Currently Compatible Version = Version compatible with Joomla 3.x
  Update Compatible Version = Version compatible with Joomla 4.x

A good idea - but we need concise headings too. So 'Joomla 3.x Compatible Version' etc.

The number values should not be hard coded as 4.x etc. since the check will work with whatever the target Joomla version is e.g. "4.0.0 beta 5" of "4.1.0 RC2" etc.

The descriptors then get a bit long

@zero-24 How do we continue with this PR? It shows that you have requested changes during a review. I've gone through the history to see if that meanwhile has been resolved, but I could not really find the details. Could you check and if ok just give again a review with approval so the change request will disappear at the bottom of the PR?

I would say you can remove my review given that they are indeed solved. The next steps here would be testing i would say.

@adj9 @particthistle Could you test this PR again after it has received changes? Thanks in advance.

In addition to testing @particthistle bumping questions from #31200 (comment) please

I'm sorry that it took that long to get back into this. I have just tested the process and I think this is a good step in the right direction.

@GeraintEdwards
While i was testing i have "just" installed the extensions you have provided here in the inital issue but i have not enabled any additional extension. While at this point no "brick my site" plugin was active it seems the headers for the table was still rendered. I would say lets just remove the table in that case.

The other case I have tested is an 3.10 without any extension installed:

The Live Update screen claims to still checking while the pre Upgrade checker already issued that no extension is installed. So in this case i would propose to remove the warning as well as the table header etc too.

A tip for all testers go to the disabled extensions and enabled them to get plugins that are not compatible.

@zero-24 I have updated the JS to hide the table headings when there are no problem plugins and to do so as soon as the list has been cleared (as opposed to waiting for the full checks to complete)

@particthistle I have re-ordered the output columns and updated the labels to show the current Joomla version and target version which should make them easier to interpret.

I think this PR is ready for final testing now.

@GeraintEdwards the first issue mentind is fixed now Thanks! But the seccond one is still there.

When you have zero extensions installed the live update claims to Pre-Update checks have not been completed yet - please wait. But when checking the Pre-Update check it correctly states No extensions installed..

Good catch on the no-extensions and no non-core critical plugins installed scenarios. I have amended the javascript to reflect these situations now.

I have tested this item ✅ successfully on b3e691a

I have tested this item ? unsuccessfully on b3e691a

Sorry @GeraintEdwards - will chat more at JUGL on this. Apologies for delay looking at it after changes back in December. I've now adjusted my Github notifications so they appear somewhere I see them when I'm not on Github.

Testing unsuccessfully based on the UX more than the functionality (also reviewing my comment from last year).

The "check" process appears to work fine, albeit that the bulk of extensions returning Update Information Unavailable (@Llewellynvdm - a discussion JED need to have with developers to onboard them to this process)

I've recorded a screencast to show where the bugs lie: https://www.screencast.com/t/VygEBpCvR721

• Accordions for information blocks are not toggling (tested in both Firefox and Chrome on Windows)
• Language strings in the process do not indicate anywhere that the Pre-Update Check is actually checking everything in preparation of installing Joomla 4.
• Link to JDOCs page on "pre-update check documentation" should open in a new tab/window.

  ---

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

The issue with the toggles looks to be string that's not defined (my JQuery skills are not good enough to suggest a fix).

Language strings in the process do not indicate anywhere that the Pre-Update Check is actually checking everything in preparation of installing Joomla 4.

That has been patched outside of this PR: #32098

Given that the pre Upgrade checker does not always check against Joomla 4 but the next target version provided by the updater.

Language strings in the process do not indicate anywhere that the Pre-Update Check is actually checking everything in preparation of installing Joomla 4.

That has been patched outside of this PR: #32098

Then it would maybe be good to update this PR to latest 3.10-dev so it contains this change, i.e. merge the 3.10-dev branch from upstream into the branch for this PR here.

@GeraintEdwards Let us know when you need help with that.

@particthistle

The issue with the toggles looks to be string that's not defined (my JQuery skills are not good enough to suggest a fix).>

This is a strange error as these variables are declared in default_preupdatecheck.php and I don't see this error arising. Viewing the web page source I can see them defined.

The only 2 possible explanations I can think of for you seeing these problems is that:

1. You have some sort or plugin that defers the execution of 'inline' javascript code so that the update check starts before these variables are parsed ??
2. The sheer number of extensions you have is causing an issue in some way

@richard67

Language strings in the process do not indicate anywhere that the Pre-Update Check is actually checking everything in preparation of installing Joomla 4.

That has been patched outside of this PR: #32098

This has been merged so I see the changes here too.

I have tested this item ✅ successfully on b3e691a

from my understanding this can go RTC
up to RL now ?

RTC

I'm now finally going to merge this here into 3.10. I would like to issue a massive thanks to @GeraintEdwards who did a great job with this PR and all the testers who tested and gave feedback.

Just to make things clear. The Pre Upgrade Checker itself is one of the main features of 3.10 and this here is an great extension to the existing tool. I'm happy to hear, read, review and accept additional improvments on this tool. So I would like to encurage everyone who has additional feedback on this tool please step up and lets discuss now what can be improved and how. Feel free to report issues or provide PRs here. But please feel also free to contact me via mail (tobias.zulauf[at]community.joomla.org) or Glip. Thanks!

@GeraintEdwards @zero-24 Is it by purpose that the minified js is deleted by this PR now in the 3.10-dev branch?

See PR #32883 .

Will take a closer look over the weekend

@zero-24 Not sure what closer look it needs. If you check the folder where the missing minified script which will be added with my PR #32883 is located, you will see that for the other js files minified versions are there, only not for that one handled with my PR and mentioned in my above comment.

Yes but when its about JS i always have to take a soccond look when at my desk, because its JS ;-)

I can confirm this minified file was accidentally removed #6c00eec7a69df98a730ea71f17d891fb33f5533e on 31/01/2021

The issue with developing/debugging JS in Joomla is that you can't debug unless you enable Joomla debug mode and then Joomla forces a new version of the file on the browser each time you refresh the page (through the 'getMediaVersion query string) so all your JS breakpoints are lost. An easy workaround for this is to temporarily rename the min.js file . I must have accidentally let it slip through the commit :(

The docs page has been updated: https://docs.joomla.org/Pre-Update_Check