JimmyLi.net

Despite that IIS 7.5 is the current stable IIS release, it is only available for servers running Windows Server 2008. However for the many of us who are still running Windows Server 2003 or Windows XP, IIS 6.0 is our only option. And many of us are still limited to that option.

In this article I will do a walkthrough on installing FastCGI and PHP. This walkthrough assumes you know how to set up a basic website that functions publically on IIS already. For those who are a bit new to PHP on IIS, here’s a general view of what happens on a PHP page call:
When the client calls a PHP page (.php), IIS responds by calling FastCGI. FastCGI then calls the PHP executable to execute the PHP script.

Installing FastCGI
With the stable release of PHP 5.3 out for a while now, the only way to install PHP 5.3 on IIS is through a CGI Handler. PHP 5.2 and earlier allowed us to run PHP using ISAPI, but that option has been deprecated. For those of us intending to move forward, we would have to use CGI from now on. We’ll go over installing the FastCGI handler on IIS 6.0.

You can download FastCGI for IIS 6.0 here (version 1.5 as of this time).

Run the executable on the web server to install FastCGI. You may have to restart your machine for the installation to complete. When that’s done, open up IIS Manager and view the list of Web Service Extensions on the server tree. There should be a “FastCGI Handler” extension on the list. Make sure its status is set to Allowed. And that’s it. FastCGI is installed!

Installing PHP
Download the latest version of PHP for Windows here.
We’ll be doing the manual method of installation, so download a ZIP version and that is Non Thread Safe. It’s completely up to you whether you want to use the PHP 5.2 series or the PHP 5.3 series. Some applications may work on PHP 5.2 but not 5.3. Either one, the installation process is the same.

Unzip the content to somewhere on your server. I prefer the base of the C drive: C:\php\
Rename the “php.ini-recommended” file to “php.ini” and make any adjustments to that configuration file. (I won’t go over that here.) You can do this at a later time if you wish. Just like that, PHP is technically “installed” on your server.

Making PHP work
Now, it’s time to make IIS understand the .php extension. When IIS hear a .php file called, we want it to let FastCGI know, so FastCGI can call PHP. To do so, we’ll have to set up the extension mapping for .php. Open up IIS Manager again and navigate to “Web Sites”. Right-click on it and select “Properties”. Select the “Home Directory” tab, and within it, select “Configuration…” A new window pops up with a listing of Application Extensions.

Look for the .php extension and “Edit…” it. If it doesn’t exist, “Add…” the extension. A new windows pops up. For Executable, look for the FastCGI library. For most default installs, it should be under: C:\WINDOWS\system32\inetsrv\fcgiext.dll
For Verbs, limit it to: GET,POST,HEAD
Save all options.

IIS can now talk to FastCGI when a .php page is called. Now, it’s time for FastCGI to talk to PHP by modifying FastCGI’s configuration file. For default installs, the config file should be located at: C:\WINDOWS\system32\inetsrv\fcgiext.ini
Open it in a text editor and add the following at the bottom:

[Types]
php=PHP

[PHP]
ExePath=c:\php\php-cgi.exe

The Types is the extensions it’s listening to and the corresponding configuration it will use. So here a “php” extention will use the [PHP] configuration. The [PHP] configuration has the path to the PHP CGI executable. This is how FastCGI knows where to talk to PHP. Modify the path to where PHP is located on your server.
There are more options you can add, but this should get you going.

Testing the Installation
Test that the installation went successfully. Restart IIS and create a website hosting a PHP file and output the phpinfo(). If everything went well, you should see the PHP Info page with hints of FastCGI being used in there.

Note: When I was doing this, I’ve also experienced a FastCGI error during this last step stating that “Access is denied”. I’m not sure if this is common, but I was able to fix the issue by adjusting the security permissions on the PHP installation folder. I make sure that the users: Administrators, NETWORK SERVICE and SYSTEM are listed. If not, add them, restart IIS, and try to load the PHP page again.

Yahoo! Developer Network (YDN) posted an interesting blog article about thinking of bandwidth in terms of packets.  Since all HTTP data essentially travel through the Internet by packets (using TCP/IP), it’s interesting to be more aware of how much data each packet stores.  I don’t know very much in-depth about TCP/IP but it seems like a packet is typically 1460 bytes maximum according to the YDN blog article.

