Hello, glad to know you were able to roll back to a working state. If you have a staging site, then you could try an upgrade to 6.3 and see if the issue stemmed from the update not being able to complete or if it’s due to some other factor.
There was a similar issue (admin not accessible after WP 6.3 update) that involved the W3TC plugin, so just in case I put here the link to that thread –
Some further errors at the time of the automatic update:
PHP Warning: copy(/var/www/html/wp-config-sample.php): Failed to open stream: Permission denied in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 309
PHP Warning: chmod(): No such file or directory in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 173
PHP Warning: chmod(): No such file or directory in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 173
PHP Warning: copy(/var/www/html/wp-config-sample.php): Failed to open stream: Permission denied in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 309
PHP Warning: chmod(): No such file or directory in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 173
PHP Warning: copy(/var/www/html/wp-config-sample.php): Failed to open stream: Permission denied in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 309
PHP Warning: chmod(): No such file or directory in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 173
PHP Warning: chmod(): No such file or directory in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 173
PHP Warning: copy(/var/www/html/wp-config-sample.php): Failed to open stream: Permission denied in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 309
PHP Warning: chmod(): No such file or directory in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 173
So it looks like something failed during the automatic update (because I don’t have the sample config file??)
When the automatic update failed, it appears to have left the “require class-wp-metadata-lazyloader.php” in wp-includes/wp-settings.php (where it exists in 6.2.2) rather than move it into wp-includes/meta.php (where it exists in 6.3). This appears to be the cause of the errors I originally reported.
After rolling back one of the sites to 6.2.2 I’ve tried a manual update on it (it’s not currently in use so I can test). That worked fine, even when the wp-config-sample.php file was not present) so I don’t know what could cause this to break during the automatic update.
Thanks, we’re not using W3TC, and the manual update appears to have worked correctly with exactly the same plugins as were on the site before.
Hi, thanks for letting us know. If the manual update worked, then there could be something else that affected the autoupdate, which led to the fatal errors you have mentioned in your original post. The rest are warnings so they might likewise be effects of the autoupdate failure. You could check in Tools > Site Health to see if there is anything that could help pinpoint the cause of the autoupdate failure.
Here’s the site health report for background updates. I can’t see anything else related:
Background updates ensure that WordPress can auto-update if a security update is released for the version you are currently using.
- Warning A previous automatic background update could not occur. You would have received an email because of this. Another attempt will be made with the next release. The error code was copy_failed_copy_dir_retry.
- Passed No version control systems were detected.
- Passed Your installation of WordPress does not require FTP credentials to perform updates.
- Passed All of your WordPress files are writable.
Hello, thanks for the Site Health info; it looked like another attempt was going to be made, so when you noticed the issues you mentioned, one possibility was the website was stuck in maintenance mode — if that had been the case, you would only need to remove a .maintenance file in the website root folder via FTP or your host’s control panel file manager.
I can’t say what caused the autoupdate failure though, it could be a temporary server resource overload. If you haven’t already, I would recommend having a regular scheduled backup in place to mitigate any risk of an autoupdate failure happening again in the future. Good luck!
Ok thanks, I don’t think it was stuck in maintenance mode as I couldn’t even get to the dashboard.