I have several websites installed in subdirectories on my Mac laptop at /Users/davidnorman/Sites where I pointed the OS-included installation of Apache to use as my DocumentRoot. This weekend, I switched one of the sites installed in a subdirectory to use the root of my DocumentRoot as the source of the "File system path" setting at admin/settings/file-system.

Since the private setting, outside the expected installation of Drupal is supposed to be able to support writing files, I had to chmod my DocumentRoot directory as 777 to get the setting to save, even though I just wanted to read some files there, not write. Note: Though I did not do it recursively, chmodding the root of your web tree as 777 is is a BAD thing in most circumstances.

After setting the private file system path in the subdirectory Drupal 6 install, none of the PHP scripts anywhere in my DocumentRoot worked anymore. The chmod wasn't the problem though. One of the reasons the file system path has to be writable is that Drupal adds a .htaccess file to that directory which effectively disables script execution for security's sake.

The result in the Apache /var/log/apache2/error_log was simply a mysterious, unhelpful bit:

[Sat Jan 08 21:08:16 2011] [error] [client 127.0.0.1] Attempt to serve directory: /Users/davidnorman/Sites/

That is the error I would get regardless of whether I tried to load http://localhost/, http://localhost/phpinfo.php, or http://localhost/drupalinstallation/.

The solution: Remove the .htaccess file that Drupal automatically added at /Users/davidnorman/Sites/.htaccess. Also, pick a different subdirectory, other than the web root for private files in your subdirectory installs of Drupal.

Let this serve as a reminder that chmodding your web directory, even in your sandbox, to 777 is a bad idea, and that the root of your web tree is not a good dumping ground for private file system path settings on subdirectory Drupal installations.

I wasn't able to get xdebug or Zend Debugger to work on my install of Mac OS 10.5 Leopard after trying the XTools version of PHP5 that now comes with the operating system, so I broke down and compiled PHP5 from scratch thinking it would make life easier in the end and finally get support for an mcrypt project I have on the todo list. I suspect it has to do with Leopard introducing 64 bit XTools software whereas xdebug and Zend Debugger were compiled for a 32 bit environment.

First, you should install XTools from the Leopard DVD and this installation process will just replace the Apache and PHP5 files that XTools installs and leave all the other configuration needed to get it to work in place.

The problem was when I loaded Apache, I couldn't connect. Console told me

httpd: Syntax error on line 114 of /private/etc/apache2/httpd.conf: Cannot load /usr/libexec/apache2/libphp5.so into server: dlopen(/usr/libexec/apache2/libphp5.so, 10): no suitable image found. Did find:\n\t/usr/libexec/apache2/libphp5.so: mach-o, but wrong architecture

Apparently this is because the custom compile I did is 32 bit and the new pre-packaged Apache is 64 bit, so I recompiled Apache, too.

I grabbed a source snapshot of PHP 5.2.6 from php.net. This configure line made a successful compile of PHP 5.2.6 with various extensions for linking to MySQL 5.1.22.

The MySQL config comes from installing the MySQL 5.1.22 official binaries to /usr/local/mysql.

Of course later, I realized Drupal 6 status page complains if GD isn't installed, so I found http://www.veola.net/macintosh/adding-gd-library-for-mac-os-x-leopard which even has the instructions on making GD a PHP extension so I didn't have to recompile all of PHP5. I used a more updated version of libpng because the one in the instructions didn't compile.