Although trying to optimize your website to use the fewest packets as possible sound absurd, there are actually some areas where doing it may have some small benefits.  For example, small requests that can fall in the 1 or 2 packet segments.  I’m mainly taking about AJAX (XMLHttpRequest) requests, which we expect the response to be fairly instantaneous.  Every packet sent with TCP/IP has to be acknowledged by the other server and the client has to wait for that acknowledgment, so it is typically slow (more latency) compared to other protocols (such as UDP, which is along the lines of fire-and-forget).  Since AJAX requests are typically very small, it is a good area to try to improve it by trying it as small as possible.  This includes its HTTP Header data (cookies, user-agent strings, accept strings, referrers, etc.) and any Body data (POST data).  Most of that data is fairly hard to change since it’s provided by the browser, but others such as the cookie data and POST data the web developers can.  For me, I try to keep the cookie data as small as possible.  Some web frameworks allow you to store encrypted session data in the user’s cookie by default (such as KohanaPHP), which is nice in keeping that data with the user, but it adds that extra data to every request (including non-AJAX requests).  (Though one can argue that accessing the file system or database for the session data could be slower than the extra packet.)  Instead, it maybe recommended to just store the session ID in the browser (which is PHP’s default behavior).

The blog article also has an interesting link to another interesting article measuring that XMLHttpRequest uses 2 packets to send POST data (for most browsers).  You should give that one a read.  Although I don’t have websites with huge user-bases that could definitely take advantage of these techniques, it is interesting to know what is going on when the request leaves your web browser and how to optimize it such a minute scale.

It’s been a while since I’ve touched on the issue of having PHP 5.3 talk to a MS SQL Server on IIS (without using ODBC or other connection methods).  Last time I’ve mentioned that Microsoft has an official SQL Server Driver (v1.0) for PHP to talk to a SQL Server only to find that it doesn’t work for PHP pre-v5.3, which, we didn’t really need anyway because PHP already came with a MS SQL Library driver (which was removed from 5.3) that somewhat works.

However, after starting to play around with PHP 5.3 with SQL Server again I’ve noticed that Microsoft finally release v1.1 of the SQL Server Driver, one that was stated to work with PHP 5.3 on IIS. Lo and behold, I was finally able to get it to work.  Even better, the package also came with an offline documentation on installing the driver and the whole API Reference.  Very nice.  For those who are interested, here is the documentation online, the lo-bandwidth version (no MS Frames):
SQL Server Driver v1.1 for PHP

Note that if your SQL Server is on another server from the PHP server, you’ll also need to install the SQL Native Client data access library on the PHP server.  (If it is on the same server, the installation of SQL Server already installs this package.)  It is highly recommended to use the latest version that works with SQL Server 2008.  It took me a while to find it (the 2005 version link is rampantly posted everyhere), but you can find it officially here:
Microsoft SQL Server 2008 Feature Pack, August 2008

Near the bottom of the page you’ll find “Microsoft SQL Server 2008 Native Client”.  Get the one that’s appropriate for your machine.  Despite it saying 2008, it should be backwards compatible with earlier versions of SQL Server.  I’ve tried it as far as SQL Server 2000 (on IIS 6.0) and was able to connect and query successfully (I haven’t tested for limitations and such, if any.)

And there you have it.  The official method to talk to a MS SQL Server on IIS with PHP 5.3, straight from Microsoft themselves.

Updated: October 09, 2009
The version of the SQL Driver 1.1 that was released in August was a preview release version.  Microsoft officially released the final version of SQL Server Driver 1.1 on October 6th.

Last time I posted about PHP deciding to remove the MS SQL Server Connection driver and library from the PHP 5.3 package, and mentioned that Microsoft now has its own version of the MS SQL Server driver for PHP.  I’ve decided to start playing around with it and after a few hours of no luck getting it to work with PHP 5.3 (it doesn’t show up in phpinfo), I’ve decided to do a search on it.  What I’ve found on the MSDN message boards was that the MS SQL  Server driver PHP, version 1.0 (the current and version), does not have support for PHP 5.3. (reference)  Not until version 1.1 comes out, at least. This is rather stupid considering now there is no direct MS SQL Server driver for PHP 5.3.  The only way I know of is to use an ODBC connection.

Update: I’ve made a new post specifically in detail on how to install PHP and FastCGI on IIS 6.0, which is needed to apply to installing PHP 5.3 on IIS.

With the release of PHP 5.3.0 introducing a lot of new features and bug fixes, it also comes in with a lot of changes for Microsoft IIS users.  The biggest one of them is the way that PHP is now installed on IIS.  The PHP 5.3 package now no longer provides an ISAPI DLL file (which I’ve been using).  The only way to do it is through CGI, in which you should (have to?) use the FastCGI module.  Depending on which version of IIS you have, the setup will be different.  (I have IIS 6.0 on a Windows 2003 server).  Microsoft seems to have gotten more close with Zend recently and provided better support on IIS that they even have a dedicated website for installing PHP on IIS and providing community support.  Everything you need to know for installing PHP on IIS is on that website.  PHP also now have a website dedicated to supporting PHP on Windows, regardless of whether you’re using IIS or Apache on Windows.

