Archive for the ‘Tools & Workflow’ Category

WordPress Docs 29th Apr 10

With a couple of days between projects, I had a chance to work on my latest 20% project.

RailsAPI‘s sdoc format is very nice in that it allows searching over all methods and classes, and is generally an intuitive way of doing things.

WordPress is full of PHPDoc comments, the Codex is invaluable, and of course being able to read the source is absolutely necessary much of the time. All in all, WordPress is quite well documented, though there’s really no coherent place that brings that all together. So I am very happy to have this new tool available before my next WordPress jaunt: WordPress Docs.

Migrating from Gitorious to Gitosis 12th Apr 10

Gitorious is very nice for social coding, and I thought it would be perfect for us at first. Apparently its git cloning is not quite adequate for us, as we need git pulling and git pushing and some of those cloning shouldn’t be able to write (such as deploy users).

Since we decided Gitorious wasn’t for us, we’ve just left it as it is (frequently restarting ActiveMQ and the poller, as they crash a lot). We just never had an excuse to spend the time to migrate until today when Gitorious broke completely for no apparent reason.

The process was fairly trivial, but I’ll share my code anyway as it was a somewhat interesting endeavour.

First of all then, Gitorious stores its repositories in quite an annoying way if you want to get at them outside of Rails. It stores them as some kind of hash, but split up to prevent the directories from containing trillions of entries. For instance, git@thedextrousweb.com:wordpress-plugins/wp-recaptcha is stored in /var/git/repositories/e27/004/48f5b0e17f3403aa15efd0ea8d47ce874a.git. The database then holds a mapping from the human-readable path to the actual path.

Gitosis, on the other hand, uses a mapping from wordpress-plugins/wp-recaptcha to ~/repositories/wordpress-plugins/wp-recaptcha.git, which is much more obvious.

So we need the mapping, for which we shall have to prod Rails’ database:

require File.dirname(__FILE__) + '/../config/environment'
Repository.all.each do |r|
  name = r.project.slug + '/' + r.name
  path = r.hashed_path
  puts "#{path} #{name}"
end

All that does is prints out the physical path to the repository, followed by the human-readable path, separated by a space. So redirect that to some file, and enter gitosis’ repository directory (possibly as the git user, or chown -R later). I’ll be using grep -v wiki here because we never used the wikis. So we first create the directories because git won’t mkdir -p:

grep -v wiki files | cut -d' ' -f2 | cut -d/ -f1 | sort | uniq | xargs mkdir

And rather than using cp -R or rsync, I thought it would be best to let git do the job:

grep -v wiki files | perl -pe 's/ /.git /;s/^/git clone --mirror \/var\/git\/repositories\//;s/$/.git/' | sh

Since we’ve only got a few users, we’re not going to bother importing all the users and groups, so we can just cut the list of repositories, remove the newlines, and append it to our writeable.

Testing WordPress with Cucumber 19th Nov 09

I should probably introduce myself first: I’m Tom, Dextrous Web employee #1.

We do quite a bit of work with WordPress, and one of the problems we’ve found is that it doesn’t lend itself to the kind of automated testing that we do with the rest of our projects. The code for themes easily gets pretty cluttered, and it’s hard to know what the consequences of installing a WordPress upgrade or new plugin might be.

One of the tools that we use for our Ruby on Rails projects is Cucumber, a Behaviour Driven Development tool that makes front-end testing of Rails applications really easy. There’s an example below, but in brief: it lets you write human-readable tests and then run them on your application to make sure it’s working properly. Because Cucumber tests the front-ends of web applications, it’s not tied to any one technology — so we thought, why not use it to test WordPress?

So I spent some time writing a little bit of configuration magicks and step definitions, and here it is: cucumber-wordpress.

To get started you’ll want to install the gem:

gem install cucumber-wordpress --source http://gemcutter.org

Then copy the example features directory from the gem into the root of a WordPress installation:

cp -R /usr/lib/ruby/gems/1.8/gems/cucumber-wordpress-1.0/examples/features .

Configure your test database, and where the site is being served from:

vim features/support/config.yml

And test:

cucumber

Here’s a sample:

Background:
    Given WordPress is installed
 
  Scenario: Submitting a post
    Given I am logged in as "admin"
    And I am on admin dashboard
    When I follow "Add New" within "#menu-posts"
    And I fill in "title" with "I <3 cucumber"
    ...

I’ve been testing a plugin with this for a week now, and it’s been very smooth.

Here at The Dextrous Web we’re committed to backporting the Rails culture to WordPress.

Categories

Recommended reading

  • A selection of interesting links. Refresh to see more
  • Public Strategist Thoughts and discussions on strategy from a large central government department
  • Jenny Brown She helps government talk to real people: she’s on the coal face of digital engagement.
  • Cabinet Office Digital Engagement Digital engagement, from the heart of government
More »