WordPress 5.5 auto-updates not working in Managed version, likely due to core updates blocked.
-
@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.
-
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.
-
@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.
-
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.
-
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).
-
@jdaviescoates Yeah, same as @d19dotca for my setup as well. I don't have WordFence. Why does wordfence want FTP permissions anyway? Is it patching some code?
-
@jdaviescoates
Normally this kind of plugin for security they want to have access to all the WordPress to intervene if needed on all the WordPress root directory.
This message is form wp. Because WordPress it's self provide an interface not edit files and accessing data, when a plugin try to access the filesystem with the filesystem API and the API fail, will automatically ask for the credential of ftp.
But .htaccess is editable I think on managed too, so it's trying to do something in a read only directory on the image. -