One of the big drawbacks I’ve found was that PHP decided to remove the MS SQL Server connection driver in the PHP 5.3 package.  Just adding back in the DLLs from the old PHP packages back in the PHP directory did not work for me.  Not only did they make it harder for IIS users to install PHP, they had to make it harder for those to connect to MS SQL Server.  Upon doing some online searches, the driver used in PHP was very old (which explains my post on trying to get it to work properly on previous versions of PHP).  Microsoft now has it’s own version of MS SQL Server driver (2005 and above) for PHP.  I have yet to install it, but it would have to be done on a development environment to redo any code using PHP’s old connection library.  I’ve also yet to find any documentation on it so I’m not sure of the details of the driver.

Update: September 24, 2009
Maybeme compiled a php_mssql.dll that works in the VC9 version of PHP 5.3. Note that the ntwdblib.dll files is still necessary. I haven’t gotten it to work personally, but it seems others have, so I’m sharing it for others who wants to try.

Download here: php_mssql.dll (right-click > Save Link As…)

Ever since I’ve began creating web applications that include more and more Javascript, some of my own, and some such as Javascript libraries and plug-ins, the need for me to optimize the amount of data to transfer to the client becomes more imporatant.  I’ve found that compressing your Javascript is one of the simpliest things you could do and save a few kilobytes on initial page load.

So far, the best compressor I’ve used is the YUI Compressor. YUI Compressor compresses Javascript files by stripping out unnecessary whitespaces, semi-colons, and replace local variable names with shorter names, decreasing the size of the file by about 30% in my experience.

The only few ways to run your code through YUI Compressor is through an online service, or by downloading the YUI Compressor to your computer and running it via command line.  I use the command line, but I’ve made using it a habit and without even having open up command line by just saving the command into my favorite code editors and just assigning a hot key to it. For example, Notepad++ has a ‘Run…’ option that lets you run external executables and saving that command line to some set of hotkeys (e.g. Ctrl+1).  In the command line arguments, you can set editor-specific variables for the filename, etc. such that executing the command can automatically take your script.js that you’re working on, compress it, and output a script.min.js file for you in the same directory.  It’s simple and you don’t even think about it once you have it all set up.  I’ve even made it a habit to compress all 3rd party scripts when possible to squeeze a few more kilobytes out of the overall transfer.

Of course there are other ways to save on transfer such as by making sure your server has GZIP compression turned out, and a few other methods, but making a habit of compressing your Javascript is one of the simplist thing you can do and can go a long way in saving a lot of bandwidth and improve user experience with less loading time.

I have been pulling my hair trying for many hours to connect to a MSSQL server remotely with PHP.  I was able to connect using ODBC but I wanted a more elegant and native solution.  Trying to connect using PHP’s MSSQL database library constantly gave me the error:

Warning: mssql_connect() [function.mssql-connect]: Unable to connect to server: 172.xxx.xxx.xxx

I’ve tried using the computer name and several other solutions.  Upon doing a lot of research and reading the user notes on the PHP website, and trying out several solutions before finding out a working solution.  I’ve found that the file ntwdblib.dll packaged with PHP5 (currently 5.2.9-1) is an old version (2000.2.8.0).  Most people suggested replacing it with the later version, 2000.80.194.0.

Click here to download this version of the file: ntwdblib.dll

I’ve replaced the file and restarted my IIS webserver and the connection was successful!  I hope this helps for those searching for the solution.

For the last year to two I’ve familiarized myself quite a bit with AJAX and was able to leverage its power in providing a seamless user experience with so-called Web 2.0 style of web development and design.  I’ve began AJAX with simple XMLHttpRequest (XHR) to request HTTP data from the server.  Then, I’ve stepped up my game and utilized the jQuery Javascript Library to do AJAX.  One of the best things I loved was the ability to handle a JSON data type request from the server.  Unlike a block of XML or HTML, JSON is so flexible as one is able to return many different types of information such as a status code, status message, and any data along with a HTTP Status Code 200 (OK).  I’ve pretty much defaulted to using JSON as the response type for all my AJAX called through jQuery.

At work, while working with a third-party application for generating personalized websites, the lack of information the system provided, I’ve tried using AJAX to request information from another server that can request for more information.  Upon discovering that AJAX cannot perform cross-domain requests (Same Origin Policy) due to various security issues that would arise, I’ve found something called JSONP.  Although it’s technically not AJAX (it doesn’t use the XMLHttpRequest object), it was a workable hack-ish workaround the limitations of the current state of AJAX techniques using a GET request that returns a JSON object wrapped in a Javascript callback function.

