In the late 1990s, you could get away with a flat Web page that displayed nothing but text. Today, a successful Web site needs to be able to interact with visitors—to collect information and provide customizations. The way you do it is through scripting.
By default, Windows 2000 and IIS 5.0 produce scripts using ASP. However, one of the hottest new types of HTTP scripting is PHP (Hypertext Preprocessor). Unfortunately, Internet Information Server 5 doesn’t natively support PHP. In this Daily Drill Down, I’ll show you how to download, install, and configure PHP to run on IIS 5.0.
If you’ve previously used ASP as a scripting language, you may wonder why you should even bother switching to PHP. But there are plenty of reasons to choose PHP over ASP. For starters, PHP scripts tend to run much more quickly than comparable ASP scripts.
Another reason for switching to PHP is that there are no hidden costs. In an ASP environment, if you need code for things like encryption or e-mail management, you often must buy third-party modules. However, many of the commonly used modules that don’t come with ASP are freely included with PHP. And if you need a module of code that isn’t included, there’s a good chance that you’ll be able to download it for free from one of the many PHP Web sites.
Another reason for switching to PHP is that it tends to be an easy transition. PHP scripts are sort of like a combination of ASP and C++. What’s more, PHP is object oriented and has a much better memory management model than ASP. This means that PHP code tends to scale better for use in large enterprise applications.
Essentially, PHP can do anything that a CGI script can do, but usually more quickly and efficiently. PHP works well for tasks such as collecting form data, generating dynamic page content, and sending and receiving cookies.
The first step to installing PHP support is to download the PHP source files. As of this writing, the most current version is PHP 4.2.2. You can download the PHP files from the PHP Web site. All of the necessary files are included in a 5-MB Zip file. There’s also an installer that you must download as well. The installer is contained in a separate 913-KB Zip file. There are a lot of files available on the PHP Downloads site, and it can be confusing trying to figure out which files to download. Therefore, check out Figure A. In this figure, the two files that you need are circled.
|These are the two files that you need to download.|
Begin the process by downloading the PHP source files and unzipping them. When you unzip the archive, be certain to extract the files using the Original Path option. Otherwise, many of the files will be placed in the wrong directory, and the installation process won’t work. When decompressed, the source files will consume about 13 MB of disk space.
Once you’ve downloaded and decompressed the PHP source files, download the installer program. The installer is contained within a file named Php-4.4.4-installer.exe. It automates the installation process for the CGI version of PHP. Before you begin the installation process, you should know that the installer doesn’t install any extensions or server API versions of PHP. You should also know that although PHP 4 comes with several SAPI modules, these modules are very buggy and aren’t recommended for use on production servers. Therefore, I’ll focus on installing the CGI version.
When you launch the installer, you’ll see a warning message stating that you’ll probably have to stop your Web services before installing PHP. However, if you’re installing PHP onto IIS or onto the Windows Personal Web Server, you can leave the Web services running during the installation.
The first few screens of the installer are fairly standard. You must accept the license agreement and select whether you want to perform a standard or an advanced installation. If you choose an advanced installation, you’ll see a screen asking which folder you want to install PHP into.
The next screen asks if you want to create a backup of system files that will be replaced by PHP, and where these backup files should be placed. I strongly recommend creating a set of backup files. The backup files are used to automatically return your system to its previous state should you decide to uninstall PHP. The backup files can also help you to recover should PHP cause problems with your server.
The next step in the Setup process is selecting a destination folder for temporary installation files. You must then select a folder for session data to use. Next, you must enter the address of your SMTP server followed by an e-mail address that PHP can use for mail functions. You can see an example of this in Figure B.
|Enter the address of your SMTP Server followed by a From e-mail address.|
The next screen asks you to select the level of error reporting to use. The default option is to display all errors and notices. This is the most verbose notification option. Although it’s overkill for most production environments, the manufacturers of the PHP software recommend that you use it any time you’re doing development.
You must now select which type of Web server you want to configure PHP to run on. As you can see in Figure C, there are options to run PHP on Microsoft Personal Web Server for Windows 9x, Me, and NT, along with options for IIS, Apache, and Xitami servers. The installer can automatically install PHP onto any of the Web servers that I’ve just listed. If you have any other type of Web server, you may still be able to use PHP, but you’ll have to configure it manually.
|There are options for installing PHP onto several different types of Web servers.|
Other Web servers?
There are a couple of things that you might have noticed in my statement about installing PHP on other Web servers. For example, there are no Linux or UNIX servers on the list. This is because PHP was originally designed to run on UNIX servers, and it’s included with most newer UNIX and Linux operating systems. You may also wonder how I can be so confident that PHP will function on servers that aren’t supported by the installer. The PHP software is written in C++, and it includes the full source code. This means that the software can be compiled to run on just about anything, including Apple’s Macintosh.
After selecting your server platform, the installation program asks you which file extensions you want PHP to interpret. By default, the PHP extension is selected, but you can also select PHTML and PHP3 if you so desire. At this point, the installer completes the process by copying all of the necessary files to the appropriate locations.
What’s that error message?
Under normal circumstances, the installation procedure should be as simple as running the installer. However, on one of the servers that I used to test PHP, the installer was unable to fully complete the installation. At the end of the installation, I received an error message, shown in Figure D, stating that an OCX file was missing and that it was necessary to complete the installation process manually.
|You may receive this error message stating that you need to manually complete the installation process.|
To manually configure PHP, you must begin by verifying that the necessary DLL files are in an acceptable location. Which DLLs will be used depends on whether you’re running in CGI mode or in SAPI mode. Since we’re working in CGI mode, the only DLL you need to worry about for now is Php4ts.dll, although you may end up having to copy other DLLs later on if you decide to activate other modules. The DLL files need to be in the WinNT\system32 directory.
The next step in the process is to copy the Php.ini-dist file to your %Systemroot% folder and rename it to Php.ini. Depending on if or when the installer broke down on you, this file may already exist in the correct location with the correct name. Once you’ve copied and renamed the file, open it in Notepad so that you can edit it.
The first thing that you need to do when editing the Php.ini file is to locate the Extension_dir = ./ line about halfway through the file. You must update this line to reflect the location of the DLL file that you copied earlier. Therefore, the line will look something like:
Extension_dir = c:\winnt\system32
Now, locate the Doc_root line and point it to your Web server’s document root. For example, on a Windows 2000 Server running IIS 5.0, this line might look like this:
Doc_root = C:\Inetpub\wwwroot
When you’ve updated the Doc_root variable, save your changes and close Notepad.
You’re now ready to begin configuring IIS to accept PHP. To configure IIS, open the Internet Services Manager, right-click the Web site that you wish to add PHP support for, and select the Properties command from the resulting shortcut menu. When you do, you’ll see the Web site’s properties sheet. Select the Home Directory tab (or the Virtual Directory tab, depending on your location in the tree), and click the Configuration button to reveal the Application Configuration properties sheet. The App Mappings tab should be selected.
At this point, click the Add button to reveal the Add/Edit Application Extension Mapping dialog box. In the executable field, enter C:\php\php-4.2.2-win32\php.exe, where C:\php\php-4.2.2-win32 is the location of the Php.exe file. Next, move down to the Extension field and enter the file extension that you want to associate with the PHP script processor. I recommend using the .php extension, but you can also use .phtml and .php3 for backward compatibility with legacy applications. You’ll have to perform this procedure once for each file extension that you want to enable.
Finally, make sure that the All Verbs button and the Script Engine and Check That File Exists check boxes are selected, and click OK. When completely filled in, the Add/Edit Application Extension Mapping dialog box should resemble the one shown in Figure E.
|This is how the Add/Edit Application Extension Mapping dialog box should be completed.|
The Internet Services Manager will now return you to the Application Configuration properties sheet. From here you can add more extensions if necessary. Once you’re done adding file extensions, click OK twice to close all open properties sheets.
The next step in the process is to enable the appropriate security. Assuming that the folder containing all of the PHP files uses NTFS security, right-click the PHP folder (or whatever you named the folder) and assign full permissions to Iusr_servername. Obviously, you’ll use a different account name if you’re using a different account as your IIS service account. Whatever account name you use, the full access permissions must apply to the PHP folder and to all subfolders.
The final step in the installation process is to stop and restart the IIS services. If your server uses a lot of dependent services, such as Exchange or SharePoint Portal Server, then the easiest way to stop and restart all of the services is to reboot the server. If you don’t want to reboot, you can stop the IIS services by entering the following command in a command prompt window:
NET STOP IISADMIN
When the IIS services and all of the dependent services have stopped, you can restart IIS by entering the following command:
NET START W3SVC
Keep in mind that you’ll have to manually restart any other services that might have been stopped along with the IIS services.
Now that you’ve got PHP up and running, it’s time to test it. Hopefully, you’ve already got some PHP scripts that you can use to test the server. If not, try creating a file called Test.php in your Web site’s root directory, containing the following code:
echo "PHP is working correctly!!";
Notice that in the sample code, there’s a section that begins with <?php and ends in ?>. This section designates the PHP code within the HTML code. The biggest difference is that while a Web browser interprets the HTML code, the Web server interprets the PHP code before passing it on to the browser.
Once you’ve created the sample script, open a copy of Internet Explorer and enter the following command (where “Bart” is the name of your Web server):
When you do, you should see the script produce the output shown in Figure F.
|You can run a sample script to see if PHP is working correctly.|
At this point, everything should be working well, but just in case something has gone wrong, I’ll try to point you in the right direction for troubleshooting the problem. The way that the PHP interpreter works is very simple. Basically, the Php.exe executable interprets PHP scripts. In order for this to happen, IIS must associate a file extension with the executable, as was shown in Figure E. Therefore, this should be the first thing that you check when troubleshooting. Verify that the path to the Php.exe file is correct, and verify that you’ve used the correct file extension.
Once you’ve verified the path and extension, double-check your test script. Begin by checking to see if the script is even accessible. You can tell by whether you receive a 404 error or some other type of error. If you’re getting a 404 error, then you’re directing your Web browser incorrectly. Otherwise, Internet Explorer is finding the script, but the script is having some other problem. If this is the case, take a moment to verify that your test script ends in the .php extension. The PHP interpreter will only interpret scripts with the .php extension, unless you’ve set up other file extensions.
If all of this checks out, double-check the %Systemroot%\system32 directory to make sure that Php4ts.dll exists and that any other DLL files that you plan on using have also been copied to this location. If the DLL files do exist, then double-check to make sure that the Php.ini file exists in the %Systemroot% folder, and that the parameters within the file point to the correct location for the DLL files (%Systemroot%\system32). If you’ve verified all of these things, try completely rebooting your server. Make sure that the Web site you’ve configured PHP for is running after the reboot. You should also verify that your IIS service account has full access to your PHP folder. If you’re still having problems, check www.php.net for patches that might have been released since this Daily Drill Down was written.