{tech}.Ben Buckman.net

BostonPHP hosted a PHP Framework Bake-Off last night, a competition among four application frameworks: CakePHP, Symfony, Zend, and CodeIgniter. A developer coding in each framework was given 30 minutes to build a simple job-posting app (wireframes publicized the day before) in front of a live audience.

I asked the organizer if I could enter the competition representing Drupal. He replied that Drupal was a Content Management System, not a framework, so it should compete against Wordpress and Joomla, not the above four. My opinion on the matter was and remains as follows:

1. The differences between frameworks and robust CMSs are not well defined, and Drupal straddles the line between them.
2. The test of whether a toolkit is a framework is whether the following question yields an affirmative answer: “Can I use this toolkit to build a given application?” Here Drupal clearly does, and for apps far more advanced that this one.
3. The exclusion reflects a kind of coder-purist snobbery ("it's not a framework if you build any of it in a UI") and lack of knowledge about Drupal's underlying code framework.
4. In a fair fight, Drupal would either beat Wordpress hands-down building a complex app (because its APIs are far more robust) or fail to show its true colors with a simple blog-style site that better suits WP.

Needless to say, I wasn't organizing the event, so Drupal was not included.

So I entered Drupal into the competition anyway. While the first developer (using CakePHP) coded for 30 minutes on the big screen, I built the app in my chair from the back of the auditorium, starting with a clean Drupal 6 installation, recording my screen. Below is that recording, with narration added afterwards. (Glance at the app wireframes first to understand the task.)

Worth noting:

• I used Drupal 6 because I know it best; if this were a production app, I would be using the newly released Drupal 7.
• I start, as you can see, with an empty directory on a Linux server and an Apache virtualhost already defined.
• I build a small custom module at the end just to show that code is obviously involved at anything beyond the basic level, but most of the setup is done in the UI.

One irony of the framework-vs-CMS argument is that what makes these frameworks appealing is precisely the automated helpers - be it scaffolding in Symfony, baking in CakePHP, raking in Rails, etc - that all reduce the need for wheel-reinventing manual coding. After the tools do their thing, the frameworks require code, and Drupal requires (at the basic level) visual component building (followed, of course, by code as the app gets more custom/complex). Why is one approach more "framework"-y or app-y than the other? If I build a complex app in Drupal, and my time spent writing custom code outweighs the UI work (as it usually does), does that change the nature of the framework?

Where the CMS nature of Drupal hits a wall in my view is in building apps that aren't compatible with Drupal's basic assumptions. It assumes the basic unit - a piece of "content" called a "node" - should have a title, body, author, and date, for example. If that most basic schema doesn't fit what you're trying to build, then you probably don't want to use Drupal. But for many apps, it fits well enough, so Drupal deserves a spot on the list of application frameworks, to be weighed for its pros and cons on each project just like the rest.

Technosophos has a great tutorial on setting up a PHP debugging environment with XDebug and MAMP. I'm using XAMPP and it works the same way, just change the path where xdebug.so goes.

However, the Textmate part - using the xdebug.file_link_format parameter - doesn't seem to be working. Apparently others are having the same problem, possibly Snow Leopard-related, not sure if there's a solution. It's not necessary for the debugger to work, however, just a convenient way to view the error-causing code.

This StackOverflow question about path traversal prompted me to see how easy it is.

All it takes is a PHP file like this on your server:

<?php
// explore path traversal vulnerabilities
ini_set('display_errors', 'on');
ini_set('error_reporting', E_ALL);
 
$path = isset($_GET['path']) ? $_GET['path'] : '';
 
  if (empty($path)) {
    echo "No path.";
    die;
  }
 
echo $path . '<br/>' . realpath($path) . '<hr/>';
 
if (is_dir($path)) {
  echo '<pre>' . print_r(scandir($path),true) . '</pre>';
}
else {
  $file = file_get_contents($path);
  echo htmlspecialchars($file);  
}

... and someone can gain total read access to your file system. Run that script with ?path=../../etc/passwd, for example, and the system's user list is printed straight to the screen. (Because most Unix systems set --4 [all-read] permissions by default on system files.) (So DO NOT put that code on your server!

Of course, that exact code would never be used, but there are all kinds of other scenarios where user-submitted parameters or cookies are passed through to the file system. That's one of the advantages of working in a framework (vs coding an app from scratch) - all these considerations have (presumably) been taken into account, and the API (if used correctly) should handle it. But it just reminds me how critical it is to escape all characters, never pass through form values directly, never load files based on unfiltered user input, etc etc... Apache's access directives are useless once the script is running server-side.