{tech}.Ben Buckman.net

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.

Facebook formally presented its HipHop project last night. (Video below.) PHP is written in C but interpreted and runtime, and trades code simplicity for performance. So HipHop aims to convert PHP into optimized C++ "just in time" (which I think is the same as runtime), then compile that C++ and run it much faster than PHP would otherwise run. They've been running it live for six months and claim it uses 50% less CPU than the standard engine with equal traffic, and 30% less CPU with twice the traffic (compared to the Zend engine with APC opcode cache).

Most of the "magical" features supported in PHP (but not in C++) were preserved, but eval(), which allows arbitrary code to be run in the script, was removed. This means Drupal can't use HipHop, for one thing.

The optimization potential depends on "how much of your code looks like C++?" Flexible variable types, for instance, run slower than type-cast variables, so HipHop has an "inference engine" to convert to C++ variable types, gaining performance for clear types but not so much when using "variant" types.

HipHop also uses its own HTTP server, so no Apache support (yet). Tabini notes, "Of course, this doesn’t preclude you from running one or more HipHop projects against separate ports on the same machine and then use Apache (or Squid, or any other server) to reverse proxy to them."

It'll all be open source, of course: the project home is here, and code will be on GitHub "soon."

Update: Four Kitchens ponders ways Drupal could be modified to support HipHop. (The changes suggested there should probably be done regardless.) I look forward to seeing that in their Pressflow distribution.

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);  
}

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.

I had to set up a local copy of an old site running (on the server) PHP 4 and hundreds of old-school SSIs (server-side includes), of the <!--#include variety. It took a bunch of time to get it right, but in the end it's pretty simple:

Make sure mod_include is enabled in your httpd.conf.
Have this directive in your httpd.conf (it should be possible in the virtualhost or .htaccess too but doesn't work there:

<Directory />
Options Includes
</Directory>

(It's possible the Directory can be other than root (/) -- I think the key is just to put it in httpd.conf.)
Also in httpd.conf, put the directive SetOutputFilter INCLUDES.

Prior to PHP 4.6 I think, there was a configuration directive --enable-track-vars which allowed SSI variables to work PHP, or something like that, but it's deprecated and built in now, so PHP can output SSI directives.

Make sure to restart Apache after adding this, of course.

If I run into other issues with this, I'll update this post; in the meantime, it seems to be working.