User tests: Successful: Unsuccessful:
This PR adds a new plugin event that allows 3rd party extensions to stop automatted updates. This allows 3rd party developers to i.e. enforce special conditions like "only perform auto updates if a backup using my backup extension has been performed in the last 24h".
Side note: A new "after update" event is not required, as the default after update event will be called.
Please select:
Documentation link for docs.joomla.org:
No documentation changes for docs.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_joomlaupdate Language & Strings Libraries |
Labels |
Added:
Language Change
PR-5.4-dev
|
But might it not be against the whole idea of automated updates when a plugin can stop it
Allowing users to disable automated updates is also aginst the whole idea ;)
At the end of the day, we can only offer the service as an option, it's up to the users to decide if and how they use it.
In my opinion the feature should be fully transparent.
User must be able to look the configuration and clearly say "is it enabled" or "is it disabled", nothing in between.
Because for example when I enable autoupdate, and it suddenly stop working because some extension decided to stop it, what should I do, how I find a reason? I will go to Joomla and complain "your stuff is broken".
It going to be a negative experience for end User.
User must be able to look the configuration and clearly say "is it enabled" or "is it disabled", nothing in between.
So, how would that work with the mentioned example of a backup extension enforcing a backup created within the last x hours? It's a pretty obvious usecase. Should that extension disable the respective parameter in the config of com_joomlaupdate?
I think some kind of lock file, method that is often used for avoiding such conflicts.
User also can check for they present in case of misbehavior.
Probably 2:
update.lock
for active update process, when it is present then the backup extension do not start;
backup.lock
for active backup process, when it is present then the update (and autoupdate) do not start;
But we would need a lockfile per extension to avoid locks of extension A being cleared by extension B, so that quickly becomes complex. It would also require extensions to do periodic checks if the update conditions are still met to write that lockfile upfront, leading to potential race-condition-like situations where an update could be installed now, but the extension has not cleared the lock yet.
I'm not necessarily against it, just trying to weight effort (for initial implementation and maintenance) against the extra benefit.
But we would need a lockfile per extension to avoid locks of extension A being cleared by extension B, so that quickly becomes complex.
Hm, why? we just need one, for common agreement the backup extension will use the one. it could hold timestamp, and extension name when needed, but could work just empty.
upd: I mean, internally each backup extension could use anything, own lock file etc. But for Joomla they have to provide the lock file that we agree.
hm, but if the following message is logged somewhere
Then use the event is probably fine
hm, but if the following message is logged somewhere
You mean logfile-like logging? Or something that's UI-accessible?
You mean logfile-like logging? Or something that's UI-accessible?
Log file.
Could also be something in our Actionlog. Similar as we have for update.
I have one: currently: 5.4.0-alpha3-dev
I did the following:
Update Server: Standard
Autoupdatepreventer Zip installed & activated.
Automated Updates: activated.
I also received an update token after saving the second time.
Patch activated (= OK?)
I don't know (yet) whether my steps were/are OK or whether they were successful.
(I just didn't understand the last few posts).
Update Server: Standard
@ChristineWk Did you install Alpha Update Server
plugin from 45540? If you install it, then you are using the Alpha Joomla Update Server:
After installation of the plugin, you can try Joomla check for (manual) update and version 5.4.110 will be offered. Do not install manually! Enable automated updates and within 24 hours the update should be done and you will receive an email like I did last night. Good luck
@muhme Thank you for your information!
I installed Alpha Update Server and it was automatically activated. It was not visible in Update Source.
After (re)enabling Automated Updates:
Error while registering to automated update service: cURL error 28: Failed to connect to my site port 443 after 5001 ms: Timeout was reached (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://my site /api/index.php/v1/joomlaupdate/healthcheck (500).
I tried again and now it appears hurray:
@ChristineWk I assume it's a publicly available site, not a local instance, correct?
@ChristineWk I assume it's a publicly available site, not a local instance, correct?
Yes (sorry) it's a public test-site.
It was not visible in Update Source.
It is visible if you go to System > Plugins > System - Alpha Update Server
Should I do Start update?
No, this is the manual Joomla update. You have to wait 24 hours for automated update happens.
Once the Automated Update was successul, then you have verified Automated Update is working without this PR. Next step is to install again fresh, this time from full package build (see All checks passed > Download > Joomla_5.4.0-alpha3-dev+pr.45696-Development-Full_Package.zip or having standard 5.4-dev installation and install Patch Tester and Apply Patch 45696. Then you install and enable the demo plugin plg_autoupdatepreventer.zip. No automatic update should take place within the next 24 hours. You can also test that with this PR and without plg_autoupdatepreventer the Automated Update is still working.
@ChristineWk your webhost is blocking incoming connections from the update server
@muhme
Thank you again for your informations! David is so kind to take a look.
Thank you: @SniperSister
David: Aha, yes, how can I prevent this? :-)
So, current status:
Version 5.4.110 is available. I'm not updating!
Automated updates are enabled.
Thanks for your help!
I had trbls with host.
The 24 hours should be over.
No automatic update has taken place.
The update to 5.4.110 is still being offered (currently).
@ChristineWk as far as I can see, the site has just been updated to 5.4.100 - can you please double check?
@ChristineWk as far as I can see, the site has just been updated to 5.4.100 - can you please double check?
Done!
You're right. Now I see:
Phew... now there's part 2 open, oh, oh. "Next step" from Muhme ...
Thanks for your help
Tried to install:
Download > Joomla_5.4.0-alpha3-dev+pr.45696-Development-Full_Package.zip
No success at the moment (after attempting to update the package in backend)
BTW. demo plugin plg_autoupdatepreventer.zip. It's been installed and activated since yesterday.
I clearly see the use case for this. But might it not be against the whole idea of automated updates when a plugin can stop it. I see this problematic when a high security release is shipped and a plugin blocks the update. Leaves a site vulnerable for an amount of time. Not saying this is a bad idea, but needs probably also some way to ignore it in emergency cases.