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.

The day is nearly upon us! Drupal 7 will open up developers to PHP 5 functionality when it is released next year. Already, there is talk of how, and if, to leverage PHP 5's object handling now that we don't need to deal with the weirdness of PHP 4's object model. Of course, because it's Drupal, our army of performance czars want to know just what the cost is for object handling, and especially advanced object magic like __get(), __call(), the ArrayAccess interface, and so forth.

So let's find out. :-)