Category Archives: drupal

Please vote for my about-me/sitemap slideshow on Slideshare!

Only 7 days left for the Slideshare World’s Best Presentation Contest, and I’d love it if y’all came out and voted for my about-me presentation–if only because I found a way to fit both Drupal and Emacs into my rhyming self-introduction! =)

It’s only one minute and 25 seconds, and it’ll probably make you smile. Plus, it’s a (mostly) working sitemap, and how cool is that? ;) The prize for this category is an iPod Touch, which (if I win it) I will promptly put to good use. After all, if I used my Nintendo DS to make a presentation, what might I do with something like the iPod Touch? ;)

Honorable mention would get me a copy of Presentation Zen book, which I liked so much I bought it already, so I’d be happy to raffle it off and keep just the warm and fuzzy feelings that my fledgling sketching and writing skills got noticed. Want it? Leave a comment on this entry (just one comment is fine), and I’ll pick a random commenter if I win the book.

In addition to either blog posts about doing interesting things with the iPod Touch or a chance at winning a free book, you’ll also get the satisfaction of supporting a geek in an area dominated by graphic designers. =) (Not that graphic designers can’t be geeks, of course.)

Anyway, please vote for my presentation! =) Voting ends on July 31, 2008.

World’s Best Presentation Contest

Kaizen: What would make our Drupal lives better?

Kaizen: relentless improvement.

We’re getting ready for the next phase of our Drupal project, and it’s a good time to think about how we can make our process better.

  • Automated builds: I have a few Makefile commands related to pushing the latest development source code to the testing server, but the other developers can’t use the commands on Microsoft Windows. However, they have access to another Linux-based server. If I can simplify the deployment process (maybe a password-protected webpage that allows you to choose which revision to deploy?), then they won’t be held up when I go on vacation.
  • Automated testing: We used simpletest for a few pieces of functionality, but we don’t have anything close to coverage. I’d like to learn how to write proper tests for Drupal so that I can avoid regression errors, which I often made during development.
  • Switching between hosts: Because we use Domain Access, I can’t just use a local domain name and a copy of the server’s database. My current approach is to use the same domain name as on the testing server, and then keep editing /etc/hosts to switch back and forth. An alternative might be to create a Makefile target that grabs the server’s database, runs it through sed to translate all the domain names to my local domain, and restores the database from this translated file. That way, I don’t need to edit /etc/hosts all the time.
  • Coding environment: I’m thinking of moving my development from Eclipse to Emacs in order to be able to customize my environment more effectively. I’ll post more notes about it as I figure out what works for me and what doesn’t. It’s a good excuse to learn even more about Emacs…

What worked well:

  • Source code control, I love you so much, even if you’re Subversion.
  • Adding a CSS person to our team meant that the other developer and I were much less stressed out about cross-browser issues. Hooray!
  • Using a defect-tracking system was infinitely better than sending e-mail around, even if that defect-tracking system was ClearQuest. ;)

Drupal: Patching simpletest for Drupal 5 to understand the Location header

Automated testing is part of good programmer hygiene. I wanted to write tests for both functions and Web-based interfaces in our Drupal project, but one of the tests I wrote was always failing. Many prints and var_debugs later, I found out that it was because simpletest didn’t do anything with Location: headers, which happen when you drupal_goto an external site. Here’s a first pass at fixing that behavior – patch sites/all/modules/simpletest/simpletest/browser.php:

Index: browser.php
--- browser.php	(revision 753)
+++ browser.php	(working copy)
@@ -321,6 +321,22 @@

+        $counter = 0;
+        $url = $this->_page->_headers->_location;
+        if ($url) {
+          $url = &new SimpleURL($url);
+        }
+        while ($url && $counter < 10) {
+          $this->_page = &$this->_fetch($url, $parameters);
+          $this->_history->recordEntry(
+            $this->_page->getUrl(),
+            $this->_page->getRequestData());
+          $url = $this->_page->_headers->_location;
+          if ($url) {
+            $url = &new SimpleURL($url);
+          }
+          $counter++;
+        }
         return $this->_page->getRaw();

