( Or How Restore your WP Site Manually, no Mirrors!)
The end of October brought a few surprises including a PHP vulnerability and a Kernel flaw.
As of this writing there is no patch for the Kernel issue, however patches for PHP were issued. Since this was a serious vulnerability, I decided to upgrade my WordPress instances.
One of my instances still uses a classic rather than a block theme. Thus I also decided to migrate it.
Well let’s say, I encountered a few issues during this process.
Motivation
A serious flaw was encountered on PHP that affected versions from 7.4 all the way through 8.5.
I was running PHP 7.4 on my WordPress instances. The reason was that when I migrated my sites to the cloud, I also upgraded my Ubuntu instance. However the version of WordPress (WP) I used did not support PHP 8.3.
I wrote a blog about it. In summary, I have to install PHP 7.4 and use alternatives to have WP work correctly.
Eventually, I did upgrade WP to the latest. Never did switch to PHP 8.3 which was running also by default.
When the flaw happened, I decided to upgrade to PHP 8.5 and from there take the opportunity of migrating one of my instances from a classic theme to a block theme.
Upgrading
PHP 8.5
Upgrading to PHP 8.5 was straight forward.
Of course you forget that you need to also upgrade the Apache and MySQL modules and of course tell Ubuntu to use 8.5.
Finally everything was working correctly.
Upgraded all the plugins on WordPress and then decided to migrate to a block theme. That is when problems started.
Classic vs Block Themes
You will think that doing this kind of migration would be as simple as installing a new block theme and then convert your pages.
Not really, I know now that there are a couple of pay apps that can do this, did not want to use them.
After changing the theme of course nothing was working!
Spent a couple of hours and realized better to switch back, this was going to take longer than anticipated, I had a backup. So I was able to do so, and did not have to use the backup either.
So after some research, decided to use the Staging plugin. This is a fantastic tool.
Installed it and then went to work.
Pretty soon I realized that I would have to do a quite a bit re-designing, in addition I would also have to compromise on a new theme, the ones I did try I did not like.
So eventually decided to create an actual staging site using a virtual machine and migrate the site there.
Good thing because of what happened next.
Before creating the VM, I decided to upgrade my plugins. Added a “Consent Preferences” plugin among others.
Deleted the staging site created by the plugin, created a backup using Updraft (another great tool also).
Everything went fine. A couple of day later got a noticed that about five plugins needed updating.
So I did a bulk update for all of them.
Then I realized something has gone wrong!
A few of the plugins I have updated were there but could not open their settings.
Got the dreaded notice:
“You do not have permission to access this page. Please log in and try again”.
Easy fix right, wrong!
WordPress Issues and Recovering
Among the plugins for which I could not open the configuration settings were WP-Statistics, Updraft and the Consent preferences.
While not having statistics is not a problem, consent should be available because of cookie tracking.
In addition Updraft allows me to backup the site, but more important I could revert to a previous backup that I knew did work because the plugin was not showing even though WP keep telling me it was installed and activated!
The plugins were installed but I could not configure them nor see stats or change the banner for the consent plugin for example. Deleting and re-installing did not work.
So I zeroing on the Stats plugin, did removed all others so I could test and debug and a fix would apply to all.
Interestingly enough, I was able to install a couple of other plugins like All-in-one-backup without an issue.
Since the backups I had were done using Updraft I needed to get that up and running correctly.
Try a few of the recipes posted on how to recover, including setting file permissions, editing the “.htaccess” file, and a bunch of other stuff. None worked.
So I created the VM I wanted originally and proceeded to manually restore my site.
Staging VM
Let’s deploy the staging VM.
- Create a VM.
- Several ways of doing this including doing it on windows.
- Install the same OS, Ubuntu in my case.
- Install the same versions of Apache, MySQL, PHP.
- Start Apache and install WordPress.
- Configure Apache to use the WP instance and make sure MySQL is up and running.
- Create the WordPress database with the same DB name you are using on your real site.
- Also create the same user with the same credentials.
- Access the new staging site.
- You will need to mimic access to it by using a hosts file on which you set the new IP to let’s say “test.mydomain.com”
- Use the cert that Apache installs by default, it will not interfere.
After accessing WP for the first time, it will create a DB, you will need to modify the WP config file in advance. Make sure to test the instance of WP works fine.
Restoring the WP site
Now we are ready to restore your site.
- Install the Updraft plugin.
- However, you do not have backups. No problem.
- On your original site, copy the wp-content/updraft folder to the test site.
- Make sure that permissions and privileges are correct.
- Open Updraft, re-scan for backups and you should see the backups from the old site!
- Choose a backup, if you created the backup with the DB, Plugins and other files under wp-content you should be fine, otherwise I will show you how to fix if you are missing some stuff.
- Restore, it will complaint that the FQDN is wrong keep going.
If everything goes well you will see the backup has restored the DB and at least the plugins.
Testing
Refresh the web page. You should see your site up. Test and make sure everything is working fine.
If you try to open a photo gallery or you are missing icons, etc, it is because your backup did not include the “uploads” folder.
The DB only contains pointers to where the actual files reside. Go to your site and copy “wp-content/uploads” onto the test site.
You should see everything working on your site. Update plugins, etc.
You now have your site recovered. Well what do you do now?
Recover Site
On your test site, use zip and zipped the whole folder that contains your WordPress site.
On your actual site, move the WordPress folder site to let’s say old-site.bak.
Then copy the zip file created onto your old site by some means, then use unzip on the directory that should contain your site.
Make sure privileges and permissions are correct for the folder and everything under it.
Restart Apache and voila your site should be back!
Conclusions
The above way of restoring your WordPress instance is extreme, however it will always work if you have at least a backup of your original DB and a copy of the uploads directory.
You can then always re-install missing plugins, since you have a DB and the uploads folder, plugins will work fine. In my case my site was not completely kaput however, I could not use some of the plugins that I needed.
I do not recommend this in general, it is not for the faint of heart, but it will work as the last resort when everything else fails. If your backup plugin is not affected then use that and recover the site.
There you have it.
Ciao.