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:

#!/bin/bash
*/5 * * * * www-data /usr/bin/curl -A 'Mozilla/5.0' 'http://127.0.0.1/wp-cron.php' >/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' 'http://127.0.0.1/wp-cron.php' >/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

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.

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?

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.