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.

So, Dries wants to know what our Drupal 7 battle plans are. I think this is the first version where I'll have explicit battle plans before hand rather than just "whatever I come up with along the way". :-) So, for those playing along at home, here's my goals for Drupal 7:

• Move Drupal to PDO
• Introduce a function registry
• Begin to solve the "Data API problem"
• Whatever I come up with along the way

The latest in a long line of DrupalCamps was held this weekend at the Milwaukee School of Engineering in Milwaukee, Wisconsin. It wasn't my first conference or my first BarCamp, but it was my first DrupalCamp. It was also the first event I've been at as a member of the Drupal Association, which meant it was my first event where I was supposed to actively flag for it. No one complained, so I guess I wasn't pushy enough. :-)

Although the turnout was a tenth that of the last DrupalCon, about 40 people, I have to say it was still a blast. Maybe it's just proximity, but I'd almost say it was even more fun than DrupalCon.

January 15th, a day that will live in infamy

I am generally not a very religious person, but sometimes things come together in ways that make me wonder if there is some strange and inexplicable order to the world. 15 January 2008 is one of those days, when three important things happened to me.

The first is, of course, Drupal's 7th birthday. OK, it is not specific to me, but it's still a curious irony given the restof the day.

The second is the completion of the project that got me into Drupal. The reason I use Drupal is finally complete.

And third, I got a new job. Well, sort of. I got more work. :-)

Marco Tabini, of php|architect magazine fame among other things, has been openly disappointed at the death of PHP 4. Not because he likes PHP 4, but because of the "OMG you're discontinuing something that everyone's still using!" argument.

I like your magazine, Marco, but I have to disagree with you on this one. :-)

I've just posted another "Data API What If"-style article over on http://groups.drupal.org/. I figured that was more archiveable than my personal blog, but I wager more people read Drupal Planet than a specific g.d.o group so I'm posting the link here as well in a blatant bit of self-promotion. :-)

I am also posting this over to Planet PHP, in case any other exPHPerts have words of wisdom to offer. Hi guys!

Earlier this week, the PHP team released PHP 4.4.8. Baring any major security holes between now and August 8th, it will be the last release of PHP 4. Ever.

We are also one month away from the GoPHP5 deadline, after which any new releases of almost every major PHP project will require at least PHP 5.2. If you or your web host is running an older version, you are going to run into problems.

The future is neigh. Is your server ready?

Drupal 6 introduced the concept of a theme preprocess function. In short, it allows themes, theme engines, and even modules to step into the theming process and manipulate the variables that get sent to a template. It replaces the older, clunkier _phptemplate_variables() function from Drupal 5's phptemplate templating engine, but serves much the same purpose.

While we can't backport all of that new functionality, it is possible to greatly simplify _phptemplate_variables() in Drupal 5 in a way that looks a lot like Drupal 6. Specifically, we can break up _phptemplate_variables() into separate functions that act like a theme's preprocess functions in Drupal 6.