The WGBH.org Development Blog

Filed by Phil at 6:10 pm under Drupal, Drupalcon, MySQL

What can beat the excitement of Drupalcon Days 1 and 2 - why, Drupalcon Day 3, of course!

I’ll spare you the coffee update today. Safe to say I was well lubed (caffeine-wise) all day. However, I do have a nice head cold now, so the mucous was flowing and I was burning through tissues at a healthy clip. Let this be a warning to all you young folks: if you’re thinking about having children someday, be aware that they’re walking germ factories and you will spend November through March sick as a dog. So, now you’ve been warned.

The first session I attended on Day 3 was SimpleTest: Because clicking on forms is for suckers. I’m certainly familiar with unit testing and had previously heard of the SimpleTest module, which is based on (and requires) the SimpleTest PHP library. But this session gave me a nicer rundown on all that SimpleTest offers, why it’s important to make use of it, and a primer on how to get started with it.

The panelists spoke of the importance of unit testing and recommended (ideally) a unit test for each if statement in your source code. They also warned against running SimpleTest on a production database (don’t do it), and mentioned the limitations of the module, namely that it doesn’t work for testing JavaScript or CSS (i.e. the visual interface).

SimpleTest is not only good for unit testing but also has an internal web browser that can be used for functionality testing (i.e. to test functionality end users will experience through a browser).

They also mentioned the new (as of Drupal 6) SimpleTest Automator module which really simplifies functionality testing by providing (essentially) a macro builder to record user actions (e.g. filling out forms, clicking on links, etc.).

SimpleTest can also be run via the command line using drush

Official Drupal SimpleTest documentation can be found here.

The panel also mentioned that unit testing is going to be added to core in Drupal 7; functional testing will remain a contributed module. The runkit php extension may be required to support all of this.

The keynote session of the day was given by Brian Aker from MySQL, speaking about, well, MySQL and what the fine ladies and gentlemen there are up to. I can sum it up in one word: scalability. Nuff said.

We broke up the day by having lunch with some new friends that we met here at Drupalcon. One was Margaret Rosas of Quiddities, who is currently working with KUSP, a public radio station in California. We also met two nice people from WXXI, a public broadcaster in Rochester, NY: Andrew Wheeland and Janele Robinson

After lunch I checked out the birds of a feather session on Solr led by Robert Douglass. This is a new approach to search on a Drupal site based on the Apache Solr search platform. Unfortunately, I came late to this session and missed a lot of the important stuff. However, having worked with Robert last year, he previously gave us a quick backgrounder on it. Solr offers the ability to have faceted search and performance improvements over core search. It also allows for indexing multiple sites or content not in your Drupal database using the Nutch crawler. Solr also supports use of synonym lists.

It looks pretty handy.

You can see Solr in action by using the search on Rob’s own site. He’s also set up a site that lets you use Solr to seach the Drupal.org site.

Rob has written a Drupal module to integrate Solr called Apache Solr. Note that this is different from the Solr Drupal module, which is an alternative implementation.

Rob also noted that one problem with current core search is that you can’t turn off content and user searching (you can only hide it). Rob has his own module, called Core Searches, which replicates the core content and user search functionality but allows you turn them off, which you may want to do if you run Solr.

Solr is also highly scalable since it is clusterable, meaning you can run as many Solr servers as you want and put a load balancer in front of it all.

Rob also noted that Netflix and Digg both run Solr. Them’s good company.

After the mid-afternoon break and deftly avoiding being included in the Drupalcon group photo (because, good lord, I don’t need photographic evidence that I ever attended a “con” of any sort) I attended my final session of the day: Creating custom workflows for Drupal applications - taking advantage of core hooks and context. The title was a bit deceiving, as it was really more about context and how it can be more efficiently identified, passed along and used by Drupal to make decisions about display or workflow.

The panelists pointed to their site Managing News as an example of how they implemented some nice context logic.

Basically, they used the same approach that the Drupal Internationalization module uses to set the display language for a site. The key here is the function custom_url_rewrite() (renamed to custom_url_rewrite_outbound() in Drupal 6). This function actually lives in settings.php, so it gets executed before Drupal starts doing it’s work on a page request.

The idea here is to prepend the (relative) URL gets with an identifier (e.g. http://www.domain.com/en/node/12345 for English sites). When a link is clicked, this information gets read and stripped out of the URLs using the custom URL function and translated to a normal Drupal URL, hence the context is set and can be used by block/menu/theme logic when the page is generated. The nice thing here is that the context identifier is removed before Drupal starts generating the page, so it doesn’t break pages that depend on URL arguments (e.g. views, panels).

The panelists used this approach to identify and set the context on page load. This is done with a custom function that sets a static variable. Another custom function can then be called by block/menu/theme logic in a simple and clean way to affect the display. This can have nice implications for workflow by allowing you to add links/tabs to pages to give users the ability to perform and action based on context. For example, on a blog entry page, display a link to add a new blog entry. Nice.

My head swimming with another day full of Drupal knowledge I called it a day and went home.

Tomorrow, the grand finale: Day 4!