It’s surprising given drupal’s popularity that there aren’t more books covering it in detail. Site launches and contributions by the likes of lullabot and bryght have pushed the CMS’ profile and recent releases have emphasised the Web 2.0 potential, but a quick look at amazon reveals only four related titles. Of the four, Pro Drupal Development is definitely the most developer focussed.

This isn’t a book for a drupal newbie. Going in you’ll want to have spent at least a little time setting up a drupal site or two, and while there’s no need to be a PHP guru the authors do presume you’re not going to need help understanding their code samples. They focus on drupal’s internals, with a lot of time spent writing modules, understanding the user, node, menu, theme and related systems, and a little attention for performance optimisation.

There’s a lot of ground to cover and most chapters are short, giving just the essentials on each area. You’ll probably want to pause from time to time to try out the code samples unless you’re already experienced at writing drupal modules. Having written a number of modules and run into various problems I found I was able to focus on the new information and how it would have affected my approach, but if this is new ground the structure of the book may make it rather overwhelming.

The writers are keen to encourage their readers to read the book in order, and some chapters certainly do build on their predecessors, but the real strength of this is likely to be as a reference guide. A quick once-through will help newcomers to module development get a sense of how everything fits together, but chances are you’ll then want to refer back when you actually encounter problems that a given chapter can help with.

I was disappointed not to see more coverage of testing drupal code. As I mentioned yesterday, the lack of attention paid to automated testing in the drupal community frustrates me and it seems that for a book like this to not to provide some coverage of sensible testing regimens is a missed opportunity. Similarly, it would be really good to have some coverage of deployment tips, particularly relating to upgrading active sites. Both of those seem to me like core topics for any book purporting to provide a guide for professionals, but the priorities of the book mirror those of the drupal community where neither topic appears to be a significant concern.

For any experienced developer who needs to get to grips with the insides of drupal and/or write custom extensions, this book will be invaluable. The style won’t suit those looking for a broader scope or lengthier tutorials, but it will help you get to grips with each of the major components quickly and provide enough information to set you on your way. Hopefully it will also trigger further writing about drupal, which may cover more ground and help developers bring some other vital practices to their drupal work.

Disclaimer: I was sent a copy of this book for review by the publisher. You can find it at apress, amazon US, amazon UK and all sorts of other places.

Recommend this post:

There’s one project I work on where the client wants to be able to edit HTML files in the root folder, but I want to be able to deploy with capistrano. It’s a pain to have to log into the server and check whether those files have changed before each deployment so last night, I added the following to my deploy.rb:

desc "Make sure we don't overwrite manual static file changes"
task :before_deploy do
  captured = false
 
  run "svn status #{deploy_to}/current/public" do |ch, stream, data|
    if stream == :out and data.chomp.match(/^M/)
      captured = true 
    end
  end
 
  if captured
    run "svn commit #{deploy_to}/current/public -m 'Storing manual changes to static HTML before deploy'"
  end
end

It’s not the most elegant, but it’ll make sure that any files the client has changed (which were already in the repository) are committed, and it makes the deployment process just that little bit easier.

(thanks to Jonathan Weiss for a recent blog entry that reminded me to implement this.)

Recommend this post:

I had an email the other day asking about my experiences with a particular shared hosting company (not dreamhost). I’ve worked my way through a few companies for smaller projects, and thought I’d throw some thoughts out there.

Dreamhost are one of the cheaper hosting outfits around, and seem to inspire either love or hate, depending on your experiences. Their setup for rails is apache+fcgi, which isn’t the optimal configuration, but works well enough for a low-demand application or one where a lot of content can be cached.

Initially, I had a number of problems with which server I was placed on. One was too stretched and my subversion processes were killed before I could even finish checking out my app. Another didn’t handle a combination of subversion and fastcgi properly. And another wasn’t killing off fastcgi processes at the right time, so the app was quickly spiralling out of control. It took quite a while to get all that sorted out, and support responses were often slow, but since I’ve landed on the current server it seems fairly stable.

The one ongoing problem I’ve had is that it can be hard to manually kill processes, and deploying a new version, particularly when switching from development to production, can be a painful process as you wait for the old processes to die and the new ones take their place. That’s not necessarily a huge problem, but does crimp my style when I want to get into an agile, rapid-deployment, continuous integration flow.

Overall, I’d have to say that dreamhost may be good for hobbyist sites, but if you think you’re going to attract significant traffic it’s probably worth paying for a more appropriate environment.

Recommend this post:

UPDATE: This post was written using Capistrano 1, which has since been superseded. An updated version—covering deployment of Drupal with Capistrano 2—can be found here.

It’s easy to get spoiled building rails apps. Tools like migrations make it so much easier to keep databases in sync, the way environments are managed helps considerably, and there’s Capistrano which makes rapid deployments a breeze. I miss those things when I have to work with other systems.

A few months back there had been a brief conversation about using capistrano with drupal and there are several blog posts (like this one) about using it with PHP. So today, tired of resolving folders full of uploaded files, I decided to write a quick deploy.rb to use capistrano with drupal.

I’m presuming here that we already have capistrano installed locally, that a recent version of drupal is set up on the server, and that we’re deploying to the sites folder. Within that we’re going to end up with capistrano’s standard ‘releases’ and ’shared’ folders, but in this case ‘current’ will actually take on the domain name of our app and shared will contain ‘files’ rather than the usual system, log and pids.

So here’s how it goes. Firstly we want to define some variables

set :application, "MyApp"
set :site_name, "www.example.com"
set :svn_user, "james.stewart"
 
# I like to have capistrano prompt me for the password.
# You can replace this with a standard assignment
set :svn_password, Proc.new { Capistrano::CLI.password_prompt("SVN Password for #{svn_user}: ") }
 
set :deploy_to, "/home/mp_app/public_html/sites"
role :web, "www.example.com"

So far, so much like a regular deploy.rb file. But if we want the app’s folder within sites to be called something other than ‘current’, we’ll need to add:

set :current_path, "#{deploy_to}/#{site_name}"

So that’s our configuration taken care of. Next we need to override a few of capistrano’s default tasks since we probably won’t be wanting to restart lighttpd/fastcgi, or change the permissions:

task :set_permissions, :except => { :no_release => true } do
  # do nothing
end
 
task :restart do
 # do nothing 
end
 
task :deploy do
  update
  # restart
end

And finally we want to update the setup and update_code tasks to make use of our altered directory structure.

desc < <-DESC
Update all servers with the latest release of the source code. All this does
is do a checkout (as defined by the selected scm module).
DESC
task :update_code, :except => { :no_release => true } do
  on_rollback { delete release_path, :recursive => true }
 
  source.checkout(self)
 
  set_permissions
 
  run < <-CMD
    rm -rf #{release_path}/files
    ln -nfs #{shared_path}/files #{release_path}/files
  CMD
 
  # uncache the list of releases, so that the next time it is called it will
  # include the newly released path.
  @releases = nil
end
 
desc "Set up the expected application directory structure on all boxes"
task :setup, :except => { :no_release => true } do
  run < <-CMD
    umask 02 &&
    mkdir -p #{deploy_to} #{releases_path} #{shared_path} #{shared_path}/files
  CMD
end

Now we can save this file somewhere appropriate and deploy new versions as simply as:

% cap -f /my/path/deploy.rb deploy

People using one sites folder to run multiple applications may need to make some further alterations so their ’shared’ and ‘releases’ folders don’t clash, but I’ll leave those as an exercise for the comments or related blog entries!

Recommend this post: