11.3. WordPress Restore, Clone

In the previous section, we saw how to offload the backup files to the Dropbox. In this section, we use the backup for a full WordPress restore and also to clone it to a new site and use it cloned site as testing or staging area.

WordPress Restore

WordPress Restore procedure involves following steps:

• Create a new WordPress application on OpenShift.

• Import MySQL dump to database.

• Extract wp-content directories.

CLI

To step through WordPress Restore procedure, we have to access OpenShift Shell through RHC or PuTTY (for Windows users) and securely copy files using SSH. OpenShift RHC Client Tools and OpenShift Linux Primer explains the secure copy.

Create WordPress Application on OpenShift

When we do a WordPress Restore, it means, we already have an OpenShift account with a WordPress application. To restore WordPress from the backup, we have to use the same Public URL for the new WordPress instance. WordPress Restore to a different URL is known as clone.

Delete the existing WordPress application to free up the public URL for the new application.

Window and Linux

C:> rhc app delete <app-name>

We can also delete the application through OpenShift Web Console. This step is irreversible so delete the application only when there is a full backup.

Next, create a new WordPress application as explained in OpenShift WordPress. It is mandatory to use the same name as the deleted application. We should also complete the installation of WordPress as explained in WordPress Installation. Once application creation and WordPress installation are complete, open the WordPress dashboard to check whether site is up properly.

Usually for a fresh WordPress installation, we proceed to install themes and plugins. However, for WordPress Restore there is no need to install theme and plugins as these components comes from the backup.

Download Backup file

We can download the backup file from Dropbox directly to the OpenShift server. To do that, we need the URL of the backup file.

Log in to Dropbox and navigate to the folder which has the backup gzip file. Select the latest backup file and click on Share Link menu to open the sharing window in a new tab. In the popup, click Get Link to copy the file’s URL to clipboard.

Next, log in to OpenShift Shell. Windows users use PuTTY or RHC.

$ rhc ssh quickstart

In OpenShift Shell, change directory to app-root/data.

> cd app-root/data

Download the backup file from Dropbox using wget command. Replace the URL shown in the command with the actual URL copied to clipboard.

> wget https://www.dropbox.com/s/5tpxxxxp2w/quickstart-wordpress-backup-2014-06-11.tar.gz

WGet downloads the backup file quickstart-wordpress-backup-2014-06-11.tar.gz from the Dropbox and saves in app-root/data directory.

Extract WP-Content folders

Using tar command, we extract the contents of the backup archive. Replace the example file name shown in command with the real file name.

> tar -xzvf quickstart-wordpress-backup-2014-06-11.tar.gz

Backup file extracts to three folders - themes, plugins and uploads and one SQL file. Extracted folder contains the plugins, themes and media files from the backup WordPress installation.

At this point, when we open the dashboard, these items are yet to show up in the admin menu. Reason being; WordPress stores plugins, themes, and media file metadata in MySQL database table, and we are yet to import database.

Import MySQL Tables

Among the extracted files, we also find a SQL file that contains database of WordPress installation.

To import SQL file, use mysql command.

> mysql --password=$OPENSHIFT_MYSQL_DB_PASSWORD -u $OPENSHIFT_MYSQL_DB_USERNAME -S $OPENSHIFT_MYSQL_DB_SOCKET $OPENSHIFT_APP_NAME < quickstart-2014-06-11.sql

Replace the example filename quickstart-2014-06-11.sql with the real SQL file name. SQL import drops all the tables in database and recreates tables with data from our old WordPress site.

With that, we finished the WordPress Restore. Restart the application through OpenShift Web Console or RHC. Open the WordPress and check the contents. It should contain all posts, pages, themes, plugins and media from the old site.

W3 Total Cache

W3 Total Cache Plugin creates some files outside the standard wp-content/plugins directory. Moreover, it also hard codes WordPress installation’s absolute path in some PHP files. In OpenShift, the absolute path contains the application UUID and it changes when we restore the WordPress to a new application. Even though we can edit certain files and bring up W3, it is safer - and also easier - to delete the W3 Plugin, reinstall and setup as explained in WordPress W3 Total Cache

Remove uploaded files

Once we are finished with the WordPress Restore, remember to delete backup files from the data directory to conserve storage space.

> cd app-root/data
> rm *.gz 
> rm *.sql

Clone WordPress Site

To try out new themes or plugins or troubleshoot some issues in a live site is always a risky proposition. We would rather prefer to do these activities in the testing site. Clone creates a new WordPress site with the same content as the original but with a different URL. Cloned site comes handy to test version upgrades.

To clone WordPress, create a new WordPress application with a different name as explained in OpenShift WordPress. We should also complete the installation of WordPress as explained in WordPress Installation.

All other steps are same as that of Restore explained in the last section, except we need to modify site URL in SQL file before importing. To summarize, steps to clone are:

• Create a new WordPress application in OpenShift, with a different name. Complete the WordPress installation.

• Download backup archive file to OpenShift app-root/data directory and extract it.

• In the extracted SQL file, replace all occurrences of the original site URL with clone site (new site) URL. We explain this in detail in the next para.

• Import modified SQL file to MySQL database.

Modify SQL file

We use a Sed command to replace matching strings in the file. Execute the following command to replace all occurrences of the original site URL with a new site (clone site) URL in extracted SQL file. In the next command, replace <orginal url> and <new url> with Public URL of your existing and new WordPress applications.

> sed -i '#<original url>#<new url>#g' <SQL File Name>

For example, if your original WordPress application is travel-xyz.rhcloud.com and URL of the new site is test-xyz.rhcloud.com, then command would be

> cat *.sql | grep -o "http://travel-xyz.rhcloud.com" | wc -l

> sed -i '#http://travel-xyz.rhcloud.com#http://test-xyz.rhcloud.com#g' quickstart-2014-06-11.sql

> cat *.sql | grep -o "http://test-xyz.rhcloud.com" | wc -l

Import the SQL file to MySQL database as already explained in the Restore section. We check whether number of URL are same before and after modification with cat commands. URL modification is essential otherwise whenever we click an internal link in cloned site, it takes us to the original site!

Next, open the General Settings of cloned site and change Site Name so that we know that we are working on cloned site. We also need to discourage search engines from indexing our cloned site, and we do this by changing settings in Settings → Reading.

With that, our cloned WordPress site is ready for use as testing or staging site.

WordPress Version upgrade

Apart from trying out new Plugins and Themes, a WordPress testing site is also useful to test version upgrade of WordPress core, Plugins, and Themes.

WordPress periodically checks for updates to its core, plugins and themes. When there are updates available, WordPress Dashboard displays a notification in Updates menu and also in the Admin bar.

When there are updates, open WordPress Updates screen using Dashboard → Updates, which shows updates in three blocks - WordPress Core, Plugins and Themes. Select items one by one and apply the update and verify the site functionality after each update. After some updates, we may have to restart WordPress application through OpenShift Web console.

Blank screens !

WordPress may display a blank screen after an update. Before trying out any other thing, always restart the OpenShift WordPress application through OpenShift Web Console.

After a successful upgrade of the test site, we can go ahead and upgrade the live site. Usually, WordPress core and also the leading themes and plugins upgrades are stable and upgrade goes without any hitch. Still, we always prefer to test them rather than to face some nasty surprises in the live site.

Though out the tutorial we used WordPress that is bundled as OpenShift Instant App. In the next chapter, we describe WordPress Installation from the source.