I’m one of those WordPress guys who rant about keeping regular backups. Even using a fantastic plug-in that automatically runs a backup every weekend. Everything was running great and I had months of backups safely stored on my web server.
Until today, I decided try and install Certbot without testing it on a non-production server first.
Everything seemed to work perfectly. Until I rebooted my server droplet and it was serving up my index.php template as straight code. Certbot and My Digital Ocean WordPress droplet had a conflict, likely I made a mistake.
As best as I could tell Certbot expected Apache to be configured a particular way; perhaps it the droplet’s customizations were at odds. Either way I no longer had access to my droplet via ssh, sshfs, or ftp to download my server side backups. To make things worse I didn’t store any backups locally or on another server.
This could have been easily avoided
Digital Ocean offers snapshots and backups that can be manually deployed at any time. I didn’t bother to create one.
I had months of weekly backups. I didn’t bother to take a few minutes to download one.
My backup plug-in, online communities and my own rants about keeping multiple backups were not heeded.
It’s not all bad – This blog is where I test ideas and break stuff
Of all the posts only three or four contained useful content. The rest was old posts imported from social media and a few bits of custom wallpaper. Nothing was irreplaceable or important.
Feel free to break stuff in production, just don’t forget the backups.
First create a unique function in the child theme’s functions.php file where style can be dequeued using the parent theme’s handle. Then add this as an action to run a little later than the parent theme’s enqueue process.
I’ve read that the default enqueue value in most themes is 10, so running it at twenty will remove it later in the loading process.