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:
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!
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. :-)
One of PHP 5's coolest features is the Standard PHP Library, or SPL. If you're operating in an OO way, SPL is a great way to easily leverage a huge amount of functionality.
Of course, the main problem is that the official documentation on it sucks. At best it points to an off-site series of class hierarchies. (Technically it's not off-site, but not internal to the manual.)