Well, I’ve had two DigitalOcean droplets running WordPress for the last two years and I basically haven’t paid them any attention. So, don’t be that person. Either move to a server-less installation where someone else is doing the work. With DigitalOcean, you can create your own droplet which is their term for a virtual server. This turned out to be much faster than Bluehost and since it is your own server, I got the latest versions of PHP and so forth.
But the problem is that you can’t really leave this stuff alone, so when trying to fix a site here is what I discovered so everyone should be careful.
- If you use Updraft running, make sure that you point it at an “infinite” store. I had thought that it was pointed to my paid Google Drive (with 2PB worth of storage), but I had not set this correctly, so instead my modest 25GB disk virtual server was literally completely filled with backups. I had it set to keep 400 backups and do it weekly which is way too much, so I reset to 100 backups every month. Remember, this is just in addition to what Digital Ocean is doing anyway.
- The net is that if you are going to use a service like this, you should also pay for regular backups. Digital Ocean has an easy to use backup service. So your $5 node costs an additional $1 to get full backups. I also have snapshots (you have to run them with the server stopped), but backups are a must. If you do this, then you don’t really need the WordPress level backup although theoretically, the WordPress one is synchronous so in the unlikely event, you are doing a post right when a backup is being made, you will have an inconsistent system.
- My biggest mistake was not understanding what was going on and just going from a $5/month to a $10/month node to get 50GB. What happens if you are out of disk though is the automatic resize will actually fail because there is no disk space left. So when using
lsblkI saw that I had a 50GB drive, but was only using 25GB. As soon as I freed up space, ubuntu automagically went to 50GB. - Once that was done, I could reset Updraft and also do an rsync to copy down those updraft files as additional insurance.
In any case, a quick remove of all the /var/html/updraft files from last year got me enough space and once that happened the resize could happen and the droplet could breath again!
Do not reset the password on the root account.
The second dilemma is that I wanted to copy all the backed up files down, but I discovered that from the Admin console on Digital Ocean it kept on asking for a password. With AWS, when you use the console it knows about your ssh keys and you never have to type a login, with Digital Ocean, every droplet by default has password over ssh turned off for security reasons, so you can’t actually use the graphical login.
I didn’t realize this and ran the reset password from the Digital Ocean console. Now I was in real trouble, I was not in an infinite loop because authentication is turned off, so I could login the first time, but it would not save the new password and kept on asking for it. The solution by the way is that when you ssh in, you can’t execute bash. This is the thing that is doing the checking so ssh root@_your_droplet_ip_address does not work, but if you run a command like ssh root@_your_droplet_ some_command then that works.
Keeping up with version
The really horrible thing though about having a droplet is that you have to maintain it. I have not touched this droplet in a long time and I had forgotten what a pain it is to keep things up to date. Specifically, there are security issues with the PHP that is in ubuntu 18.04 (the droplet template I used), so I really needed to upgrade to 20.04. That turns out not to be too hard. You basically run a single command. There is this cool upgrade command called do-release-upgrade which does the whole conversion. It is pretty painless.
And of course, you have to do the apt-get update && apt-get upgrade as well. Geez, I really want to move as quickly as possible to a JAMStack because then I’m not maintaining an entire operating system.
Solutions where you do not maintain a server
Well, there are few, first is that Digital Ocean now has Applications as a service, so if you like WordPress, you move to their managed MySQL service and then you can package up WordPress as a special GitHub repo and run it that way. You use something called Bedrock to do this.
Or you can use tools like Locust to upload a standard WordPress image, this still leaves you with the update problem.
Moving WordPress to Hugo
Well, it turns out that if you want to move from WordPress, you can do this. You can for instance, get all your images by doing an rsync of the media folder and then recreating it. It is sort of painful to recreate all of this because the standard WordPress user interface doesn’t have a media download button although they have a media upload one.
Or if you have a large site, you can try an export utility to get your text and your images over. Of these, the little Java application you run on your local machine to do this. For me, I’m mainly working on small “vanity” sites, so all I really need are the images and then will pour them into a new template on the Hugo side.
So to move things from WordPress, the main thing is that you can find the media uploads in /var/www/html/wp-content/uploads
