- Hide menu

Blog

Tips on using Migrate Guru to move a WordPress Multi-site with FTP

 

I wanted to move a WordPress Multisite from Digital Ocean to a Raspberry Pi running on my LAN. The total size of the sites was just over 1 GB. After checking Google, it seems the Migrate Guru plugin could do the job. After several failed attempts, it finally worked and here are my tips, and limitations:

  1. If you’re moving a Multisite, create a working Multisite with a couple of sites on your destination server before starting the migration. If you just have a standard site the migration failed for me with redirection errors.
  2. I had an ftp server setup on the destination server but I could never get Migrate Guru to work with FTP. Rather, install the Migrate Guru plugin on the destination server and copy the Migration Key into the Migrate Guru’s migration page on the origination server. This method seems to use http as the transfer protocol and you don’t need to enter any IP address or site URLs.
  3. The migration took around 3-4 hours to complete for my 1 GB and 8 web sites.

After the transfer, if you want to have the same primary site as the origination server, you’ll need to edit the wordpress database tables. Otherwise, the primary site will be the name you setup prior to the transfer.

You may also need to update your DNS records to point the host to the new IP address, create virtual host files in your Apache configuration as well as getting SSL certificates for all the hosts.

Tech Tip: Port forwarding WordPress on Raspberry Pi and DNS name resolution

I was following the excellent instructions on how to Build a LAMP Web Server with WordPress on my Pi running on my LAN. Everything worked fine with the internal LAN IP address. I wanted to have the web server accessible from the Internet and I thought all I had to do was setup port forwarding and point an A record on a DNS to the public IP address. But I was wrong.

While I could access the WordPress server using the external IP address, so port forwarding was working correctly, it would not respond when I used a host name set up in the DNS A Record. Turns out the reason is that Apache needs to be set up with a Virtual Host record. And it’s best to setup WordPress via the host name URL rather than the internal IP address. So, here are some modified steps to the above tutorial:

  1. Install Apache as per the tutorial. Stop there, don’t install the database and WordPress yet.
  2. Add an A Record with the host name to your DNS and setup port forwarding so the host name access your Apache server. You should forward ports 80 and 443 for http and https. More on this later.
  3. Now set up a virtual host on Apache. There are good tutorials on doing this here and here. Basically you want Apache to respond correctly when you use a host name rather than an IP Address. Once you’ve done this, test the accessibility by using a web browser with a VPN (or another method such as using your smartphone’s mobile data) to confirm that your web server is accessible from outside of your LAN. Note, some web browsers, eg Apple’s Safari on iOS and iPadOS will not connect to your web server on http. So use Firefox or Chrome to test.
  4. Now set up an SSL certificate so your virtual host is accessible using https. I use the instructions here. Test the connection using the VPN enabled web browser.
  5. Now that you’ve got your web server accessible via http and https from outside your LAN you can finalise the setup of WordPress.
  6. Continue with the installation of the Marian DB and WordPress. When it comes to setting up WordPress, using the VPN enabled web browser with the host name rather than the internal LAN IP address

You’ll now have an externally accessible WordPress server running on a Pi on your LAN. But if you run the Site Health test, it will suggest that the install the following php modules:
sudo apt install php7.4-gd
sudo apt install php7.4-curl
sudo apt install php7.4-xml (for DOM)
sudo apt install php7.4-mbstring
sudo apt install php7.4-zip
sudo apt install php7.4-intl
sudo apt install php-imagick

I also added 127.0.0.1 <host name> to the /etc/hosts file and used certbot to add SSL/https access.

URL to show Google reviews

Took a bit of Googling to find, but here’s the answer on StackOverflow:

https://stackoverflow.com/questions/52021393/link-to-show-google-reviews

The answer is to find the placeid and use this stub
https://search.google.com/local/reviews?placeid=<place_id>

Or use the hack via Google Maps and getting the link to reviews via the embed map popup

How to upgrade the soldered SSD on your Macbook Mini and Studio

Apple has soldered the SSD storage onto the motherboard for years now. Here is detailed and succinct explanation of how you might upgrade the storage, and probably why you won’t want to do it yourself.

TP-Link Archer AX80 not recommended for Macbook iPad and iPhone

TLDR; Not recommended for an Apple device environment.

My Netgear RAX50 which I use as an access point is now two and half years old. I was evaluating alternatives and the Archer AX80 (aka AX6000 8-Stream Wi-Fi 6 Router with 2.5G Port) was available for virtually half the price of what I paid for the RAX50. And on paper, better specs. But in less than 24 hours, the AX80 is getting returned. It appeared to have a fundamental flaw. Five minutes after a startup or a reboot, the throughput dropped by over 50% to my 2021 MacBook Pro.

On a 1000/50 NBN connection, my Macbook would get 700-800 Mbps on the Netflix Fast.com test, and a similar speed via Speedtest. This is via a 80MHz channel setting on 5Ghz 802.11ax. This is 5-15% faster than my RAX50 on a similar 802.11ax setting. Thinking all is well, I’d return to run the test again 5 to 10 minutes later only to find that the throughput dropped to 250-350 Mbps. Tried all the settings I could find on the router but the only way to get to the original speed was a reboot. And then again, 5-10 minutes later, the throughput speed would drop again.

This happened on both the MacBook Pro and an iPad Pro. However, an iPhone 14 Pro didn’t encounter this issue. I can only surmise that there is a bug in the router software in how it interacts with Apple’s wifi. Also note that it seems TP-Link routers in Australia are “EU” specifications and it does not have the UNII-3 channels: 149, 153, 157, 161, and 165. This was very disappointing as the DFS channels also didn’t work with the MacBook Pro. It seems this is a common problem with TP-Link routers and TP-Link omits details of available frequencies on the product’s specifications. Make of that what you will.