As Drupal gets bigger and bigger in the marketplace, it is moving into areas where system administrators still hold sway. Dedicated servers or server farms have a different set of needs than a shared host when it comes to monitoring and performance.
That's not even Drupal specific. For any high-end web app, it's useful to be able to interact with it for administrative purposes through standard system tools. On Windows, that's the Windows Administrative Tools or IIS. On LAMP, that could be a unified web app like webmin or a KDE control panel plugin or a Gnome applet. Getting a web app into certain organizations requires offering existing sysadmins a way to integrate it into their existing management workflow.
But what pieces of the app do sysadmins want in their existing admin tools? Calling all sysadmins, what do you want from us? :-)
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.
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.
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. :-)
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?
A ran across this article recently making the rounds. In it, the author discusses spending 2 years in Ruby on Rails land before finally giving up and coming home to PHP, wiser for the experience. It's a good article, but one thing in it really raised the hair on my neck.
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?
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.
"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.