WordPress 5.5 auto-updates not working in Managed version, likely due to core updates blocked.

[d19dotca]

@jdaviescoates oh that’s interesting, I somehow totally missed that message when I was updating. Hopefully this is just an issue with the pre-release version then.

[d19dotca]

@jdaviescoates interestingly the forum post with the release notes doesn’t mention it as beta either. https://forum.cloudron.io/topic/2407/wordpress-managed-package-updates

[MooCloud_Matt]

@d19dotca
btw dont use the auto-update, it dosent provide any check on the update, we are faing many WordPress crash because customer activate this new feature.

[jdaviescoates]

@d19dotca said in WordPress 5.5 auto-updates not working in Managed version, likely due to core updates blocked.:

@jdaviescoates interestingly the forum post with the release notes doesn’t mention it as beta either. https://forum.cloudron.io/topic/2407/wordpress-managed-package-updates

I also note that after hitting Check for Updates, the fact that there is now an update then triggers an email about the update, and the email doesn't contain the warning about it being unstable either:

[d19dotca]

@MooCloud_Matt Just to clarify, you’re talking about the auto-update within WordPress itself, the new functionality right? Interesting that you’ve seen some crashes and stuff already.

I went through and updated about 12 WordPress sites yesterday afternoon and did some brief testing of them all, one-by-one since it was a major WordPress update. Thankfully there were no public-facing issues, aside from one where I had to regenerate the CSS files. Everything went smoother than I expected, honestly.

The only real issue I’ve experienced is the one I’m reporting here, but to be fair I only tried enabling the auto-update for plugins and themes on two of twelve sites. No crashes or anything though observed, just that the auto-update isn’t doing anything.

[girish]

Yeah, we haven't heard any WP 5.5 related issues either. What crash are we talking about? The package itself gets rolled out slowly since we have a very large amount of WP installs.

The auto-update of plugins should ideally work, let me check why it doesn't.

[MooCloud_Matt]

@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.

[MooCloud_Matt]

@girish
I'm speaking of the new auto-update feature of WP, that is similar to use an auto-update script for packages on a rolling realize linux distro, is not a good idea in production.

[MooCloud_Matt]

https://www.wordfence.com/blog/2020/08/wordpress-auto-updates-what-do-you-have-to-lose/

[girish]

@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.

[d19dotca]

@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]

Actually, this seems like some plugin related issue. Because on the same instance I could update other plugins. I have asked our customer to contact the plugin author, I will update once he gets back.

[d19dotca]

@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.

[girish]

@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.

[MooCloud_Matt]

@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

[d19dotca]

@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.

[jdaviescoates]

@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.

[girish]

OK, I waiting for Hello Dolly to auto-update in 12 hours to see what the error is. I couldn't figure an obvious way to trigger auto-updates immediately.

[girish]

I was able to reproduce this. It looks like it triggers the cron event wp_update_plugins but 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.

[d19dotca]

@girish Is this a WordPress issue then in that case or to do with the way this is packaged in Cloudron?