Using Capistrano with PHP, specifically WordPress

Here at Made By Many we are technology agnostic. Primarily because we believe a client should use the best technology solutions to fit them and fit the problem we are trying to solve. We work with lots of in-house technology teams and out-sourced partners for clients, offering technologyconsultancy wrapped into a holistic offering on next-generation website problems.

That’s not to say we don’t have technology preferences. With all things being equal for greenfield deployments we can work with the best technology to do the job. That’s why we have delivered several solutions using Ruby On Rails and use WordPress for delivering blog solutions, such as this one.

I’ve spent some time making WordPress deployments as easy as Ruby On Rails using the excellent Capistrano, this also lets me control environments which are hosting both WordPress and Ruby On Rails in the same way.

Capistrano 2, while built for Ruby On Rails, can be used as a generic deployment tool with a little work. It adds capabilities to open-source infrastructures which were previously only available to things like high-end J2EE application servers. Here are some of the things to make WordPress deployments with Capistrano.

Some dependencies

You are going to need rubygems and capistrano installed on your machine and apache on your server.

Directory structure

I use a directory server for my PHP applications which has parallels with a Rails directory, but because it’s PHP all of the code lives in the public directory. You are going to need this structure to separate out the PHP from the Capistrano files.

wpproject        |______config   (this is for storing the capistrano deploy.rb file)        |______log      (for server logs)        |______private        |______public   (the webserver vhost root with all the PHP files)

mkdir -p wpproject/config  mkdir -p wpproject/log  mkdir -p wpproject/private

Capistranoing WordPress

Now we install the latest version of WordPress.

cd wpproject  svn export http://svn.automattic.com/wordpress/trunk/ public

Great, now lets capistrano it, its a simple capify command away.

capify .

Now we have to make some recipes for capistrano. These will be our series of commands to make the deployments.

Creating a WordPress Deploy Setup Recipe

I created an extensive Capistrano recipe for configuring a new instance of WordPress, of which we’ll talk about the most basic setup.

Open up wp/project/config/deploy.rb in your favourite editor.

You need to add some setup tasks

set :app_symlinks, ["wp-content/avatars","wp-content/uploads","wp-content/cache"]
namespace :wordpress donamespace :symlinks do
desc "Setup application symlinks in the public"task :setup, :roles => [:web] doif app_symlinksapp_symlinks.each { |link| run "mkdir -p #{shared_path}/public/#{link}" }endend
desc "Link public directories to shared location."task :update, :roles => [:web] doif app_symlinksapp_symlinks.each { |link| run "ln -nfs #{shared_path}/public/#{link} #{current_path}/public/#{link}" }endsend(run_method, "rm -f #{current_path}/public/wp-config.php")send(run_method, "ln -nfs #{shared_path}/public/wp-config.php #{current_path}/public/wp-config.php")endendend

This sets symlinks from the release directory under the current link to directories in shared. This is so that information such as avatars, uploads and cache are maintained between releases. This also deletes any development wp-config you may have deployed and link to the server one stored in the shared directory.

This deployment scenario is also going to get Capistrano to create this wp-config for us.

Adding the follow tasks to deploy.rb in the wordpress namespace

set :wp_config_template, "wp-config.php.erb"
task :wp_config_php, :roles => [:web] dofile = File.join(File.dirname(__FILE__), "templates", wp_config_template)template = File.read(file)buffer = ERB.new(template).result(binding)put buffer, "#{shared_path}/public/wp-config.php", :mode => 0444end

And create the following file in a wpproject/config/templates directory

wp-config.php.erb

// ** MySQL settings ** //define('WP_CACHE', false); //Added by WP-Cache Managerdefine('DB_NAME', '<%=wp_db_name%>');    // The name of the databasedefine('DB_USER', '<%=wp_db_user%>');     // Your MySQL usernamedefine('DB_PASSWORD', '<%=wp_db_password%>'); // ...and passworddefine('DB_HOST', '<%=wp_db_host%>');    // 99% chance you won't need to change this valuedefine('DB_CHARSET', '<%=wp_db_charset%>');define('DB_COLLATE', '');
// You can have multiple installations in one database if you give each a unique prefix$table_prefix  = 'wp_';   // Only numbers, letters, and underscores please!
// Change this to localize WordPress.  A corresponding MO file for the// chosen language must be installed to wp-content/languages.// For example, install de.mo to wp-content/languages and set WPLANG to 'de'// to enable German language support.define ('WPLANG', '');
/* That's all, stop editing! Happy blogging. */
define('ABSPATH', '<%="#{current_path}/public/"%>');require_once(ABSPATH.'wp-settings.php');?>

This is going to create our server wp-config file for us but you’ll need to set the variables in the deploy.rb file

set :wp_db_name, "ourblog_wp"set :wp_db_user, "ourblog"set :wp_db_password, "pa55w0rd"set :wp_db_host, "localhost"set :wp_db_charset, "utf8"

