WordPress in the Cloud: Part 2, Themes

Wordpress in the Cloud

In the previous post in this series, we explained how to deploy WordPress to a production cloud environment. As an app which wasn’t specifically designed for the cloud, WordPress has to be handled specially to make this work. In the conclusion to a previous series, we outlined a solution that does this with the minimum effort and yet great reliability. In the third post in this series, we look at a contrasting technique, using the admin interface to install an Amazon Web Services Simple Storage System (S3) plugin.

In this post, we’ll be looking at installing a theme. This is not an essential task for setting up WordPress on Engine Yard, but it’s a common option. It also helps to illustrate the frozen app approach that lets us configure locally, and deploy remotely.

The installation method for themes we’re covering here is the manual approach. This will help you to learn what’s going on under the hood. In the next post in the series, we’ll be looking at a contrasting technique, using the admin interface to install an S3 plugin.

The Theme Machine

WordPress maintains a theme directory. Have a look around there. Once you’ve found a theme you want to try, download it.

Unpack the archive and move it to your wp-content/themes directory.

That whole process might look something like this:

$ cd ~/Documents/my-blog/wp-content/themes
$ wget http://wordpress.org/themes/download/responsive.1.9.5.3.zip
$ unzip responsive.1.9.5.3.zip
$ cd ~/Documents/my-blog

At this point, we should install the theme locally via the WordPress admin console, and verify that everything works.

Start your dev PHP server:

$ php -S 127.0.0.1:8080 -t ./

Before we deploy this to Engine Yard, we need to configure the theme locally, and verify that everything works.

Visit http://127.0.0.1:8080/wp-admin to load the admin dashboard of your local blog. Then go to Appearance and then Themes.

You should see the theme you added on this screen. Activate it. Your theme should be activated immediately. Check your local blog URL to verify.

Note, however, that in this instance, the theme we chose is suggesting that we install some additional components:

This won’t happen for every theme, but if this happens for you, click Begin installing plugin, and follow the instructions to install it.

Be sure to Activate Plugin on the confirmation screen. If you forget to do this, you can activate the plugin under Plugins, Installed Plugins.

Let’s briefly recap what we’ve done here:

  • We installed a theme manually by downloading the source

  • We configured WordPress via the admin console, which wrote some configuration options to our local MySQL database

  • We then installed a theme plugin from the admin console, which downloaded some files on our behalf and installed them locally

So, to deploy this we will need to:

  • Freeze the file system state by checking in any file changes

  • Deploy the files to Engine Yard

  • Log in to our production blog and replay the same configuration changes in the admin dashboard

Let’s start by checking what changed on our local file system:

$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# wp-content/plugins/responsive-add-ons/
# wp-content/themes/responsive.1.9.5.3.zip
# wp-content/themes/responsive/
nothing added to commit but untracked files present (use "git add" to track)

Here we see the files that have been fetched from the Internet (either manually or automatically) and installed on the local system. We must now add them to Git, commit, and push:

$ git add wp-content/plugins/responsive-add-ons
$ git add wp-content/themes/responsive.1.9.5.3.zip
$ git add wp-content/themes/responsive
$ git commit -m 'Add Responsive theme'
[master 2e3ac15] Add Responsive theme
296 files changed, 68583 insertions(+)
[output snipped for brevity]
create mode 100644 wp-content/themes/responsive/sidebar.php
create mode 100644 wp-content/themes/responsive/single.php
create mode 100644 wp-content/themes/responsive/sitemap.php
create mode 100644 wp-content/themes/responsive/style.css
create mode 100644 wp-content/themes/responsive/wpml-config.xml
$ git push
Counting objects: 324, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (317/317), done.
Writing objects: 100% (320/320), 2.03 MiB | 685.00 KiB/s, done.
Total 320 (delta 163), reused 0 (delta 0)
To git@github.com:nslater/ey-wp-test.git
   af1f8fc..2e3ac15  master -> master

Git now holds the master record of what our file system should look like. Doing this allows us to deploy the same files to every web server in our production environment.

Note that if you had installed these addons in your production environment, only the web server you installed them on would have the files. This is why we do everything locally.

Once you’re satisfied with the theme, log in to Engine Yard and redeploy. You will then have to visit your production blog and repeat the same configuration steps.

Specifically, you must:

  • Re-select the chosen theme

  • Re-activate any theme plugin you installed

Remember that your dev database and production database are separate!

Conclusion

Congratulations, you installed a theme for WordPress in the cloud! The most important aspect of this process was that we didn’t install the theme on our production app. We installed it on dev, and then took a snapshot of our state in a process that we call freezing the app. We were then able to use this frozen state snapshot to deploy to all of our servers in the cloud cluster, replicating them identically across many machines.

In the next post in this series, we’ll look at using a different approach. But we won’t be deviating from this core "freeze and deploy" method. Instead we’ll be showing that freeze and deploy works not only with a manual installation as covered here, but also for an admin interface installation, with an S3 plugin as our target.

We hope you found this guide helpful. Do you have any questions or comments? Have you deployed frozen apps in this way before? Please leave us a comment below.

About Noah Slater

Noah Slater is a Briton in Berlin who’s been involved with open source since 1999. They’ve contributed to Debian, GNU, and the Free Software Foundation. They currently serve as a member of the Apache Software Foundation. Their principal project is Apache CouchDB, the document database that kicked off the NoSQL movement. They also help out in the Apache Incubator, where they mentor new projects in the ways of community and open source.