Geeky Bob

Whenever I am delivering a presentation where I need to use PHP, I typically use a batch file that I wrote in order to rapidly deploy PHP on the system that I am using for my demos. The batch file usually takes less than a second to run, which always seems to amaze people in the audience. As a result, I usually have several people ask me for my batch file after each presentation, so I thought that it would make a good subject for today's blog.

I should mention that I have used this batch file in order to demonstrate PHP with IIS in a variety of scenarios, and one of my favorite demos is when I would borrow someone's laptop and plug in a flash drive where I had IIS Express pre-installed, and then I would run the batch file in this blog to deploy PHP. Next I would launch IIS Express, open a web browser on their system, and then browse to http://localhost/ in order to show that IIS Express was working correctly. Lastly I would write a simple PHP "Hello World" page to show that PHP was up-and-running on their system in a matter of seconds.

That being said, I have to point out that there is a very important prerequisite that you must have in order to follow the steps in the blog: you need to start with a known-good installation of PHP from one of your systems, and I'll explain what I mean by that.

My batch file expects to find a folder containing ready-to-run files for PHP in order to deploy PHP on a new system. I originally obtained my PHP files by using the Web Platform Installer (WebPI) to install PHP, and then I copied the files to my flash drive or some other repository. (Note that WebPI usually installs PHP in the "%ProgramFiles(x86)%\PHP" folder.) If you don't want to use WebPI, you can also download PHP from http://windows.php.net/, but you're on your own for configuration.

Once I have the files from a known-good installation of PHP, I create the following folder structure in the location where I will be storing the files that I use to deploy PHP on other systems:

• <root folder>
  • SETUP_PHP.cmd (the batch file from this blog)
  • PHP (the folder containing the PHP files)
    • PHP.INI
    • PHP-CGI.EXE
    • etc. (all of the remaining PHP files and folders)

One thing to note is that the PHP.INI file you use may contain paths which refer to specific directories on the system from which you are copying your PHP files, so you need to make sure that those paths will exist on the system where you deploy PHP.

Here is an example: when I used WebPI to install PHP 5.5 on a system with IIS, it installed PHP into my "%ProgramFiles(x86)%\PHP\v5.5" folder. During the installation process, WebPI updated the PHP file to reflect any paths that need to be defined. At the time that I put together my notes for this blog, those updates mainly applied to the path where PHP expects to find it's extensions:

extension_dir="C:\Program Files (x86)\PHP\v5.5\ext\"

What this means is - if you want to deploy PHP to some other path on subsequent systems, you will need to update at least that line in the PHP.INI file that you are using to deploy PHP. In my particular case, I prefer to deploy PHP to the "%SystemDrive%\PHP" path, but it can be anywhere as long as you update everything accordingly.

The following batch file will deploy the PHP files in the "%SystemDrive%\PHP" folder on your system, and then it will update IIS with the necessary settings for this PHP deployment to work:

@echo off

REM Change to the installation folder
pushd "%~dp0"

REM Cheap test to see if IIS is installed
if exist "%SystemRoot%\System32\inetsrv" (
  REM Check for the PHP installation files in a subfolder
  if exist "%~dp0PHP" (
    REM Check for an existing installation of PHP
    if not exist "%SystemDrive%\PHP" (
      REM Create the folder for PHP
      md "%SystemDrive%\PHP"
      REM Deploy the PHP files
      xcopy /erhky "%~dp0PHP\*" "%SystemDrive%\PHP"
    )
    pushd "%SystemRoot%\System32\inetsrv"
    REM Configure the IIS settings for PHP
    appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='%SystemDrive%\PHP\php-cgi.exe',monitorChangesTo='php.ini',activityTimeout='600',requestTimeout='600',instanceMaxRequests='10000']" /commit:apphost
    appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='%SystemDrive%\PHP\php-cgi.exe',monitorChangesTo='php.ini',activityTimeout='600',requestTimeout='600',instanceMaxRequests='10000'].environmentVariables.[name='PHP_FCGI_MAX_REQUESTS',value='10000']" /commit:apphost
    appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='%SystemDrive%\PHP\php-cgi.exe',monitorChangesTo='php.ini',activityTimeout='600',requestTimeout='600',instanceMaxRequests='10000'].environmentVariables.[name='PHPRC',value='%SystemDrive%\PHP']" /commit:apphost
    appcmd.exe set config -section:system.webServer/handlers /+"[name='PHP_via_FastCGI',path='*.php',verb='GET,HEAD,POST',modules='FastCgiModule',scriptProcessor='%SystemDrive%\PHP\php-cgi.exe',resourceType='Either']" /commit:apphost
    popd
  )
)
popd

Once you have all of that in place, it usually takes less than a second to deploy PHP, which is why so many people seem interested during my presentations.

