There are few companies doing exciting things with hardware. Back in the golden era of computing (or was it the bronze age?) everyone would look to Applied Engineering, thinking "What will they think of next?"

A current company that fits that mold is WiebeTech.

This has bitten me enough that I'm going to write a blog post about it so when I search for this issue, I will find my own blog post and say, "Duh!"

Recently we had one site in development that presented a white screen whenever a form was submitted. Other sites right next to it worked fine. The form was being processed. But no errors were appearing either on the screen or in the error log for Apache or PHP -- all we saw was a blank page.

Then I noticed that the output_buffering setting in php.ini was set to Off. I turned it on and it solved the problem. But I wanted to know why it solved the problem. Here's why, and why it doesn't really solve the problem.

When Drupal's form handler completes processing of a form submission, it normally does a 302 redirect. The code responsible for that is in drupal_goto() and looks like this:

Running the code through a debugger showed that indeed, we were reaching the exit() call.

If any of your code has sent anything back to the browser, PHP has already sent the headers to the browser. If output_buffering is Off, Drupal cannot take that back and say no, really we meant to send you a 302. But if output buffering is on, the headers are not really sent, so calling header() still works. That's why turning on output buffering solves the problem.

But that's just treating the symptom. The real problem is that somewhere in your code, something is being sent back to the browser when it shouldn't be. This is the problem being referred to when the Drupal coding standards say, Note that the final ?> should be omitted from all code files--modules, includes, etc. The closing delimiter is optional, and removing it helps prevent unwanted white space at the end of files which can cause problems elsewhere in the system.

In my case, a designer had put a drupal_add_js(..., 'inline') call directly into template.php. Moving the JavaScript to a .js file solved the real problem.

I thought I'd write up the steps I took to get Drupal running on a stock Leopard installation. You may wish to save some time and install MAMP instead. Especially if you need GD support (i.e., you're going to have Drupal do image resizing). Update 17-Dec-2007: In fact, I recommend using MAMP instead.

Step 1: Enable PHP

Uncomment line 114 in /etc/apache2/httpd.conf to enable Leopard's built-in PHP:

LoadModule php5_module        libexec/apache2/libphp5.so

Start Apache 2 by using the Sharing panel in Preferences or at the command line with the following:

sudo apachectl start

(If Apache was already running, use restart instead of start.)

Place a test document into the default htdocs root to see if php is running. I created /Library/WebServer/Documents/phpinfo.php with the following content:

<?php phpinfo(); ?>

Now going to http://localhost/phpinfo.php shows me the info page for PHP 5.2.4. Yay!

Step 2: Friendly Virtual Hosts in Apache

I don't like keeping my websites in /Library/WebServer/Documents. It's a cumbersome place; I'd much rather keep them in /Users/john/Sites. That's right in my home directory and when I copy or sync my home directory I get the sites I'm working on, too. But using Leopard's built-in URL support for my home directory is verbose, too:

http://localhost/~john/sitename

I'd much rather use a nice short URL like http://dev/sitename. So first I assigned the name dev to my computer by adding a line to /etc/hosts:

Since Leopard caches DNS queries, we force it to reread /etc/hosts by using dscacheutil which replaces the lookupd utility that was in OS X 10.4.

dscacheutil -flushcache

I changed /etc/apache2/users/john.conf from

to

You can test that everything works and you didn't make any typos by using

sudo apachectl configtest

which should tell you that the syntax of your Apache configuration files is OK (it will point you to the line containing the error otherwise). If all is OK, restart Apache to effect the changes:

sudo apachectl restart

Now you should be able to go to http://dev/ in your browser, and the file at /Users/john/Sites/index.html should be displayed.

Installing MySQL

There was no friendly installer for OS X 10.5 so I used the OS X package for 10.4. It ran fine.

It was unclear from my web searches whether the startup item for MySQL is working on Leopard. So I created the following file at /Library/LaunchDaemons/com.mysql.mysqld.plist to autostart MySQL (thanks Joannou Ng):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>KeepAlive</key>
	<true/>
	<key>Label</key>
	<string>com.mysql.mysqld</string>
	<key>Program</key>
	<string>/usr/local/mysql/bin/mysqld_safe</string>
	<key>RunAtLoad</key>
	<true/>
</dict>
</plist>

Before I restarted, I wanted to make sure that mysql would be in my PATH environment variable when I restart. So I created a file at /etc/paths.d/mysql containing

For more information on this, type man path_helper.

Then I restarted to make sure that MySQL would launch. Yes, it's running:

Now to set it up securely.

mysql_secure_installation

This allows you to set a root password, disallow remote root logins, and generally tighten up MySQL security.

It's nice to be able to tweak MySQL parameters, so I created a my.cnf file:

sudo cp /usr/local/mysql/support-files/my-large.cnf /etc/my.cnf

The only thing I tweaked in the my.cnf file was to add one line under the [mysqld] heading to prevent MySQL from listening on port 3306 (I don't like unnecessary open ports):

skip-networking

Now I can create a database for Drupal to use:

One more thing. PHP and MySQL are confused about which socket to use (/tmp/mysql.sock vs. /var/mysql/mysql.sock). So let's provide a symlink so they can use either one:

Installing Drupal

Pull down a copy of Drupal 5 from the CVS repository:

Change permissions on the settings file so the installer can modify it:

chmod o+w drupal/sites/default/settings.php

Run the Drupal installer by going to http://dev/drupal.

Remove the permissions from the settings file:

chmod o-w drupal/sites/default/settings.php

And create Drupal's files directory:

Rejoicing

Now I've got an easy setup where I can create my Drupal sites under /Users/john/Sites and refer to them with short names like http://dev/foo. MySQL is running nicely. Public access to my dev sites is disabled by Apache. Life is good.

If you use a RAID 0 array created by SoftRAID 3.6.4 as the boot drive on your Intel Mac and you feel the urge to install Leopard on it, don't. Just be patient until SoftRAID 3.6.6 comes out. Also, get your head examined. You should not be running striped RAID as your boot drive! *grin*