OK now that I’m sort of digging out here are some notes about getting it all working on all of this stuff. There are a bunch of gotchas that are pretty hard to understand, but in short:
- Make sure you have ssh access into the actual Droplet. You get this by looking at the console and seeing the raw IP address and making sure that you have your public ssh key up on Digital Ocean. If you do this, then a simple
ssh root@_the ip address_will work.
- When you are there, you will be confronted with a setup script. This is designed to get a single WordPress installation working on Apache2 inside the official image. Also you can disregard the documentation in the Digital Ocean marketplace, it is actually the latest version 5.2 at this writing (and not 4.9 as it says on the page).
- If you look through the instructions, it then tells you to run certbot and so forth. I actually had this fail and had to run it manually and do some hacking on
/etc/apache2/confwhich is where you tell Apache how many websites you want.
- The long and short of it is that you can actually run multiple WordPress installations on a single droplet. Given that a droplet is $5/month, it makes some sense if you have lots of small websites, then you can load their own WordPress installations and manipulate the files in
/etc/apache2/conf/available-sitesand when you want to enable a site, you run
a2enssitewhich symlinks the appropriate conf file into
current-sitesand then you have to
systemctl restart apache2for that to take
- If you want to reenable certificates, then you just run
certbotand it will look for the sites that are active and create a certificate for you. I’m not quite sure how it handles renewals as Let’s Encrypt obsoletes these free SSL certificates every 90 days.
Finally, you have to get your site back:
- I had a running site, so I could export the site information. There is a 25MB limit on imports, so you have to do this a series of posts at a time. If you have UpdraftPlus, you can also just run some sort of sync and clone which I didn’t do, but is an option later when I have hot backups running.
Getting JetPack to Work
- Finally, JetPack to WordPress.com and WordPress clients doesn’t seem to work with the latest versions of the firewall. So for some sites it works fine. The way to debug this, is to try
curl _yoursite_.com/xmlrpc.phpand you should get a message that reads
XML-RPC server accepts POST requests onlyand if you don’t then you know something is blocking it.
- JetPack known issues says to check your firewall, but when looking at iSecurity it says that setting it to Security/WordPress Tweaks and System Tweaks, there are few settings that could be the issue, but they look identical
- Next step is a search which indicates this could be because I set Apache2 to redirect all http requests to https and this is unfriendly to XMLRPC.php and I can’t seem to find it in .htaccess. This also seems true of wp-login.php.
- In debugging this another funny aside is that with Bluehost, the main domain you have has a weird state, you can’t edit it and you can’t change the IP address of the
@record. So you have to use a subdomain to ssh into it.
- Net, net something is specifically blocking xmlrpc.php on this new installation and I can’t quite see what it is. I finally turned off iSecurity and I still got the error, it does say it comes from Apache, so somewhere in the Apache2 configuration I have this problem. Strange thing is that it happened with the old Bluehost site as well, so I wonder if WordPress 5.2 introduced something or if it is something in the DigitalOcean version of WordPress.