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
That whole process might look something like this:
At this point, we should install the theme locally via the WordPress admin console, and verify that everything works.
Start your dev PHP server:
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:
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 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!
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.