User tests: Successful: Unsuccessful:
Pull Request for Issue #31042 (edited to add testing packages)
New method in JoomlaupdateModelDefault -> getNonCorePlugins which fetches a list of plugins filtered by optional list of plugin folders. The returning array excludes core Joomla plugins.
PreUpdate Check now fetches a list of 'system','user','authentication','actionlog' and 'twofactorauth' plugins that could, conceviably, break a Joomla upgrade if they contain code that isn't compatible with the targetted Joomla version
The PreUpdateChecker javascript now:
The messages displayed are changed as the update checker is run.
In a J3.10 dev site install some extensions that are NOT compatible with Joomla 4 - at least one out of date version of an extension and one where there is no published J4 compatible version. Ideally you should have one with an invalid update server entry too.
I am attaching some test packages you can use to check - make sure to enable the system plugins after installing these test extensions. The components and plugins do nothing.
testuptodatepackage.zip
testuxpackage.zip
testwuj3ej4package.zip
testwuj3n4package.zip
testwuvcpackage.zip
testxupackage.zip
Then open Joomla Updater component and observe the pre-update checker tab and the live update tab - as the update checker is running and after it has completed
You would be able to upgrade Joomla with an incompatible plugin installed that could 'brick' (i.e. kill) your Joomla installation which would involve a lot of work to resolve.
The modified update checker will stop you from performing the upgrade unless you have no incompatble plugins OR you click a checkbox to say you know what you are doing.
Once the PR is finalised the update checker and update process pages will need to be updated.
https://docs.joomla.org/Pre-Update_Check
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_joomlaupdate Language & Strings JavaScript |
Labels |
Added:
?
?
|
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:
Language comments-
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.
Labels |
Added:
?
?
|
Geraint is correct.
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.
@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.
@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:
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.
Labels |
Added:
?
Removed: ? |
I have tested this item
I have tested this item
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
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.
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:
I have tested this item
from my understanding this can go RTC
up to RL now
Status | Pending | ⇒ | Ready to Commit |
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!
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-03-26 20:41:54 |
Closed_By | ⇒ | zero-24 | |
Labels |
Added:
?
?
?
Removed: ? |
@GeraintEdwards @zero-24 Is it by purpose that the minified js is deleted by this PR now in the 3.10-dev branch?
Will take a closer look over the weekend
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
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?
