Murphy's picture

Hello all,

I have a question about the automatic update on wordpress.
I have noticed that a plugin or a wordpress update does not update despite activating the automatic update.

What can I do ?

Jeremy Davis's picture

Hi Murphy, I'm no WordPress expert and TBH I am a bit unfamiliar with the automated WordPress updates. So my first step was to launch a new WordPress instance and see how it works...

FWIW, when we first enabled automated WordPress updates, we specifically decided to only enable minor version updates, as at that point there was a fair bit of concern that major version releases might break things. Ultimately that's still the case, but it appears now that a default install of WordPress will enable all auto WordPress Core updates. Considering that WordPress recommend that, we should perhaps reconsider our position.

Regardless, when I first launched a local WP appliance, it auto updated itself to 6.1.1, but wouldn't update to v6.2, nor update any of the themes or plugins. That is expected behavior as per our default settings.

By my understanding (and reading) changing the value of WP_AUTO_UPDATE_CORE (in wp-config.php) to true (by default we set it to 'minor' - which only installs minor updates) should enable all WP updates. Note that the 'minor' needs to be quoted, but the 'true' needs to not be quoted! From what I can gather, other components (e.g. plugins and themes) will also be updated, but only as explicitly decided by the WP security team. So assuming that it worked as documented, it still wasn't going to run all updates for all plugins and themes as I assume you desire.

Before I did any testing, I had a go at creating a "automatic-updates.php" plugin, that used filters to ensure that all components would be updated.

Unfortunately, nothing I tried appeared to work?! I reconfigured the cron job to run every minute, but that made no difference. I have no idea why it wasn't working as I expected, but there were no errors (I enabled debug mode to be sure). Perhaps I was too impatient and it only does updates once per day or something? Regardless, I could not get it to update WP Core to v6.2 - let alone updating plugins and themes.

Anyway, seeing as we pre-install wp-cli (and include a convenience wrapper script - turnkey-wp - to run it in the wordpress dir as the webserver user) and that supports running updates, I decided to take an alternate path.

So to enable auto updates for all WP components (i.e. Core, all plugins and all themes), I first created a script (which I called turnkey-wp-update) to do all the updates:

cat > /usr/local/bin/turnkey-wp-update <<EOF

# To disable a particular type of update, comment the line out (prefix line with '#').
# To only update specific plugins/themes, in the relevant lines below replace '--all'
# with a list of space separated plugin/theme names.
/usr/local/bin/turnkey-wp core update
/usr/local/bin/turnkey-wp plugin update --all
/usr/local/bin/turnkey-wp theme update --all
chmod +x /usr/local/bin/turnkey-wp-update
Then I added a new line to the existing wordpres cron job that we provide (/etc/cron.d/wordpress-cron) to also run the updates daily (FWIW I actually configured it to run every minute for testing; but this is what I would recommend) - this will run them every day at 00:02 (i.e. just after midnight as per the system clock):
echo "02 00 * * * root /usr/local/bin/turnkey-wp-updates >/dev/null 2>&1" >> /etc/cron.d/wordpress-cron

You can check the system time (UTC by default) using the 'date' command. You can then update the cron line I note above to run the updates at the time that best suits you. In case it's not obvious, use 24 hour time notation and the time the cron job will run is the first 2 components of the cron line (minute then hour). I.e. in my example above, minute first (02 in my case), then the hour (00) - 00:02 (12:02am - just after midnight).

This appeared to work really well. Hopefully that is of value to you and works as well for you as it did for me.

Murphy's picture

Hello Jeremy,

first of all, thank you very much for the comprehensive answer.

I always wonder why updates should not be applied if I have activated them at all in wordpress itself, or as an external plugin. The risk of an attack is much greater without an update. Also, not everyone checks everything for updates every day.

I have installed your configuration on a test server and will wait and see what happens.

I'll get back to you on the results - just wanted to give you a quick report.

Greetings Murphy

Murphy's picture

Hello Jeremy,

after waiting and checking for more than 1 day now.
Yoast SEO says: "Automatic update overdue for 1 day. There may be an issue with WP-Cron."

Translations that are displayed are also not updating.

Greetings Murphy

Jeremy Davis's picture

Hi Murphy, that doesn't sound ideal!

The command I gave should have added a new line to the existing cron job, so AFAIK it shouldn't have changed the functioning of the previous one. However, the difference between updating an existing file and overwriting it is the difference between '>' & '>>' (the former will overwrite, the latter will append).

