This is a series of articles explaining how to speed up WordPress, the use of which is growing rapidly for CMS-based business sites and media sites. This time, we will explain how to implement Always-On SSL and HTTP/2 on an existing HTTP WordPress site.
Last time, we explained how to set up a new WordPress site that uses Always-On SSL and HTTP/2, first with free certificates through Let’s Encrypt in Vol 13, then with business SSL certificates in Vol 14.
However, there are probably many of you who already have your own WordPress site running. Over the next two installments, we will explain how to migrate existing HTTP WordPress sites to KUSANAGI and configure them with Always-On SSL and HTTP/2.
Along with this article, please check “Using KUSANAGI – Adding Always-On SSL and HTTP/2” for some basics on Always-On SSL and HTTP/2 and why they are necessary.
(Helpful link) Always-On SSL and HTTP basics and background
Step1: Migrate an existing HTTP WordPress site running on a different platform to KUSANAGI
First, we will migrate the existing WordPress site over to KUSANAGI, then enable Always-On SSL and HTTP/2.
If you are already running a WordPress site on KUSANAGI, skip to step 2 (to be published soon).
We will now perform the migration to KUSANAGI. We will use these example settings for before and after installation (Table 1).
|WordPress install directory||/var/www/html||/home/kusanagi/example.com/DocumentRoot|
|Location of wp-config.php||/var/www/html/wp-config.php||/home/kusanagi/example.com/wp-config.php|
|Database host name||localhost||localhost|
|Database user name||wpuser||exampleuser|
First, prepare the necessary data files before migrating. To migrate WordPress sites, in general you need the database dump file, files in the document root and wp-config.php.
1: Create a database dump file
Log in to the pre-migration environment’s shell (if necessary, as an admin user), and then run the following command to create a dump file.
cd /var/www mysqldump -u wpuser -p -h localhost example > example.sql
The command to create the database dump file in the pre-migration environment.
2: Consolidate the data into one file
In (1), we created the database dump file in /var/www. Using the following command, we will package /var/www/html – including /var/www/example.sql, and wp-config.php into one file.
cd /var tar czvfp www.tar.gz www
Package the database dump file and document root into one file
3: Send the data to KUSANAGI
Set up the KUSANAGI environment that you will migrate to. Consult “How fast is KUSANAGI, the “1000x speed” WordPress virtual machine?” and follow the “KUSANAGI Provisioning” instructions. Since we are doing a migration and not an install, there is no need to do the “WordPress Installation” section.
At this point, the pre-migration WordPress site is still running. Without switching the DNS (it would be a good idea to set the TTL to about five minutes in preparation for switching the DNS), resolve the host name with the client machine’s host file. When doing KUSANAGI provisioning, use the profile name (the top directory name, example.com), URL, database name, database user name, and database password shown in Table 1. Also, since we are doing a migration with HTTP, skip over the SSL/Let’s Encrypt settings section.
After provisioning is finished, return to the pre-migration console and use the scp command to send the file we created in (2) to the KUSANAGI environment.
The KUSANAGI environment will receive files through port 22, so change the settings to temporarily allow a connection from the pre-migration environment to port 22. On cloud platforms like AWS, you might have to change the security settings from the management portal. You might also need to allow access to port 22 from the pre-migration IP address inside the KUSANAGI TCP wrapper (/etc/hosts.allow, /etc/hosts.deny).
scp www.tar.gz email@example.com:/home/kusanagi/
Send the file to the KUSANAGI environment