I’m going to show you how easy it is to migrate WordPress using only the command line. It is just as simple as installing it, in the first place. If you followed the tutorial on deploying wordpress from terminal successfully, you’ll have no trouble with this one.
To be honest, unless you’re using the kick ass wp-cli tool. I’ve found that it’s easiest, and fastest, to use the command line to migrate WordPress. There’s no fiddling about with random plugins that’ll clutter up your database and bother you otherwise. And, in the end, it’s really only a few commands.
All we need to do is make sure we have all of the files and the file structure intact, as well as the database. If you’re moving from one domain name to another, you may need to find and replace in the database, everywhere your origin domain exists with your destination domain. Or, you could just update the website’s settings with your destination domain prior to performing the migration.
We’ll touch on fixing the configuration, if you forgot to update your domain before the migration, at the end.
Zip and Grab the WordPress Files
Go ahead and SSH into the machine hosting WordPress that you plan to migrate and zip up the entirety of the wordpress directory.
ssh <source host>
sudo zip -r wordpress-migration.zip *
sudo mv wordpress-migration ~
You’ll see a lot of spam fly by as zip recursively compresses all of the files in preparation for our WordPress migration. Finally, I move the zip archive back to my user directory, where all that’s left for that part is to change the ownership to my user and pull it down. But, we still need the database or we won’t have anything for users or content or anything that matters.
Now migrate your files to your new host. In case you haven’t noticed, this is exactly how you’d perform disaster recovery on a WordPress website that’d been compromised or suffered a hardware failure or anything else catastrophic. As well, it’s not far from manually deploying WordPress from the terminal either.
Go ahead and use SFTP (which comes bundled with OpenSSH) to connect to your new host and transfer your backup for restoration and recovery.
sftp <destination host>
Now we simply extract the WordPress files on their new host. Then we will fix the file permissions. Create an empty database, database user and restore the SQL database at it’s new home.
Change directories to webroot (if that’s where you want WordPress to live). Extract the files and proceed to log into the SQL server.
sudo unzip ~/wordpress-backup.zip
Next we connect to our MariaDB server and create a shell for our WordPress website to move into.
sudo mysql -u root -p
MySQL> create database wp_database;
MySQL> grant all privileges on wp_database.* to 'wp_db_user'@localhost identified by 'wp_db_password';
MySQL> flush privileges;
Now that we have a skeleton in place, all we need to do is restore the SQL content by populating the database with a quick one-liner and fix the file permissions and we’re golden!
mysql -u wp_db_user -p wp_database < wordpress-database-backup.sql
Setting the Correct Permissions after our WordPress Migration
I’m going to walk you through a WordPress deployment, using only the terminal. This is mostly because I need to put some content up here. And, once upon a time, this used to be one of my staple articles. Nothing has changed, really. But, I will reiterate the fact that you really should know how to do things manually, because you start plowing ahead and automating them.
Automation is good, it’s absolutely necessary, even. But, when things break, it’s best that you’re able to figure it out how it happened. And, the easiest way to obtain that information is, sadly, the hard way.
WordPress being so evolved.. Please do not expect a WordPress deploy to be something you can’t handle. Deploying WordPress is very straightforward. So, let’s get started.
LAMP: Linux, Apache, MySQL and PHP
WordPress runs very well on almost any web server. But, for the purposes of sticking to the documentation, we’re going to use Apache (not that I always stick to the documentation, mind you). You should familiarize yourself with a “LAMP” deployment anyway, it’s pretty much what powers the entire internet. Please note that MySQL is often replaced with either MariaDB or Percona Server. I won’t go into the differences here.
Go ahead and SSH into your web server, update your software repository and do a full system upgrade. There’s no reason to deploy LAMP without the latest patches. I’m using debian, so your commands may be slightly different for these types of things. Refer to your distributions handbook, if you need to.
Hah! Before, that required us grabbing a whole lot more packages than it does these days. But, don’t worry! We will still need to go get various PHP libraries for our WordPress deploy to be successful (specifically, for it to interact with mariadb). Still, you don’t need to do anything else there on Debian, unless Apache was previously configured with libapache2-mod-php. Then go ahead and issue the following (unexplained):
sudo a2dismod php
sudo a2dismod mpm_prefork
sudo a2enconf php7.3-fpm (at time of writing, 7.3 was stable)
sudo a2enmod mpm_event fcgid cgi proxy_fcgi setenvif rewrite
There’s plenty of other Apache modules that are beneficial for WordPress, but we’re just doing a deploy right now.
Prepare MariaDB for Production
I’m pretty sure that we all knew MySQL shipped with insecure defaults for many years. So, I have no idea, why this tradition has carried through to MariaDB. But, it’s my opinion, that we should damn not be having to still do this bit here. But, set a root password for the SQL db. And, disable remote access. Run ‘mysql_secure_installation’, press Y to everything and set a password.
Install the Minimum PHP Requirements
As I just said about Apache, there’s also plenty of PHP libraries that will benefit WordPress, but they’re beyond the scope of this walk through. So, we’re only going to grab what WordPress requires to install without complaint, as well as what is required to return a green health check.
I, honestly, don’t know what to tell you about PHP modules. Depending on your linux distribution, your PHP package is going to come with different modules. There’s really no telling what was bundled with it and what wasn’t. If you’re on Debian, this will get WordPress up and running, at least. But, on others, the packages will be named differently anyway. So, try to reach this minimum.
WordPress Deployed from Terminal
On Debian, Apache’s default “webroot” is in /var/www/html . Your “webroot” may be in a different location. If you don’t know, check your Apache configuration. It should be located in /etc/apache2 or /etc/httpd – The filename would either be apache2.conf or httpd.conf
Anyway, back to manually WordPress deploying from the terminal. I’ll have to clean this up later. But, for now, I’ll just finish what I started. Jump on over to webroot, grab the latest version from wordpress.org and extract it. All that’s left after that is to create a user for “MySQL”, set permissions and run the installer.
Note: this next part you can ignore. What I am doing is deleting my webroot and moving the folder wordpress extracted to in place of my webroot.If you extracted wordpress into ./html/ then you don’t need to do this.
rm -rf ./html/
mv ./wordpress/ ./html/
Create a MySQL Database, a MySQL User, Marry Them
Now we need to create a MySQL database. Create a MySQL user and grant it privileges to write to the database. Then, fix the file permissions and we’re done with the terminal (the website is technically up, a that point.
mysql -u root -p (perhaps prefix with sudo, if you're not root)
mysql> create database wordpress;
mysql> grant all privileges on wordpress.* to 'wordpress'@localhost identified by '[email protected]';
mysql> flush privileges;
Let’s set some privileges, first give the user that runs Apache ownership of the files. Then set the directories to read/write, read/write by Apache’s user and group. Finally, give the files read/write to Apache’s user and read/execute to everyone else (since php-fpm needs to read and run them).
At this point, we really need to bust out our browser and complete the install, so we can prevent about a billion zombies from hammering away at our install script and owning the box (just log password attempts on WordPress for a week and you’ll see what I mean). So get your browser out and finish this bitch off! You’re done.
Good luck. Have fun! And, next map. If you’d like this handled for you, drop me a line at Gray Hat Freelancing!
FIN – Our Job Here is Done
There’s plenty more to do. Especially from a security standpoint. I can tell you right now, our file permissions are decent but not perfect. There’s optimizations that need to be made or your blog could become a zombie in a DDoS, etc.. But, those are for another article. For now, enjoy the WordPress deploy!