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

[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?

[d19dotca]

@girish just wanted to follow-up on this. Any idea what could be causing this?

[girish]

@d19dotca It's in my todo list, have to investigate but so it's not obvious yet what the issue is.

[jdaviescoates]

@girish @d19dotca I wonder if the issue I'm having with configuring Wordfence Firewall is related....?

When I try to do it I end up getting asked for FTP credentials (which of course I can't supply as they don't exist for WordPress Managed app).

[d19dotca]

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

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

@girish it's for adding firewall rules to .htaccess

[MooCloud_Matt]

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

[d19dotca]

@girish Hi Girish, Any updates on this one? Did we ever find what causes the auto-updates to not work?

[girish]

@d19dotca This one has me totally stumped. It's crazy that there is no obvious way to test this. All the time it is "scheduled in 12 hours".

[d19dotca]

@girish Do we know if this works in Unmanaged? I haven't tried there, but if it works in Unmanaged... maybe that's one more reason to make Unmanaged the primary WordPress app package haha I'll maybe try in Unmanaged over the weekend if it hasn't already been tried.