Note that you can deploy PHP for IIS Express just as easily by updating the "%SystemRoot%\System32\inetsrv" paths in the batch file to "%ProgramFiles%\IIS Express" or "%ProgramFiles(x86)%\IIS Express" paths. You can also use this batch file as part of a deployment process for PHP within a web farm; in which case, you will need to pay attention to the paths inside your PHP.INI file which I mentioned earlier.

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/

As you may have seen in my previous blog posts, I tend to use several of Microsoft's various editors when I am working on web projects: Visual Studio, WebMatrix, and even FrontPage on occasion. But every once in a while I also use FrontPage's successor: Expression Web 4.

Expression Web 4 and PHP

One of the great features about Expression Web was that it contained support for local PHP development before WebMatrix and IIS Express had entered the picture, and it was pretty easy to configure; all that you needed to do was to enter the path to your PHP executable in the Expression Web's Application Options, which you will find under Expression Web's Tools menu:

All that being said, I was working on a PHP project in Expression Web 4 recently, and when I clicked the button to preview my page in a browser, the following error message appeared:

"The php.ini file is not configured correctly. Would you like Expression Web to configure this file?"

I had not seen this error before, and it was a little unnerving to me because I had spent a lot of time customizing my PHP.ini file and I didn't want Expression Web (or any other application) making a bunch of unknown changes to my PHP.ini file.

That being said, I was curious what would happen if I answered Yes to that question. With that in mind, I tested several scenarios, and I thought the results of my experiments would make a great blog.

Expression Web 4 and PHP.INI Scenario Testing

First of all, clicking the No button for the PHP configuration dialog box listed above will not break anything, and Expression Web 4 will still open your web page for testing with PHP in the Expression Development Server (which is basically the ASP.NET "Cassini" development server).

If you click the More Information link in the PHP configuration dialog box, that will take you to the following page in the Expression Web help file:

Previewing a PHP page
http://msdn.microsoft.com/library/cc294950(v=expression.40).aspx

When I clicked the Yes button in the PHP configuration dialog box, Expression Web 4 made a few changes to my INI file that it deemed necessary for local development, and I tested three different scenarios which I will document here:

Scenario #1:

Starting with a PHP.ini file that was created when I installed PHP 5.4 through the Web Platform Installer (WebPI), I only noticed one directive in the PHP.ini file that was changed by Expression Web 4:

display_errors=On

(Note: This directive was originally set to "Off".)

And I only noticed one directive in the PHP.ini file that was added:

cgi.force_redirect=0

Scenario #2:

I ran a script that crawled through my full PHP.ini file which reset every "On" value to "Off" (and vice-versa), and then it reset every "0" value to "1" (and vice-versa). After those changes were completed, Expression Web 4 added only modified the following two directives in the file:

display_errors=On

-and-

cgi.force_redirect=0

Scenario #3:

If I removed everything from my PHP.ini file and I restarted my testing with a completely blank PHP.ini file, Expression Web 4 only added the following lines to the file:

[php]
cgi.force_redirect=0

More Information

So in the end, Expression Web 4 made very few changes to my PHP.INI file despite the ominous-sounding dialog that I listed earlier; just the same, it's always a good idea to back up your PHP.INI file before you let any application make changes to it. (This way you can compare the resulting files after any changes have been made and restore settings if necessary.)

Additional information about the two directives which Expression Web 4 modified can be found on the PHP website at the following URLs:

• cgi.force_redirect:
  http://www.php.net/manual/en/ini.core.php#ini.cgi.force-redirect
• display_errors:
  http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

By the way - as of the writing of this blog, Expression Web 4 with Service Pack 2 is available as free download from Microsoft at the following URL:

Microsoft Expression Web 4 (Free Version)
http://www.microsoft.com/downloads/details.aspx?FamilyID=00e6f791-6450-4894-9b3a-2f5b58617a38

Free stuff is always nice. ;-]

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/

With the release of WebMatrix 2, I thought that it would be great to take a PHP class and use WebMatrix exclusively for the entire class. Much to my surprise, this proved to be a great experience. Seriously, I did not expect it to go as well as it did. This has nothing to do with WebMatrix, it's just that I've picked up some cynicism over the years where editors are concerned. This pessimistic outlook is largely due to the fact that I've tried a lot of editors based on the recommendations of my fellow geeks, and those have often been bad experiences. Usually they say something like, "Dude, if you're going to write code in <some language> then you have to use the <some editor> application."

