AddThis Social Bookmark Button

Listen Print Discuss
Mac OS X > Excerpts >

Web Apps with Tiger: Getting Started
Pages: 1, 2

Enabling PHP

Now that we know where our configuration files are, the first thing to fiddle with is enabling PHP, an easy-to-learn web programming language that most of our forthcoming applications are coded in. Open your favorite text editor (BBEdit, nano, etc.), and load /etc/httpd/httpd.conf. You can read a great primer on using nano (and sudo to authenticate) with O'Reilly's An Introduction to the Tiger Terminal. BBEdit will take care of the authentication required when we save our changes.

The Apache configuration file is heavily commented and contains sane defaults for pretty much anything you'd want to do. To change these defaults or, in this case, to enable PHP, we'll simply search for a string matching what we're interested in. Tell your text editor to search for php, and the first and second matches should be:


#LoadModule php4_module        libexec/httpd/libphp4.so
#AddModule mod_php4.c

These two lines tell Apache to load the module that enables PHP--here they are commented out (i.e. prefixed with the # character). Uncomment these two lines (remove the # character but don't touch anything else) and save your changes. Changes to these configuration files take effect the next time Apache has restarted. I'll show you how to do that below but first, let's see what else we find in our php search:


<IfModule mod_php4.c>
    # If php is turned on, we respect .php and .phps files.
    AddType application/x-httpd-php .php
    AddType application/x-httpd-php-source .phps

    # Since most users will want index.php to work we
    # also automatically enable index.php
    <IfModule mod_dir.c>
        DirectoryIndex index.html index.php
    </IfModule>
</IfModule>

This block of configuration only comes into play if the PHP module has been enabled (IfModule...). They tell us that PHP will be interpreted in any file that has an extension of php, and that a source file ends in phps. In addition, index.php should be treated as a default page when nothing more specific is requested and index.html doesn't exist. This is just fine; save your configuration.

Restarting Apache

We've now got to restart Apache so that it can enact our configuration changes. One way is just to toggle the Stop button for the Personal Web Sharing service in the Sharing System Preference, and then click Start again. Unfortunately, if we've made a mistake in our configuration edits, the GUI won't tell us, instead opting to endlessly try unsuccessfully. A far more reliable way is through the apachectl shell utility shipped with Apache. Hop into your Terminal and type apachectl configtest; you should see something like:

morbus@MoistTowelette:~ > apachectl configtest
Processing config directory: /private/etc/httpd/users/*.conf
 Processing config file: /private/etc/httpd/users/morbus.conf
Syntax OK

This is just perfect. On the other hand, if we made a mistake--say, deleting one character too many on the LoadModule line--we'd see a stern rebuking of our mistake with line number:

morbus@MoistTowelette:~ > apachectl configtest
Syntax error on line 240 of /etc/httpd/httpd.conf:
Invalid command 'oadModule', perhaps mis-spelled or defined
  by a module not included in the server configuration

Get into the habit of running apachectl configtest after any configuration change; as long as you see Syntax OK, you're cleared for restarting. We'll use apachectl again, this time prefixed with sudo to authenticate as the root user, and with the restart parameter:

morbus@MoistTowelette:~ > sudo apachectl restart
Password:
/usr/sbin/apachectl restart: httpd restarted

restart stops the Apache server if it is currently running, and then starts it immediately. It is, oddly, equivalent to running sudo apachectl stop and sudo apachectl start. If you don't see any errors (common ones include a configuration typo or forgetting to use sudo), then Apache is now running with your config changes.

Checking for PHP

You can confirm that PHP has been enabled with your error_log. Whenever you enable a third-party module (such as PHP), Apache will happily add that information into the Server header of every request it serves (though it has become common practice by most Linux distros to "obscure" the header with ServerTokens in an attempt at "security"). It also logs this information in the error_log. Use tail to check out the latest information logged there, where you should see something along these lines (shortened for brevity):

morbus@MoistTowelette:~ > tail /var/log/httpd/error_log
[notice] Apache/1.3.33 (Darwin) configured -- resuming normal operations
[notice] Accept mutex: flock (Default: flock)
[notice] SIGHUP received.  Attempting to restart
Processing config directory: /private/etc/httpd/users/*.conf
 Processing config file: /private/etc/httpd/users/morbus.conf
[notice] Apache/1.3.33 (Darwin) PHP/4.3.11 configured
 -- resuming normal operations
[notice] Accept mutex: flock (Default: flock)

Take a look at the two lines that start with Apache/1.3.33. The first one is before your configuration change; the second, with the addition of PHP/4.3.11, confirms that the PHP module has loaded. Depending on your activity, you may not see both entries in the last 10 lines of tail. Try grep notice /var/log/httpd/error_log, or the tailDash widget can F12 your way to logfile monitoring.

Oftentimes, however, simply enabling a module in the configuration file doesn't mean it has been configured properly. Thankfully, with PHP it's easy to test; simply create an index.php file with the following contents and save it into /Library/WebServer/Documents/:


<?php phpinfo(); ?>

Load up http://127.0.0.1/ and, if everything is roses, you should see a rather large page full of PHP debugging information: what it was compiled with, what settings are currently enabled, and blah, blah, blah. An awful lot of stuff here, and only a wee bit you'll need to care about.

Caring Is for Next Time

Unfortunately, this concludes our whirlwind start of Apache web serving under Tiger. As mentioned, I've skimped on the hand-holding so that those with a firm foothold from my previous articles, or their own spelunking, won't wander off in a daydream.

Next time, we'll be focusing on tweaking PHP to be more secure, and installing and configuring the MySQL database server. With that scaffolding in place, we'll start looking at some of the best-of-breed applications that have made LAMP (Linux + Apache + MySQL + PHP/Perl/Python) the preferred architecture of many a web developer. If you have suggestions for where you'd like this series to take you, wax poetic in the comments below.

Kevin Hemenway is the coauthor of Mac OS X Hacks, author of Spidering Hacks, and the alter ego of the pervasively strange Morbus Iff, creator of disobey.com, which bills itself as "content for the discontented."

Return to the Mac DevCenter