But wait there is more!! We can also create our apache vhost using the same method

set :apache_server_name, "madebymany.co.uk"set :application, "ourblog"set :domain, "madebymany.co.uk"set :apache_server_aliases, []set :apache_ctl, "/etc/init.d/apache2"set :vhost_template, "wp_apache_vhost.erb"
namespace :apache do
task :vhost, :roles => [:web] doset :apache_vhost_aconf, "/etc/apache2/sites-available/#{application}"set :apache_vhost_econf, "/etc/apache2/sites-enabled/#{application}"
server_aliases = []server_aliases << "www.#{apache_server_name}"server_aliases.concat apache_server_aliasesset :apache_server_aliases_array, server_aliases
file = File.join(File.dirname(__FILE__), "templates", vhost_template)template = File.read(file)buffer = ERB.new(template).result(binding)put buffer, "#{shared_path}/httpd.conf", :mode => 0444send(run_method, "cp #{shared_path}/httpd.conf #{apache_vhost_aconf}")send(run_method, "rm -f #{shared_path}/httpd.conf")send(run_method, "ln -nfs #{apache_vhost_aconf} #{apache_vhost_econf}")end
desc "Start Apache "task :start, :roles => :web dosudo "#{apache_ctl} start"end
desc "Restart Apache "task :restart, :roles => :web dosudo "#{apache_ctl} restart"end
desc "Stop Apache "task :stop, :roles => :web dosudo "#{apache_ctl} stop"endend

This works with another Ruby builder (ERB) template file under wpproject/config/templates. In this example I’m using an Ubuntu Linux server with apache configuration installed under /etc/apache2 and a standard Debian setup using files under /etc/apache2/sites-available with a symlink from /etc/apache2/sites-enabled.

#vhost for <%=apache_server_name%>    ServerName  <%=apache_server_name%>    <% apache_server_aliases_array.each do |a| %>      ServerAlias <%= "#{a}" %>    <% end %>    DocumentRoot <%= "#{current_path}/public" %>    <%= "#{current_path}/public" %>>      Options FollowSymLinks      AllowOverride All      Order allow,deny      Allow from all    
    RewriteEngine on
    # Prevent access to .svn directories    RewriteRule ^(.*/)?\.svn/ - [F,L]    ErrorDocument 403 "Access Forbidden"
    # Check for maintenance file and redirect all requests    RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f    RewriteCond %{SCRIPT_FILENAME} !maintenance.html    RewriteRule ^.*$ /system/maintenance.html [L]
    # Deflate    AddOutputFilterByType DEFLATE text/html text/plain text/xml    BrowserMatch ^Mozilla/4 gzip-only-text/html    BrowserMatch ^Mozilla/4\.0[678] no-gzip    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
    ErrorLog <%= "#{current_path}/log/apache_error.log" %>    CustomLog <%= "#{current_path}/log/apache_access.log common" %>

Almost done with configuration but it needs to be tied into the deploy:setup task.

namespace :config do
desc "Configure new wordpress install"task :default, :roles => [:web] dowordpress.wp_config_phpapache.vhostendend
after   'deploy:setup', 'wordpress:config'before  'deploy:update_code', 'wordpress:symlinks:setup'after   'deploy:symlink', 'wordpress:symlinks:update'

My deployment setup recipes are a bit more complex, creating the database, running the wordpress install scripts and bootstrapping with some users, but this should be enough to get you going for WordPress or any other PHP CMS setups.

We now need to make sure the deployment of releases works.

Creating a WordPress Release Recipe

There are two basic options here. Capistrano allows you to release from your source control system such as SVN or Git, or alternatively you can do a copy from your local filesystem. Obviously if you are working in a team greater than one, I kinda hope you have source control.

Assuming you have checked the entire wpproject into your SVN server. You need the following in your deploy.rb file.

default_run_options[:pty] = trueset :keep_releases, 3set :use_sudo, trueset :user, "deploy"set :repository,  "svn+ssh://#{user}@madebymany.co.uk/var/svn/wpprojects/ourblog/trunk"set :deploy_to, "/var/www/apps/#{application}"set :deploy_via, :export
role :app, "madebymany.co.uk"role :web, "madebymany.co.uk"role :db,  "madebymany.co.uk", :primary => true
namespace :deploy dotask :restart, :roles => :app do# Do nothing or restart apache# apache.restartendend
after   :deploy,'deploy:cleanup'

And that’s it. The after hooks that modify the symlinks are handling the other areas of the deployment, so all we need to do is override the restart. You can get away with not restarting apache for sure but sometimes you can have APC cache issues.

To deploy your WordPress, create a database then:

cap deploy:setup  cap deploy

And you are ready to blog, when you need to make a release just cap deploy. Hopefully this is a good intro because you can use Capistrano with lots of PHP CMS’s using a similar setup.