WordPress 5.5 auto-updates not working in Managed version, likely due to core updates blocked.
-
@d19dotca
I called them crashes, but to be precise they are CSS errors, or WooCommerce for example or other plugins that are out of date with the current version of WordPress or other plugins and therefore create incompatibilities.
For example, those who activated this function and had Divi or Elementors, in the first hours the site did not load the images correctly because the two builders were not yet updated to support lazy load by WP.
For this reason it is recommended to use external tools that perform the updates, there are many even free ones, which perform a backup before the automatic update and once the update has been performed they compare the CSS and the HTML to check is identical, if not then they will proceed to reverse the backup. -
Matteo. R.
Founder and Tech-Support Manager.
MooCloud MSP
Swiss Managed Service Provider -
@d19dotca said in WordPress 5.5 auto-updates not working in Managed version, likely due to core updates blocked.:
Just a heads up to anyone on the Managed version who is hoping to take advantage of the built-in auto-updates for themes and plugins - it ain't working with he way the Managed app is configured.
@d19dotca What error did you see for this? Was this some cURL error?
I am debugging this bizzare error and was wondering if it's related to what you saw.
-
@girish That's an interesting one, I never saw that error in my quick test, but I wonder if that error only shows for a short period of time so maybe I missed it.
Mine just had a message about 2 hours from now it'll check again, and I knew there were updates to it as it showed it, but it didn't install them and when I checked 3 hours later since it was supposed to be done 2 hours later, it showed the next attempt was 11 hours from then (so basically it tries to check every 12 hours I guess), but no action was taken to install the update when it should have done it.
-
-
@girish Yeah that seems like a different issue, so that's a good conclusion on that one. I'm still interested in knowing why the auto-update isn't working, did you see it work for you then? I have a sneaky suspicion this has to do with the WordPress cron doing it every 12 hours but I think since it's disabled and we run our own in this app (correct me if I'm wrong but I think the cron was handled differently than default), this may explain the discrepancy.
-
@d19dotca How can I test the auto updates? Install an old version of plugin and enable auto update and wait for a day?
cron shouldn't be a problem. Essentially, php apps are loaded by the server only when someone makes a page request. Some PHP apps (like WP) have a built-in "cron" module which checks if some cron task is due and runs it, but it can do this only when someone requests a page. If you have a reasonable traffic site, it will work out. But if someone doesn't visit your site for 4 hours, those cron jobs are not going to be run. The alternate solution (WP supported) is to disable this built-in cron and instead just run it using crontab or something outside the PHP/Apache. This is what we do.
-
@girish yes that should work.
Admin columns pro use private repo, the new autoupdate feature will overload the repo-server, because it try to update all the server in that time zone at the same time.
That may be the cause of the timeout of curl request.But normally if u try to update it manually should work
-
@girish Good question. My test was I had a plugin that was out-of-date (it coincidentally was at the time of WordPress 5.5 update), and as soon as I noticed it I set it to be enabled for auto-updates, and it gives a message saying at that time it'd be done in 2 hours, but it didn't do it and the counter reset afterwards to 11 hours (would have been 12 if I checked on time though).
So to test I would think your proposal would work, uploading an out-of-date plugin, check for updates to verify it recognizes an update is available, then enable the auto-update on that particular plugin and see if it updates automatically by WordPress.
For the cron part, you are likely correct - I am not intimately familiar with that level since moving to Cloudron for the app package, but I assumed this may be an issue because I thought the app package is calling the cron every 1-5 minutes, but yet the WordPress item is saying every 12 hours, so it seemed like a discrepancy and thus a possible issue. Plus the "disable core updates" plugin is there too which I felt may also interfere from auto-checks.
-
@MooCloud_Matt said in WordPress 5.5 auto-updates not working in Managed version, likely due to core updates blocked.:
https://www.wordfence.com/blog/2020/08/wordpress-auto-updates-what-do-you-have-to-lose/
A good overview (as one would expect from Wordfence), thanks.
-
I was able to reproduce this. It looks like it triggers the cron event
wp_update_pluginsbut that even does nothing.root@01d9cbb3-049c-4b99-b5e6-299ea3775d75:/app/code# exec /usr/local/bin/gosu www-data:www-data /app/pkg/wp --skip-themes cron event run wp_update_plugins Executed the cron event 'wp_update_plugins' in 0.007s. Success: Executed a total of 1 cron event. -
-
-
-
@jdaviescoates Good question! That won't be the root cause for me though I'm pretty sure as I don't have WordFence installed (or any security-related plugins really yet).
-
-
@girish it's for adding firewall rules to .htaccess
