One of the numerous projects I’ve been juggling over the past few months has been a redesign of the Greenbelt Festival website. That redesign went live late last night.

Working from Wilf’s designs I initially built new HTML and CSS templates and began to establish some rules for how we’d handle the new image management requirements for a site that is now very photo-heavy. When it came time to apply the new designs to the CMS, however, it became apparent that there was a much bigger job ahead.

That CMS (a bundle of custom PHP that I had inherited) has grown over time and within some quite onerous server configuration constraints to a point where it was due a significant overhaul. Sticking with PHP was a fixed requirement as we’re relying on various APIs and a server architecture that wouldn’t be happy with me shifting to, say, rails, but already having the problem domain mapped out and the opportunity to radically simplify a few things meant I got to enjoy the feeling of stripping out a lot of code without impairing functionality.

One note that Derek Sivers made in his controversial blog entry last year about switching from Rails to PHP was that working with Rails had made him a better PHP developer. I’ve found a similar effect. I have no intention of leaving the world of Rails (I still prefer it by orders of magnitude), but tackling projects like this in PHP are a reminder that working for a while with really good tools is likely to encourage you to seek out best practice in whatever environment you end up in.

Ruby developers who occasionally work on PHP projects as I do may be interested to note that we are using capistrano for deployment, and I intend to use rspec for some testing. I’ll try to write that up once it’s in place.

With a refreshed CMS, new templates, and some standardisation of our many javascript files on top of a jquery foundation, Paul, Greenbelt’s was able to manage the photos and copy to turn that new look into a vibrant and content-rich new site. You can see a few notes he wrote about the redesign on the site.

There’s still a fair way to go. I’ve got a lot of tests to write in order to make it easier for us to make further changes, and various aspects of the site are more than ready for a more fundamental rethink that will let the festival open up its archives better, but all concerned are very pleased to present the fruit of our labours.

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: