“Potentially serious problem” in Joomla! Update is misleading #34599
Comments
|
The intention is that plugins that are running while the upgrade is in progress can break the site to a point where there is no return. IIRC its not intended to show the message once the plugin / package is marked as compatible. When there are changes to the language strings or the feature itself done i would propose to do that within 3.10 cause the main reason to have such check is there. Cause we removed isAdmin / isSite in 4.x and plugins (not only system ones) could break the upgrade to a point of no return. When there are better texts i'm happy to review and merge them into 3.10. |
|
In case I wasn't clear, even though I made a point of explicitly stating it: I do understand the intention, I have read the discussion around it and I agree with the intention. The problem is that the execution DOES NOT follow the intention. It does something else which is wrong and misleading. Any changes must be applied to BOTH Joomla 3.10 AND Joomla 4. It's not an either/or. Both identical implementations are broken. As I said, it's not just a technical change and it's not just a language change. It's a combination of both. I made sure to provide a lot of detail as to how this SHOULD work and even gave you the language strings to go with it. I did ask native English speakers about the language strings you currently have and the ones I propose to make sure that the current strings don't make sense and my proposed ones do. That's more than the Joomla project did the past two years. I am afraid I do not have the time to fix what the Joomla project has broken. I can only tell you what is broken, why it's broken and how to fix it. I still need to work on my own software, rewriting it with Joomla 4 core MVC and Bootstrap 5 styling. If you feel nobody has the time to fix this feature so it works as it should, then I strongly recommend removing it and reintroducing it in a fixed, properly working form at a later point in time. After all, the whole point of the Joomla Update component being updatable separately from Joomla itself was that any issues with it could be dealt with without entering a chicken and egg situation — in fact, it was introduced precisely because we did hit a chicken and egg situation around Joomla 3.4 if memory serves (broken restore.php; I remember the discussions we had with Michael and George about how to best deal with a really bad situation that was mostly my fault). |
Great so we agree here :)
Thats great than I understand it correctly now, and again i'm happy for the feedback. Its also good that native speakers even provided that strings so we can improve the pre upgrade checker. |
|
Thank you! This helps a lot. One more clarification (I realised I didn't say this before): This feature is a good idea to have even for minor release updates, not just major updates. As experience has taught us, just because a plugin works with Joomla X.0 does not mean it will work reliably with X.1 as well. Joomla does introduce surprise changes in minor versions: either last minute changes or security fixes which act as such. Since we're here, let me tell you that I am interested in helping you test any update-related features against real world extensions. If you need access to paid extensions drop me a line and I can give you access to mine. If necessary, I can even create a mock extension with tailor-made updates and its own "paid" download area (basically, a download URL with a static download key). Having good-behaved update features is beneficial for all parties involved: users, the Joomla project, and 3PDs. |
Thats great, and I fully agree on that. Thats why I asked for feedback on the release notes, twitter, magazin, github etc from "real world" extension devs. Will ping you when a PR is aviable to test. |
I referenced this matter in passing in discussing J! 3.10 but the issue was overtaken by other concerns. |
|
My 2 cents: I'd also appreciate a few events in the Pre-Update Check process - for example, some plugins that our extensions install are marked as "Potentially Serious Problems" because there are no update servers for them (they are part of the component package, can't be installed separately so they're always updated along with the component). I can imagine the flood of concerned users that won't proceed with the update because of that message... that will persist on every Joomla! update. Having some events that pass Otherwise, we'll have to add update sites to every plugin our components install, which will create overhead for us (we'll have to split the installation package so that everything can be downloaded and installed separately, something that users don't need) as well as confuse users (instead of a component update that handles everything they'll be presented with lots of updates for the same product). I also agree that the wording and/or process needs to be improved. |
|
@OctavianC This use case doesn't need an event. As long as an extension is part of a package (the There is a problem, though, if someone uses the Discover feature to install an extension. In this case the The use case which is actually problematic is extensions which are installed standalone and do not have an update package. For example, I have several small extensions I use on my sites which don't have a public update server. For example, I have purpose-built modules for my site's headers (as the design needs them to be above the breadcrumbs module area) and even a purpose-build component for displaying the PHP and Joomla version compatibility of my extensions. These appear as not compatible with Joomla 4 even though they are. I am a developer, I understand this, no problem. However, site integrators also do the same thing on their clients' sites, especially when they want to make small changes to core modules which cannot be fully covered by template overrides. In this case the site they deliver will always appear as having incompatible extensions which will be confusing to the end client who's neither a developer nor a site integrator. One way to address that would be introducing the version compatibility information for these extensions in the XML manifest itself. If Joomla can't find that information in the update server or there's no update server available it would look into the XML manifest instead. If someone is about to complain that the XML manifest can lie about the compatibility status, yeah, so can the update server. I've seen commercial extensions with update servers claiming to be compatible with all Joomla 4 versions even before 4.0 is released. Will they be compatible with all 4.x releases? Doubtful, given Joomla's proclivity to making breaking changes in minor releases with total disregard to SemVer (if Joomla actually implemented SemVer we'd be in Joomla version 134 or somewhere around that number already). So, if we are happy with people lying on their update servers why not let them lie about it in their XML manifests as well? Seems par for the course to me. |
|
Thanks we just had a chat with @softforge @wilsonge and we came up with |
|
@zero-24 I EXPLICITLY said that this is NOT just a language issue. Your fix doesn't fix anything at all. RIGHT NOW — AND AS I EXPLICITLY MADE YOU AWARE OF THREE WEEKS AGO — ALL THIRD PARTY EXTENSIONS WITH A SYSTEM (OR OTHER ALWAYS LOADING) PLUGIN APPEAR AS CAUSING A POTENTIAL UPGRADE ISSUE. THIS IS AN ABJECT LIE WHICH IS HARMFUL TO THE REPUTATION OF THIRD PARTY EXTENSION DEVELOPERS. IT IS ALSO INCREDIBLY IRRESPONSIBLE ON YOUR PART BECAUSE IT WILL MISLEAD JOOMLA USERS INTO DISABLING THESE PLUGINS, BREAKING THEIR SITES WITHOUT ANY INDICATION THAT THIS LIST OF PLUGINS THEY ACTED UPON WILL NEVER, EVER APPEAR AGAIN. FINALLY, IT IS INCREDIBLY STUPID BECAUSE IT BETWEEN THE BAD ADVICE LEADING TO BROKEN SITES AND MISLEADING JOOMLA USERS INTO BELIEVING THAT VIRTUALLY ALL MAJOR JOOMLA EXTENSIONS ARE BROKEN (CAUSING UPGRADE ISSUES) MAKING THEM UNTRUSTWORTHY YOU ARE EFFECTIVELY DISSUADING THEM FROM USING JOOMLA AT ALL. Again, you are printing this FALSE AND MISLEADING warning for ALL extensions, even those which EXPLICITLY state that they support the version of Joomla the user wants to upgrade to in their update XML sources. Do you understand what this means? Let me spell it out. OpenSourceMatter Inc's product is DELIBERATELY affirming falsehoods for the software products of third party companies while keeping mum about any similar “potential upgrade issues” on its FIRST PARTY software products. This is something even Big Tech doesn't do because they understand this is the fastest path to being sued to their eyeballs for preferential treatment of first party products on what is, in fact, a software platform. Okay, then, suit yourselves. There are ways around it, not all of which are technical. |
|
Further to that, do note that the Live Update tab prints this misleading information: “The system is currently checking these plugins to see if they could cause problems during the upgrade.” Joomla does no such thing. It does NOT check anything. It only lists all system, user and actionlog plugins already enabled on the site which are not marked as protected. Therefore the list of plugins printed is misleading, the message is misleading and the intent of that page is to harm the reputation of third party developers. If you do not want to follow a technical solution, the wording on that page would have to be FAR more nuanced. As it is right now, even a rookie lawyer straight out of law school could win a defamation lawsuit against OpenSourceMatters Inc. |
|
Totally agree with @nikosdion |
As far as I can tell this isn't true. I just installed Akeeba backup and enabled the backup on update plugin and viewed it - none of the plugins in the package render. Image below:
If I override to a local update server and force an update (e.g. pretend that J4 say is only compatible with a made up
I've also installed @zero-24 's standalone https://github.com/zero-24/plg_system_httpheader plugin here as a sample system plugin which is J4.0 compatible and ensured that it doesn't show in the list
So as far as I can tell this is all working as intended without duplications or extra warnings. More than happy to be shown if i've missed the obvious (quite possible I have :) ) but this was the process I went through when we tweaked the string then closed the issue |
|
See also #34468. What is going on here? I was able to update from J! 3.10 alph8 to alpha9—big deal, took me 5 minutes—but so what? The update pre-checker indicated there was a "serious potential problem with Akeeba Backup" and I had to click the yeah-I-accept-the-risks checkbox and, yes, the site was backed-up before the update sailed through (as per normal) but what else has changed? I agree with @nikosdion that the current situation sends worrying signals to developers and end users alike and the anxiety they cause mean that people—uncertain about what these signals mean—will generate more of the same questions. Even though the questions themselves can be answered with the same answers, the fact that the pre-update checker does these things to web developers/site owners is not helping matters. Further, the ongoing anxiety dissuades people from testing J! 3.10—not that there's more than a dozen people in the whole world who may be testing alpha versions of anything, by the way—as well as putting people off migrating from J! 3.x to J! 4. So I don't understand why the "release blocker" status has been removed. While there may not be a technical reason that prevents updating to J! 3.10 (to later versions of it or as a basis for updating to J! 4) when people see a "potential upgrade problem" signal they'll stop, ask the question—and wait for an answer (maybe)—and reconsider their future business dealings with Joomla. Alternatively, they may think, "This is just a false positive" (until they encounter a situation where the signal is genuine) and this creates further uncertainty. I don't know how many third-party extensions generate these error messages. I'm using a vanilla-flavoured J! 3.10 alpha site with one extension installed. I don't have the time or inclination to load the site with lots of third-party extensions just to see which one(s) generate pre-update notices. We're in alpha; there are a dozen people who test alpha things; we don't have the user base to look into the thousands of possible combinations of matters that developers and end users may encounter day-to-day. Some extensions will generate these warnings and some extensions won't. That's all we can say. The fact that the number one extension used in the world today generates these warnings is, however, problematic. Is this the responsibility for the developer to fix (and, if so, how?) or is this the responsibility of the Joomla project to remediate ("just ignore the warning and she'll be right, mate")? |
Have you moved the update server from 3.10 to 4? The akeeba packackage does not claim to be 3.10 compatible. Thats the reason the message is showd. |
|
Huh? I don't understand. Have I moved the what to the what? I'm testing J! 3.10; that's all I'm doing at the moment. I don't want to update the site to J! 4. I'm testing J! 3.10. ❓ |
|
Tested clean install of 3.10 with akeeba backup and admintools pro versions.
Then I went to the plugins and enabled the System - Backup on update plugin for akeeba backup
Then I went to the plugins and enabled the Action Log - Admin Tools Log User Actions plugin from admintools
|
Yes than the seccond part is true. Basing on the update server that akeeba provides is that it does not support 3.10 but only 3.9 and 4.0
|
|
what does any of that have to do with the pre-update check for joomla 4 |
Hmm that seems to be a bug will take a look.
it was in reply to @sozzled not you. |
|
@zero-24 : I think you're saying that @nikosdion has to repair Akeeba Backup (to make it compatible with J! 3.10), yes? Likewise, all other J! 3.x (and J! 4) extension developers have to do likewise (for J! 3.10 and J! 4). Is that the solution? |
|
There are TWO different issues here
|
|
Ok the problem is here: https://github.com/joomla/joomla-cms/blob/3.10-dev/media/com_joomlaupdate/js/default.js#L308-L312 In case its a package it first has to check whether the package_id is marked as compatible or not right now the upgrade information of the package is not checked and therefor showing a warning where there should not be any shown. |
|
I agree, Brian, but it goes further. I think we all agree that the main objective of the J! project is to move people towards J! 4 eventually. J! 3.10 is a waypoint on the pathway towards that objective. At some future point, there will be four classes of people: (a) website owners and extension developers who will remain on outdated, "non maintained"versions of J! (i.e. anything less than J! 3.10) For the sake of this discussion, J! 3.10 needs to inspire some degree of confidence that it will last—EOS notwithstanding—and that outdated and no-longer-maintained releases (i.e. anything less than J! 3.10) are no longer suitable. It will take time for people to understand that versions before J! 3.10 are "unsuitable" and that there won't be any help for them if they continue to use whatever version they currently have. Such people will do what they do. Like all forward-thinking people, I will make my plans accordingly. My purpose at present is to assist the project: to help the tens of thousands of people who have invested their time, continue to invest their time and will invest their time in future. J! 3.10 (as I have written earlier) is a point along the path in that direction. J! 3.10 is not the end-point but it needs to be a point at which people arrive and know what they may need to do next. I don't understand why this discussion is marked "closed". The discussion continues. |
|
If an XML manifest file for an extension is claimed as compatible with 3.9 and 4.0 it's obvious that the extension is also compatible with 3.10. Anyway 3.10 is still not out so we could not even pretend that all extensions developers mark a manifest as compatible with 3.10 |
@brianteeman Found the problem. The issue was that the code did not handle when there is more than one "critial extension" within one package, please test this PR: #34776 |
"Computer logic" is not as flexible as human logic. "Computer logic" is black-and-white: something is or something isn't. We (human beings) can infer things based on our experience. Sure, if something worked yesterday, and we've checked that it will work "tomorrow", we can infer that it should work today (even if something flags otherwise). If we extend the testing base, move from alpha to beta (or even RC), then we improve the prospects of establishing a higher degree of confidence in the project. As things remain at present, with a dozen or so people willing to test alpha software, we're stuck in a catch-22. |
|
Apparently the Joomla core maintainers who are (or at least should be) intimately familiar with the Joomla Update code are far less capable than a third party developer who hasn't taken a sideways glance at that code in identifying the problem. As I said before, the Live Update tab lists the extensions' plugins regardless of whether the extension is up-to-date and marked compatible with a specific Joomla version. To make it abundantly clear, as I said before I am testing with Joomla 4. My production update site DOES support Joomla 4. This is also beyond the point for two reasons. First, I am using a local update server when testing with an upcoming Joomla version since my production update server can include neither the upcoming version number (for obvious reasons) nor can it claim to support a Joomla version I have not finished testing with. The second reason is that Joomla doesn't give a rat's ass about whether an extension is up to date or compatible with the Joomla version to be installed. It took me two minutes to find out why. In tmpl/preupdatecheck.php line 238 you can see that it only checks if $this->nonCoreExtensions is non-empty. The HtmlView populates this by calling the UpdateModel's getNonCorePlugins() which lists ALL 'system','user','authentication','actionlog','twofactorauth' plugins which do not match the ID of ExtensionHelper::getCoreExtensionIds(). If you want to reproduce this issue install Akeeba Backup CORE on Joomla 4 AND enable the ActionLog plugin that comes with it. Alternatively, just install Admin Tools Core on Joomla 4; its system plugin is automatically enabled. THIS IS NOT THE CASE OF THE DEVELOPER BEING STUPID. IT'S A SIMPLE CASE OF JOOMLA DOING SOMETHING WRONG AND COMPLETELY AGAINST WHAT IT CLAIMS TO BE DOING. Let's say you install Admin Tools Core on Joomla 4, to make things easier. Sure, in the Pre-update Check tab Admin Tools Core appears under “No Update Required”... and still shows the spooky message RIGHT NEXT TO ITS NAME. The More information opens a popup which reads the following:
It affirms that the plugin belongs to an extension which is either outdated or not compatible with the Joomla version we are about to install. However, Joomla has already downloaded and parsed the update stream and confirmed that the extension IS up to date and IS compatible with the Joomla version we are about to install, hence it lists it under No Update Required! So, this message is completely wrong. It should have NOT been displayed next to an extension under the No Update Required header in the Pre-update Check tab. In any case, and as I reported 21 days ago, when I go to the Live Update tab per the instructions of this message, I see the following false, misleading and defamatory information:
Right below that is a table which lists the plugin “System - Admin Tools”. It gives people my name and my company's URL. Anyone reaching that page comes to the conclusion that I don't know what I'm doing, I can't be arsed to support this new Joomla version and that Joomla has somehow checked my plugin and confirmed it will break their site on update. THIS IS DEFAMATION. It is also completely and utterly wrong since Joomla has already CHECKED that the plugin's package reports itself as compatible. The instructions given are beyond just plain wrong, they are outright HARMFUL. It tells you that you have one of three options:
But, please, do go ahead and tell me how I am wrong for not adding official support in my update XML for a version of the CMS I am not supporting anymore... |
Joomla would not show any updates so why should we show them to be compatible by "guessing" something?
Agree the same applies to joomla 4 ;) Right now its not an issue with an live version cause 3.10 and 4 are not stable yet.
Yes as mentiond by brian we are discussing two issues here your issue should be patched here: #34776 atleast that works on my side. |
No, it's not just there. This is just the first part of the problem. The second part is the Live Update tab which is generated server-side by the view template. That feature needs to be completely rewritten.
Are you for real, my good man? There's a MASSIVE difference! Joomla 4 is the next major version targeting new site developments, a completely new architecture and currently RC. Joomla 3.10 is the upcoming graveyard version targeting holdouts, the same old architecture and still Alpha. Nobody gives a crap if Akeeba Backup or JCE or whatever works on Joomla 3.10 Alpha. Everyone and their dog wants to test Joomla 4 and start getting familiar with it, even since it was just a beta, because that's where the future business income lies! If I spent my time supporting the perpetually alpha 3.10 instead of putting my time into supporting Joomla 4 I would lose my clients and I'd be out of business. In other shocking news water is wet and Pope's a Catholic. |
Right it is a few lines above. I have send a PR with the changes that fixes the issue described: #34776
I get your point I only try to explain where the issue (the seccond issue that @sozzled reported not your report!) is comming from. I'm not blaming you to be focused on Joomla 4 cause thats the main focus of us all. |
I agree (especially with the observation about how J! 3.10 is perpetually in alpha) which is why I referred to the discussion about shifting it out of alpha. I don't think I completely understand what was the second issue I raised in this discussion. I have made a number of points here: (a) the information about "potential update problem" warnings sends unclear signals to website owners and extension developers; I would guess, if J! 3.10 was stable, Nick and other developers of mainstream J! extensions would be adapting their business model to cater to J! 3.10 to some extent, wouldn't they? But, as Nick succinctly puts it, J! 3.10 is alpha—mostly unknown and ignored by ordinary folk—and it's not something that they should invest their any of their valuable time messing around with. |
|
@sozzled repeating the same thing over and over again in multiple places doesnt change anything. Everyone knows what you think. whether you write 20 words or 20,000 words explaining it we still know. |
|
I know that some people know what everyone else thinks, but I don't know if everyone knows what I think. 😏 |
Well seems we disagree here. It shows a clear message to everyone to double check the extensions marked with that label. Nic is right with the issue he reported and thats going to be adressed in the PR #34776 feel free to help testing it :)
Yes as a PR to adress the issue has been posted.
Yes as there is a PR that adresses this issue.
Correct thats the intention of this release. Have a common ground for upgrades to 4.x and a stable package with two years of support.
I have tried to explain a few times already why 3.10 is still in alpha. When I move it to beta or RC and than add a "new feature" like the planed EOS plugin others will stand up and say "its not how versioning" works. But now that I try to follow the rules I get complains form the other side like "why it is not stable yet", its hard to make everyone happy :)
Yes it is and always was. 3.10 is an 1:1 copy of 3.9 only with minimal changes like the pre upgrade checker. The main development focus is on 4.0. |
|
I want to comment that Joomla 4.0 RC4 has the same Joomla Update as 3.10 which is different than Joomla 4.0 RC3. The Live Update tab has been removed which is a positive step as this is what was causing the most problem for extension developers and users. However, a series of newm smaller bugs was introduced: the More information tooltip is no longer a tooltip. You see the cursor change but you get no tooltip and clicking it does nothing. The misleading information still appears but this is already being worked on so I won't comment on that. I also see that the icon from More information disappeared, presumably intentionally. What is really weird, however, is that we now have a tab bar on the side where everywhere else in Joomla we have a tab bar on top. But, most importantly, there is button to perform the update! All I get is “Update your site by manually uploading the update package.” at the bottom, which looks like a link and I missed the first three times I looked at that page. Granted, the problem was that the database structure was up-to-date but there was nothing on that page telling me that a. this prevents me from seeing an update button and b. how to fix it. This might prevent people from updating their sites which beats the purpose of the Joomla Update component! IMHO, the database structure should not completely prevent the update. Many times I have had to install an update exactly because Joomla wouldn't figure out that its database is, indeed, up to date. At worst you should have a checkbox. I also don't agree on making the update button disappear completely. It violates the Principle Of Least Astonishment. The user is left thinking that Joomla is broken. Show it disabled and with a message underneath explaining WHY it's disabled. Don't expect people to read a Joomla documentation wiki page written in bad English on their volition. People don't have time for this. If they had time for this our labels would be ITEM PER ARTICLE 5, PARAGRAPH 1 or something just as inscrutable. You think that's preposterous? Tell that to Citibank; they do that and it cost them just over $900m when someone did not, in fact, read the fine manual... Fixing the database structure I also get the “I accept the warnings about potentially incompatible extensions and wish to proceed with the update.” but this is presumably being addressed by the PR so I am going to ignore it. |
|
Thats from the recent pr from @bembelimen which (imho) was merged a bit early |
|
Would be great to get your test on the mentiond PR so we can merge it for 3.10 and push it up to 4.0 so the issue reported here are beening fixed. Thanks. |
|
I think Joomla is in dire need of a UX person. What I am seeing is confusing to me who's not only been using Joomla since it was called Mambo, not only knows how it works under the hood inside and out but also is the person who has written the original implementation of Joomla Update. If I had to look three times to figure out WTF is going on what is the average, non-technical Joomla user going to understand? @zero-24 Once I am back on a computer with time on my hands I will. I am replying from an iPad sitting with a toddler as we were left without childcare this week on zero notice. I also need to cook today and take the cat to the vet. It's a bit hectic, you might say... |
Awesome thanks. |
Confirmed in J! 3.10 alpha9 Joomla! Update. |
I can not confirm that on 3.10-alpha9 it is looking like this to me (thats without the PR that fixes the issue mentiond above), From my understanding Nic was talking about Joomla 4 I havent checked that yet: |
|
This is not exactly a tooltip (in the sense that the modal appears onHover); I stand corrected: the modal now appears onClick. I cannot confirm anything with J! 4 because I would have to use a "nightly build" and I refuse to use "nightly builds". I cannot reproduce the same screen display for J! 4 (as for J! 3.10) because the option to do this doesn't exist. I can "reload core files" but, when I choose that option, it just goes ahead and reloads the core files without the intervening stage of asking "are you sure?" |
|
This is what I see in Joomla 4.0-RC4
Note that More Information does not have an icon, does not appear as a badge, does not have a tooltip and does nothing when clicked. For Joomla 3.10 I would say that using the Danger colour for the more information label is wrong; it needs to be the Info colour or the Dark colour. Otherwise we communicate to the user that this is a hard error when it's not. Moreover, the tooltip is now wrong since there is no Live Update tab. IMHO the Joomla Update should be reverted to how it works in 3.9 and have an out-of-band update for it sometime in the 3.10/4.0 release cycle AFTER restarting developing it with a clear roadmap and user experience in mind. What we have now is a rolling Dumpster fire. Sorry, but I can't describe it in more charitable terms. The whole point of the Joomla Update component was to make core updates easier to manage by non-technical users. What you have now is a convoluted hot mess that manages to confuse even seasoned developers. PLEASE reconsider this. People WILL contrast this with how stupidly easy WordPress updates are and leave Joomla. We don't want to be extremely technical, we need to be catering for the non-technical users. |
What colour would you suggest for 3.10 than as info colour? Blue? |
|
There's a literal
|
|
Ok thanks will take a look and do a PR for the class change. |
|
PR has been updated with the "info" class: #34776 |
|
... so much for this discussion being "closed", hmmm? 😏 |
Steps to reproduce the issue
Expected result
Everything listed in the “No Update Required” section shows as having no problem whatsoever. These are the extension versions confirmed to be compatible with the version of Joomla I am about to install. These green items are good to go, the extension developers did their due diligence and I am a star for having updated them already. Hooray!
The other extensions show me a message about them having plugins which might be incompatible and cause my site to stop functioning after executing a Joomla update. Okay, I guess. These are old extensions which haven't received an update for a while. I'll miss them but I'll live. Let me disable or uninstall them before I start updating Joomla.
This is really neat! Joomla 4 is already supported by so many third party extensions. This thing will freaking ROCK! Woo-hoo!
Actual result
All extensions which contain a system plugin show with a very scary and confusing ‘Potentially Serious Problem. More Information.’ message. This tells me all these extensions do have a problem that Joomla detected and it might be a serious one. My, oh, my.
When I click on more information my worst fears are confirmed:
I understand that all extensions, even those which are supposedly "up to date", are incompatible with Joomla 4 and I'd need to remove them or disable them. But... if I do that, I am left without any extensions! How is my site even supposed to work?! It looks like this newfangled Joomla 4 thing is unsupported by most Joomla developers. Joomla must be dead; components which have been around for more than a decade seem to not support it. Yet, Joomla 3 is an ancient piece of crap. I guess I'll stick with Joomla 3 for a while before moving my site to WordPress. Clearly, Joomla 4 is dead as a dodo. This pre-installation check confirms it. I guess the writing was on the wall...
System information (as much as possible)
Completely irrelevant.
Additional comments
The current message reads “Potentially serious problem”. There are two adverbs and a noun which creates a lot of ambiguity as to the meaning of the message. Does the adverb “potentially” apply to the adverb “serious” or the noun “problem”? I have asked native English speakers and their first guess was that it applies to the noun. Therefore the message ends up reading as “this extension most definitely has a problem and it can be a mighty serious one, ALERT ALERT ALERT, AWUUUGAAAA”.
Of course this confuses the user who will now be untrusting towards our software. When us 3PDs explain the lack of a problem to users they will lose trust in Joomla itself and start blindly ignoring its warnings. Therefore this message is not just a waste of time but it also conditions users into ignoring messages about real issues which has a net negative impact to their experience using Joomla.
Further to that, the recommended course of action of disabling all these plugins is detrimental to the site's operation and WILL cause the site to fail. System plugins implement very important functionality on the site, from security to integration with payment providers and everything in between. Disabling them will break the frontend and could even have detrimental consequences e.g. e-commerce sites left unable to process orders. Considering that the list of plugins with “potentially serious problems“ is never to be shown again once you disable the plugins and/or update Joomla, the user is caught off-guard and left with a broken site. In other words, if you follow Joomla's advice your site is broken and you're left in the lurch, trying to figure it out all by yourself. Ouch!!! A bad experiences like this is what drives people away from Joomla.
I do understand why this message exists and I have read on its history. I agree on the concept but I disagree on the misleading implementation.
For the extensions in the “No update required” category the message should be a much less scary, informative one e.g. “Extension containing plugins” with an info icon instead of an exclamation icon and with a further information tooltip content similar to “This extension includes plugins which load on all pages. The extension is reported as compatible with the version of Joomla you are about to install and should not cause any problems. In the unlikely event it's not, these plugins may prevent your site from loading at all. You are advised to take a backup copy of your site before proceeding with the Joomla update.”.
Moreover, the plugins from these extensions should either NOT be shown in the Live Update tab or shown separately (e.g. under a “Always loading plugins”, explained to be plugins from extensions which claim to be compatible with the new Joomla version to be installed) and their existence NOT block the Joomla core update.
As for all of the other extensions, the language strings need to change to be far less ambiguous and their information needs to be clear and actionable.
The short message should read ‘Potential error’. Instead of the inherent ambiguity of using two adverbs we now have a single adverb and a single noun. The noun “error” in the context of computer programs denotes a very serious problem which will cause a, let's say, unplanned termination of the program.
Further to that, this should be what you can click for more information instead of a separate “Further information” link. The “Further information” link seems to applied to the extension, not the message about a potential error.
Moreover, it's enough to show this ONCE per extension. Showing it as many times as there are plugins is an overkill and does not add to clarity. Quite the contrary.
Finally, the further information tooltip as it stands is an exercise in bureaucratese. It's unclear, it's not actionable, it instills uncertainty. Something more clear is in order, e.g. “This extension includes plugins which load on all pages. This extension can not be confirmed as compatible with the Joomla version you are about to install. If the extension is indeed incompatible these plugins may prevent your site from loading at all after updating Joomla. You can find a list of these plugins in the Live Update tab. You may need to disable these plugins before running the update. If you choose to do so please make sure to keep a copy of the list of plugins in the Live Update tab somewhere safe before disabling any plugin. Remember that this list will NOT be shown to you again after you update Joomla. You will need it if you decide to re-enable these plugins after updating Joomla and upgrading the respective extensions they belong to.”
It's clear and concise, with actionable items instead of letting the user guess. We all know what happens when the less experienced users are left to guess too much...
Why did I not report this before
As you remember, this feature was completely borked, up to and including 4.0 RC1. I reported that issue, I got it fixed and I finally got to the point where I could test the pre-update checks for real.
The text was updated successfully, but these errors were encountered: