There has been some discussion recently, in IRC, issue queues, and blogs, about the Drupal 7 database API and its impact on supporting different database engines. While I am still trying to avoid large amounts of public distraction, especially when we're supposed to be trying to get a Drupal 6 beta 1 out the door, I feel it's important to get a few points cleared up lest they lead to confusion later.

Just a quick note in case you're one of those people who reads Drupal Planet but doesn't check drupal.org's front page daily (like, you know, me), there will be an IRC session to coordinate housing and transportation (and possibly parties) on 29 August 2007 at 7 pm GMT +1 in #Drupalcon on Freenode. I'm planning to be there, and if you don't have firm plans for everything you're doing for DrupalCon Barcelona yet, you should be too! (Be sure to check your timezone offset.)

PHP is, conceptually, a very traditional language. By that I mean that it is steeped in the C/C++/Java mindset of how a program is put together, rather than the LISP/Javascript/Ruby/Python mindset. That's not a bad thing, necessarily, but it does mean that a lot of the cool dynamic language capabilities in those languages isn't really available to PHP developers. I freely admit to being jealous of functions as first-class objects, for instance.

PHP 5, however does include lots of "magic" capabilities, some in the object model directly and some via SPL Interfaces, that, if used properly, can make up for a lot of that lack of dynamic capaibility. A favorite of mine is the ability to add methods to a class at runtime.

What? You didn't know PHP can do that? Well, that's because it can't. However, we can simulate it pretty closely if we're careful. Let's see how.

Are you tired of hearing me talk yet? If not, why not come work for Palantir.net? We're looking for a PHP/Drupal programmer and a web developer/themer. Benefits include a full time position at a small business in Chicago, working on sites for higher education, not-for-profits, and other non-evil clients, a company issue Nerf gun, and access to the company Wii. And getting to work with Larry! Who could ask for a better job?

The Drupal development list has been sharing Drupal development server setup secrets lately (try saying that five times fast), so I figured I'd toss mine out there. And since knowing me it wouldn't be short, I figured I'd blog it instead of just posting it in email. :-) Here, then, is the development environment we've set up for Palantir.net.

I've been talking up some evil plans I have for Drupal's database system in Drupal 7 lately, without going into a great deal of detail. For the most part, I've been trying to avoid distracting people, myself included, from the considerable work still remaining on Drupal 6. However, there has been recent work and discussion of making post-freeze changes to Drupal 6's database system, and even backporting them to Drupal 5. Those changes revolve mostly around database replication, which Drupal currently doesn't support in any meaningful way. That becomes important, though, on very heavy sites like, say, I don't know, Drupal.org. :-)

Those changes, though, impact the API changes we can make in Drupal 7. (OK technically they don't, since we change APIs all the time, but if we can set things up so as to minimize API changes over time that does make life easier for everyone.) For that reason, at Dries suggestion, I'm going to try and lay out now a skeleton of what I'm planning for Drupal 7's database system and how we can start adding replication support to Drupal 6 in a way that flows into it.

What a week it's been! Eight days ago, we launched GoPHP5.org to try and break the stalemate that kept PHP 4 on past its sell-by date. At launch, we had a half-dozen projects and about 10 hosts that had signed up.

What a difference a week makes.

Lullabot's Jeff Eaton has been talking about "Glue Code" lately; that's the extra little bit of code you write to make module A talk to module B to add that last little bit to that View you setup with that CCK-based node to make it just right. He's started spinning some of it off into modules, like Top Node, and asked for other people's favorite glue. Here's mine. :-)

"Never believe that a few caring people can't change the world. For, indeed, that's all who ever have." --Margaret Mead

A while back, various people were lamenting the state of PHP 5 adoption, myself included. What to do about it? How to get hosts to let programmers leverage the added functionality that PHP 5 offers? How can we do that without cutting off 80% of our user base?

The solution a few people suggested was team work. If all PHP projects stopped supporting PHP 4 and made the jump to PHP 5 at the same time, none of them is penalized in the market for being "first" and web hosts will have a clear business case to upgrade their systems to PHP 5. We can then all start offering faster, cleaner, more powerful, more secure web software.

But how does one get all PHP projects together to agree on something like that? Actually, it's fairly simple. You ask them.