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 procedure involves following steps:
Create a new WordPress application on OpenShift.
Import MySQL dump to database.
Extract wp-content directories.
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 Chapter 1, OpenShift WordPress Tutorial
. It is mandatory to use the same name as the deleted application. We should also complete the installation of WordPress as explained in Chapter 2, 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
> 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
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 --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 Plugin creates some files outside the standard
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 Chapter 7, WordPress W3 Total Cache
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
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.
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
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
→ , 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.
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.