So the first thing is to check what your existing cron job says. E.g.:

cat /etc/cron.d/wordpress-cron

FYI, the default cron job looks like this:

*/5 * * * * www-data /usr/bin/curl -A 'Mozilla/5.0' '' >/dev/null 2>&1

(See the original file in the build code here - note that the bash shebang is not actually needed).

The line I suggested above:

echo "02 00 * * * root /usr/local/bin/turnkey-wp-updates >/dev/null 2>&1" >> /etc/cron.d/wordpress-cron

Should have made the complete file look like this:

*/5 * * * * www-data /usr/bin/curl -A 'Mozilla/5.0' '' >/dev/null 2>&1
02 00 * * * root /usr/local/bin/turnkey-wp-updates >/dev/null 2>&1

If yours looks like that and the problem persists, then I suggest splitting it into 2 files (AFAIK it should work; but perhaps the mixing of jobs for root and www-data in the same file causes issues?

If so, perhaps try having them in 2 separate files? Note that the file does not need to be executable. Also, if you want to capture what it's doing, remove the '>/dev/null' from the line(s) and it should send you emails each time it runs (if you have system emails configured). Emails can be read locally via the relevant user. E.g. to read root's emails (if there are any):

cat /var/mail/root
Jeremy Davis's picture

Re your comment on translations not being updated, it appears that that requires more commands...

So add on the the existing /usr/local/bin/turnkey-wp-update script (that we made before). The new lines are:

/usr/local/bin/turnkey-wp  language core update
/usr/local/bin/turnkey-wp  language plugin --all update
/usr/local/bin/turnkey-wp  language theme --all update

Please let me know if that works/helps.

Murphy's picture

Everything is done like this and I'll wait and see.
Tomorrow I'll see what comes out.

But one question:
Why shouldn't updates be installed automatically?
As a normal stupid user I think that the plugin I use is good - otherwise I wouldn't install it ?
If I now also do without updates that might promote an attack - who wants to assess that?
Honestly - most people do updates and "hope" for the best !

Jeremy Davis's picture

Updates can break things and often introduce new bugs (including security bugs), so we generally think that it's better for users to decide themselves how/when updates get done. If WordPress and plugins differentiated between security updates and other updates, then we'd be much more inclined to enable auto (security) updates by default.

The risk of breaking something vs the risk of known open security holes is a very different equation IMO. But as there is no fundamental difference (between security and non-security updates - from WordPress perspective), we don't want to risk breaking someone's site and/or introducing new bugs by enabling auto updates. If you would rather auto install all updates, then that's fine, but we don't think that's our decision to make for you. I can almost guarantee that if we enabled all auto updates, then we will get users complaining about their WordPress being fine one day, then broken the next and they don't know why...

You are right in your statement 'most people do updates and "hope" for the best", but if a user does that themselves without a current backup and it breaks their site, that's on them. If the system we provide does that to them, then that's a completely different thing IMO.

Having said that, I think it would be better if we provided something a little more extensive (along the lines of what I've shared with you in this thread) with the appliance. We still probably won't enable them by default, but making it easier for users to do what they want with their server is certainly something that we'd like to support.

In future, we could look at asking if users want to enable auto updates on firstboot?

Murphy's picture

Hello Jeremy,

Good news and bad news.
my two updates: YoastSEO and translations.

i did it this way and everything was updated.

i tried again with the backup.
now it doesn't want anything.

now when i ask myself what is different - no idea.
maybe it's also because of the remote site ?
what if the updates require some waiting time at that point and it doesn't do that and aborts directly ?
is it not possible to log separately whether it wants to update and what happens with the remote station ?

Greetings Murphy

Jeremy Davis's picture

I'm sorry, but I'm not completely clear what you mean. If I understand correctly, you tried on your main site and the 2 updates worked. But then you tried on a backup site and it didn't? Is that correct?

One thing you could do to check what is going on is to run the update script directly (rather than waiting for cron) to get an idea of what output it is giving.

If you'd like to log what it does, you could change the cron job line from this:

02 00 * * * root /usr/local/bin/turnkey-wp-updates >/dev/null 2>&1

To this:

02 00 * * * root /usr/local/bin/turnkey-wp-updates >>/var/log/wordpress-updates 2>&1

That will write the output to a file named /var/log/wordpress-updates. Please note that unless you also configure log rotation, that file will grow forever, so I recommend not leaving it like that for an extended period of time - just for troubleshooting.

Add new comment