(update: okay, let’s try diff syntax highlighting with wp-syntax…)

From Eclipse to Emacs: Drupal development with Subversion, tags, templates, and xdebug

Yesterday, I started working on my Drupal project in Emacs. I can’t believe I hadn’t moved to Emacs earlier. =)

I really like being able to diff a file with C-x v = (vc-diff) and check in a file with C-x v v (vc-next-action). I also like the way that svn-status (from psvn.el) lets me examine a directory tree, mark a set of files, and commit them–all without using the mouse. I probably should’ve set up keyboard shortcuts for these in Eclipse, but Eclipse made it too easy to just use the mouse. Emacs encourages you to use the keyboard, and it’s easy to customize any keyboard shortcut.

php-mode’s C-c . (php-show-arglist) works beautifully with the TAGS file that I’d set up using Exuberant Ctags, so I don’t need to do anything special in order to get function definitions. Definition functions for PHP functions would be nice. In the meantime, there’s C-c C-f (php-search-documentation).

The yasnippet template engine came in handy when I was writing test cases. I updated my module template to include the simpletest hook, added a test case template, and added a template for the simpletest hook as well. Yay dynamic templates!

And I just got Xdebug working with PhpMode and Geben… Sweet!

Development kaizen: Deployment and testing

I got back yesterday to a still-empty defect list, so I decided to spend the day working on some infrastructure to help my team work more effectively.

Thinking about what could make the most difference in the other developers’ productivity, I decided to invest time into making it easier for them to deploy code to the testing server. I had written a Makefile target that efficiently transferred only the updated files, but the other developers worked on Microsoft Windows and did not have all the necessary tools. I spent the morning writing a web-based interface for them: a password-protected PHP script that displayed a list of recent revisions and allowed people to deploy a selected revision to a separate server. Behind the scenes, it was a mess of bubblegum and string. To work around various limitations, I strung together sudo and suid and rsync and ssh key-based authentication. It wasn’t pretty, but it worked. I e-mailed instructions to my team members, and they started using it right away.

After solving that problem, I focused on improving our tests. Fixing one bug often led to creating or recreating another, and these regression errors resulted in back-and-forth communication and wasted time. I explored the Simpletest automated testing framework for Drupal, and found out that I could write both unit tests and Web-based tests using the framework. However, I had a hard time figuring out why several of my Web-based tests consistently failed. I found out that the latest version of Simpletest for Drupal 5 did not understand the Location: header, which we use extensively in order to direct people to different subdomains and external sites. I fixed it and wrote a number of tests for one of our key modules. By the time I was ready to pack up and go home, I’d gotten into the swing of writing test cases.

Easier deployment and automated testing go a long way towards making a project almost a joy to work on. I’m glad I spent some time paving the way for my team and for other projects to come. =) Kaizen: relentless improvement.

Drupal shell: quickly evaluating PHP statements in a Drupal context

I often find myself needing to variable_set something temporarily, just to try things out. The drush module provides a command-line interface that solves this problem with a little more hacking. To minimize the effect on my source tree, I’ve unpacked it into the sites directory for my local installation and enabled it in my test database. After I enabled the main drush module and the related modules, I tweaked drush_tools to include an insecure-but-useful eval command. Here it is:

--- sites/    2008-08-05 17:18:48.000000000 -0400
+++ sites/    2008-08-05 17:18:55.000000000 -0400
@@ -46,6 +46,10 @@
     'callback' => 'drush_tools_sync',
     'description' => 'Rsync the Drupal tree to/from another server using ssh'
+  $items['eval'] = array(
+    'callback' => 'drush_tools_eval',
+    'description' => 'Evaluate a command',
+  );
   return $items;
@@ -156,3 +160,6 @@
+function drush_tools_eval($command) {
+  eval($command);

I also added an alias to my ~/.bashrc along the lines of:

alias drush='php ~/drupal/sites/ -r ~/drupal -l'

where ~/drupal is my multisite Drupal directory root.

After I loaded the alias with “source ~/.bashrc”, I can now execute PHP statements in my Drupal context with commands like:

drush eval "variable_set('hello', 'world');"

Good stuff!