Rich's Tongfamily

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:

1. 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.
2. 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).
3. 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/conf which is where you tell Apache how many websites you want.
4. 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-sites and when you want to enable a site, you run a2enssite which symlinks the appropriate conf file into current-sites and then you have to systemctl restart apache2 for that to take
5. If you want to reenable certificates, then you just run certbot and 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:

1. 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

1. 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.php and you should get a message that reads XML-RPC server accepts POST requests only and if you don’t then you know something is blocking it.
2. 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
3. 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.
4. 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.
5. 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.