Today, I’ve discovered a proposal by Douglas Crockford for a JSONRequest service that allows cross-domain requests with requests and responses in the form of JSON, minus some of the issues that plagued XMLHttpRequest if it was usable cross-domain.  The big one would be that cookies or HTTP Authentication data would not be sent along with the request, so that prevents Cross-Site Request Forgery.  Though the proposal has been created nearly three years ago I’m surprised that it hasn’t been implemented in any browsers yet.  I hope a future version of Firefox or some browser would implement it and slowly spread its implementation.

I was reading this article about how when many Japanese Internet users want to visit a website, they type in the name of the website on Yahoo! Japan to do a search and click on the result rather than directly typing the domain name into their web browser’s address bar.  (This is based on Yahoo! Japan’s 2008 search ranking that the top keywords are to specific websites.)  This made me think about how I used to enter information into the address bar and how I do it now.

Since years ago when I was an Internet Explorer 6 user I would always have Yahoo as my home page.  In fact, I still do now since it does provide interesting news.  Whenever I would go to any specific website, I would type it in as a search term in Yahoo.  The reason I did this was because anything I typed directly into the address bar would stay in the drop-down list.  Why this bothered me was because I used the address bar as like a “super-favorites” menu of the top 10 or so websites I habitually visit everyday.  You know, like webmail, favorite forums, etc.  Yes, I know that’s not how you use it, but it was easier than digging through a long list of bookmarked favorites, and also I wasn’t a fan of the ‘Links’ toolbar either since it took up screen real estate. Since the address bar menu only displays the entries by most recently visited, by typing some other random website into that address bar pollutes the list with that address, and there was no easy way to delete that entry except to clear the whole browser’s history.

Then came the days when I switched to Firefox 2.  I was still following the same habits of doing a keyword search to get to a website.  However, Firefox 2 did have a method to remove entries, but it was cumbersome to often delete these entries.

Then came Firefox 3, with its heaven-sent “Awesome Bar,” as they call their address bar.  This made my search-to-get-to-a-website illness disappear.  The Awesome Bar literally, out of the package, displays your most visited websites, which, not surprisingly, are the websites I visit everyday!  Firefox keeps tabs on the count of how often you visit each website.  Since the Awesome Bar sorts by hits, I could free myself by typing any ol’ web address I’ve visited one or two times directly into the address bar and still not pollute what shows up in the address bar.  The Awesome Bar also searches your history urls and page titles with whatever you typed so that’s very helpful.  There are times where I’ve visited a website but had not bookmarked, and the history auto-search makes forgotten websites so easy to find.  Thank you Awesome Bar!

I was just reading this blog entry and it reminds me of why using a framework gives the developer so much more flexibility and better off long term, especially for business information systems where business rules change will be made.  Although comparing using a framework as opposed to an out-of-the-box solution is fairly subjective, I do believe that using a CMS does have its advantage when budget is tight.  However, as a full-time web developer for a company, like myself, using a framework is definitely the way to go.

One framework I’ve began using recently is the Kohana PHP 5 Framework.  It’s a very lightweight framework using the Model-View-Controller (MVC) pattern.  While working with the framework, I’ve found several things that I really liked over several CMS software such as Joomla! and Drupal could not provide (or not that I’ve noticed, at least).  I really like Kohana’s simple ability to allow all your scripts to sit under the public root, and be the core of several applications.

Security-wise, I like how simply it is to keep everything under the public root.  The only thing that sits on the public root is in index.php file and any client files (images, CSS, Javascript, etc.)  If the PHP parser fails and the PHP code is exposed, only the index.php is exposed to the public, and it doesn’t contain anything critical except relative paths to your main application directory, which is inaccessable publically.  Kohana has a core “system” directory, and one more or “application” directories for each of your web application.  With this type of filesystem, they’ve implemented the so-called “cascading filesystem.”  If there is anything not set in your application directory (e.g. configurations, error pages), Kohana automatically aquires those lower in the filesystem chain, with the “system” directory being at the very bottom.

Kohana provides all the abstraction libraries for common use functions, like database access, session management, caching, etc.  Additional modules also such as the Auth module for user authentication makes it simple to create and manage secure passwords and sessions.  Even without a URL rewrite module on your web server, building SEO-link friendly apps should not be an issue.

PHP itself is a very lax scripting language that lets developers do whatever they want, which can have major disadvantages when trying to create organized apps.  Having a framework like Kohana definitely helps keep many things organized.