Unfortunately, most of these editors fail to live up to their hype, and I am forced to endure trials and tribulations where I loudly exclaim "If I was using <my favorite editor> I would be done by now!" (I periodically accompany those moments with language that is best reserved for a golf course when you've just hit your last Titlelist into the water hazard.)

But those experiences never happened with WebMatrix 2 - not even once; WebMatrix did pretty much everything that I needed it to do, and it did everything really well. As a result, my cynical skepticism quickly gave way to optimistic impression.

I took copious notes about my experiences with WebMatrix throughout the class, and with that in mind, I thought that it would be great to write a blog with my genuinely unbiased thoughts about using WebMatrix exclusively as my PHP authoring platform for the two-month duration of my class. (As a point of trivia, the PHP class that I took was BMIS 410 - Web Enterprise Technologies at Liberty University. Quick shout out to my professor, Michael Hart, who was a great instructor.)

What Went Well

First of all, the intellisense for PHP was quite good - and having the URLs to the PHP.net reference pages in the tooltip help for PHP functions was extremely useful; I spent a lot of time clicking through to the PHP.net website for assistance for one function or other.

Fig. 1 - WebMatrix's Intellisense for PHP.

Using WebMatrix to preview in IE and WP7/iPhone/iPad emulators was great; in my opinion, this experience was much better than the SuperPreview feature of Expression Web.

Fig. 2 - Options for previewing your website.

Fig. 3 - Testing my website in the iPad simulator.

Using the WebMatrix database editor to create tables for my MySQL database was great - in many ways it was much better than using the MySQL Workbench. The biggest drawback in WebMatrix was the inability to create auto-number fields, and I couldn't enter dates in the correct format in the database UI. (That was undoubtedly something that I was doing wrong.) So every once in a while I had to go back to the MySQL Workbench to fix something. That being said, the interface for creating relationships in WebMatrix is great, and much better than using MySQL Workbench.

Fig. 4 - Editing the data in a MySql Database.

FTP publishing is much better in version 2 of WebMatrix. I used an IIS7 web server, so I was able to use FTP7's virtual hosts to publish to a specific site on a shared server. WebMatrix has no FTPS support, so that is something of a loss. (WebMatrix also lacks full WebDAV support, but I've already talked about that in other blogs.)

Fig. 5 - FTP Publish Settings.

This last point might seem trivial, and I realize that a lot of editors have similar features, but the way that WebMatrix keeps track of opening/closing parentheses, brackets, and curly braces saved me more times than I can count.

Fig. 6 - Helping me keep track of what I'm doing.

What Could Have Been Better

Here are the few problems that I encountered with WebMatrix during the course:

My first issue was not a problem that was due to WebMatrix per-se, but every once in a while a page would get stuck in the cache and I couldn't see changes that I had made to a page, so I would have to restart IIS Express. I'll have to investigate why that was happening; it could be IIS Express, or it could be the PHP engine - I'm still not sure where the fault lies. Fortunately WebMatrix makes it very easy to restart IIS Express from inside WebMatrix, but still - it was a minor frustration.

WebMatrix only wanted to validate against HTML5, but my class required all assignments to use XHTML 1.0 Transitional DOCTYPE, and that showed up as errors in WebMatrix. Yes - the world is moving to HTML5, but still - that shouldn't cause an error.

Perhaps the biggest feature that WebMatrix lacks is the really cool local and remote side-by-side publishing view that both Expression Web and it's predecessor FrontPage had.

When you have a lot of pages open the WebMatrix tab bar fills up, and it's really difficult to keep track of which pages are open.

It would be nice to tear pages out of the editor like you can do with Internet Explorer and Visual Studio.

I have to mention this last item because it was in my notes, but it's technically not an issue for WebMatrix. One of my personal coding self-annoyances was that I would write the text for a string and then realize that I forgot to put it in quotes; when I would type an opening quote, WebMatrix would try to help me out by adding the closing quote - which would now be outside my string, so I always had to delete one of the quotes. There is an option to turn off that feature; see File->Options->Code in WebMatrix. But that being said, this is a useful feature when I remember to create the quotes before I start typing in a string. So once again, this is really more of a complaint against myself; it's my fault that I sometimes have lousy typing skillz. [sic]

Summary

I should start off by saying that I got an "A" in the course, and I can honestly give WebMatrix some of the credit for that. If I had spent a great deal of time fighting with an editor, I would have had less time to focus on writing PHP code. But in the end, WebMatrix actually made it easier for me to write PHP code.

So in closing, WebMatrix rocks, PHP rocks, and using WebMatrix with PHP definitely rocks.

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/

The IIS team has officially signed off on the Windows Cache Extension (WinCache) version 1.3 for PHP 5.4, and the files have been uploaded to SourceForge. This version addresses all of the problems that were identified with WinCache 1.1 that customers were seeing after they upgraded their systems from PHP 5.3 to PHP 5.4.

With that in mind, you can download WinCache 1.3 for for PHP 5.4 from the following URL:

http://sourceforge.net/projects/wincache/files/wincache-1.3.4/

You can discuss WinCache 1.1 and WinCache 1.3 in the Windows Cache Extension for PHP forum on Microsoft's IIS.net website.

Source Code Availability

Since WinCache is an open source project, the IIS team has uploaded the pre-release source code for WinCache at the following URL:

http://pecl.php.net/package/WinCache

For the instructions on how to build the extension yourself, please refer to the Building WinCache Extension documentation.

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/