By now you may have heard the news from Paris that a unit testing framework has landed in Drupal core. A huge shout-out goes to everyone involved. I particularly want to note the work that's been put in by former GHOP students and members of the GHOP team. It's amazing to see how far some people have come in a short time, despite still having homework to do. :-)
The next step, of course, is to make Drupal itself fully-tested. That poses a number of challenges, particularly for unit tests. Because I'm sure others will be singing the (well-deserved) praises of the testing team, I want to take a moment to focus on that next step and one important approach: Testable APIs.
I recently had a discussion with Peter Wolanin about pluggable subsystems. (You can tell this is going to be an exciting entry already, can't you?) Drupal has supported a few pluggable subsystems for a long time, namely the database and cache systems. In both cases, they work on a very simple principle: Conditionally include one of two (or more) files that defines the same set of functions but with different bodies.
That's all well and good and simple, but has some very serious limitations. Most notably, because the same function name is defined twice you can never load multiple versions at the same time. That becomes a problem if you want to, say, connect to a MySQL and PostgreSQL database in the same page request. In addition, Drupal 7 is on track to include a fully introspective code registry for conditional code loading, which, based on earlier benchmarks, should be a huge performance boost. The Registry, however, assumes that all code resources (functions, classes, and interfaces) are globally unique throughout Drupal. Having a given function name defined twice will confuse the poor thing.
That is not an insurmountable problem, or even, truth be told, a difficult one. It simply requires switching from a simple include to a more formal mechanism. There are, in fact, several ways that can be done, so to further the education of the world at large (and probably embarrass myself a bit in front of other architecture buffs) I decided to write a brief survey of simple pluggable mechanisms.
I've been meaning to upgrade the Akismet module on this site for a while now. Of course, I waited so long that another option just appeared, one I've been waiting to see for a while: Mollom.
The other other project from apparent insomniac Dries Buytaert, Mollom is a content filtering service similar to Akismet. I've actually been familiar with it for a long time, as the GoPHP5 project has been running a Mollom private beta since last June. In fact, when Acquia was announced my first thought was "wait, what happened to Mollom?"
A recent thread on the Drupal documentation list has brought up once again the "why don't we have a wiki on Drupal.org?" question. It comes up regularly; you can set your watch by it.
What I've never understood is why anyone would want to take a step backwards from Drupal's handbooks to a simple wiki. How would removing features and capabilities help Drupal's huge pool of documentation?
What exactly makes something "a wiki"? Let's examine:
One of the major changes in Drupal 6 (where "major" is defined as "worthy of a mention in Dries' keynote") was a new feature of the menu and theme hooks. The newly introduced "file" and "file path" keys in those hooks' respective retun arrays. allow them to define files that get included conditionally, only when needed. In theory, that should be a big performance boost; page handlers are virtually never called except for on the page they handle, so loading all of that code on every other page is a waste of CPU cycles. Of course, there is also the added cost of the extra disk hit to load that one extra file we need. Modern operating systems should do a pretty good job of caching the file load, but that may vary with the configuration.
So just how much benefit did we get from two dozen fragile patches that were a glorified cut and paste? And is it worth doing more of it? Let's benchmark it and find out.
So I am finally back from Boston, and have slept off the jetlag and DST change, so I can finally get caught up on writing about Drupal's latest foray into the world of conventions. Sadly I had trouble with the wireless at my hotel as well as at the convention center, so writing anything up before now wasn't really feasible. Drat.
I was actually a bit disapppointed at this DrupalCon; so many amazing talks, and I only managed to see a quarter of them! Hopefully the videos will be online soon, so I'll be able to see what I missed.
I also had an entourage this time. Three of us from Palantir were in Boston; myself, George DeMet, and Tiffany Farriss. We arrived Sunday, the day before the conference. What is a bunch of geeks to do right before a major conference? Eat, of course!
DrupalCon Boston is only one week away! Are you excited yet? I am, and so are 799 other people. We've filled the conference center and sold out the conference at 800 people. Yikes! I won't be able to shake hands with more than a third of you. :-)
I have a fairly light schedule this time around, at least on the presenter side.
The new database system for Drupal 7 that I've been talking about for the past few months is nearly ready for submission. With chx's visit to Chicago we were able to refactor it for far better modularity and cleanliness. As of yesterday, the system is able to navigate around Drupal, submit forms, create and edit nodes, and view the insanely heavy modules admin page. I still need to make it work with the installer, but it's looking very promising. A very recent copy of the new code base, pre-Drupal-integration, is available in my sandbox.
Here's a brief list of the features it offers:
For those who haven't really been following it, several hundred contributors, 13 months, and tens of thousands of lines of code have gone into making the only version of Drupal ever that is better than Drupal 5. So, naturally, we've released it and called it Drupal 6.
Drupal 6 boasts a boat load of new functionality, ranging from Ajaxy yumminess throughout the system to native support for OpenID to vastly enhanced multi-lingual support. Several entire subsystems have been either overhauled or totally rewritten to proivde more power, flexibility, and speed. The official press release has the complete rundown, or for the more visually inclined there's a new features screencast. For me, though, the new theming system is feature numero uno.
For those who may not have noticed it, it looks like Drupal 7 is going to require not only PHP 5.2, but MySQL 5.0 as well. It makes sense to do. Drupal 7 won't actually ship for another year, by which point MySQL 4.1 will be on life support anyway. It will also lose all support during the Drupal 7 life cycle. So if you're planning a new server, get ahead of the curve and Go MySQL 5! :-)
Drupal 7: The version that gets over the 20th century.