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 technology consultancy 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 do
namespace :symlinks do

desc “Setup application symlinks in the public”
task :setup, :roles => [:web] do
if app_symlinks
app_symlinks.each { |link| run “mkdir -p #{shared_path}/public/#{link}” }
end
end

desc “Link public directories to shared location.”
task :update, :roles => [:web] do
if app_symlinks
app_symlinks.each { |link| run “ln -nfs #{shared_path}/public/#{link} #{current_path}/public/#{link}” }
end
send(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”)
end
end
end

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] do
file = 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 => 0444
end

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 Manager
define('DB_NAME', '<%=wp_db_name%>');    // The name of the database
define('DB_USER', '<%=wp_db_user%>');     // Your MySQL username
define('DB_PASSWORD', '<%=wp_db_password%>'); // ...and password
define('DB_HOST', '<%=wp_db_host%>');    // 99% chance you won't need to change this value
define('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] do
set :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_aliases
set :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 => 0444
send(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 do
sudo “#{apache_ctl} start”
end

desc “Restart Apache ”
task :restart, :roles => :web do
sudo “#{apache_ctl} restart”
end

desc “Stop Apache ”
task :stop, :roles => :web do
sudo “#{apache_ctl} stop”
end
end

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] do
wordpress.wp_config_php
apache.vhost
end
end

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] = true
set :keep_releases, 3
set :use_sudo, true
set :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 do
task :restart, :roles => :app do
# Do nothing or restart apache
# apache.restart
end
end

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.