IIS + PHP Revisited
I found myself with the need to install PHP, MySQL and FastCGI onto another IIS machine yesterday and was feeling pretty good about myself as I set out on the journey. “I’ve done this a buncha times now…this will be smooth sailing!” Famous last words, right?
So I installed Fast CGI. I installed PHP and set up the php.ini file just like I like it. (I even made sure all my extensions existed!) I then installed mySQL. Wow. this is easy. Feel full of myself, I went ahead and installed my favorite free mySQL management tool, EMS SQL Manager for MySQL. After that was in place, I copied the WordPress site over, dumped the extract from the old home into the new database, changed a few URL paths in the database to match my new server digs, and then set up the application in IIS. “T minus 10 seconds and counting until site launch…. 10 …. 9 …. 8 …. ” you get the idea.
Well, wasn’t I surprised when I fired up the browser only to find every-one’s favorite ambiguous error:
“The specified CGI application misbehaved by not returning a complete set of HTTP headers.”
Aww… come on! This isn’t what I signed up for!
So, I turned to Google to solve this dilemma. It’s amazing how many different solutions are out there for the same problem. And it’s even more amazing how few of them are actually solutions that resolve the problem. I found none. Well, almost none.
After checking and double checking my php.ini file location and contents, and checking my Environment Variables for the appropriate PHP extension paths, and checking my IIS config for my applications for the appropriate extensions, modules and processors, I was stumped.
I dug into the Event Viewer to see what was happening, and could only find this:
“Permission settings do not grant Local Launch permission for the COM Server application with CLSID.”
What?! What’s this?
Look. I’ll spare you the gory details, but it was just another red herring. I added permissions my files, folders and dll’s to my hearts’ content in search of answers, but got no where. Well, nearly nowhere. Maybe you could call it ‘knowhere’... because in one of my searches, in one of the posts, attached there at the bottom, probably on page 2 was a little link that said something like “Just try this. It works every time and usually fixes problems like this” and then there was a link. You know the link. It’s the one you usually ignore. Desperate, and running out of time, and really wanting to power down this machine and go eat, I clicked. And boy, am I glad I did.
What I found on the other end was something called IIS AID. Sounds harmless enough. What they offered was a PHP installation kit for IIS. I took the bait and downloaded the package. Fearing both the worst, and that things couldn’t get worse, I went ahead and installed it and lo-and-behold, it went by in seconds, painlessly. Granted, it went into the default C:\iis-aid\php\ location which for a details guy like me, ruffled my feathers, (I’ll know better next time) but even that was survivable.
So I dared to turn back to the browser, left staring blankly at me with incoherent blabbering about CGI headers. And then I hit F5. And there it was, in all of its’ glory. A site to behold. A website to behold! Thank you IIS AID. What I missed, you didn’t. And I am really grateful. And now I can go eat.
WordPress 3.0 + Events Calendar
There is nothing quite like the haymaker of old. Coming out of nowhere. Stealing your breath. Forcing you off-kilter.
So there I was, updating my localhost copy of WordPress to 3.0 as I had done so many times without a thought on production servers. Come on! This is WordPress. It just works!
Before I could take another sip of coffee and click on a playlist, I was afronted by an unwelcome screen of errors shouting “Error 500″ and “fastcgi.”
“Oh no” I thought. “Here we go again.” Just yesterday I had reluctantly installed IonCube’s PHP Loader (this allows encrypted PHP code to execute, which allows vendors to encrypt their PHP code, which allows you *not* to fiddle with it.) “Surely, this is the fault of IonCube!” I proclaimed. So, I fiddled with my php.ini file and rearranged things, and checked my PHP/ext/ folder to make sure everything the php.ini was looking for could be found. Nothing. Zero. Nada. Zip! Not the way I wanted to spend July 3rd. (Really, I should be out teaching my kids how to crimp “whistling peets” with pliers to make their own not-so-safe-and-sane version of the popular noisy tweeter.)
Curiously, all of my other PHP sites ran locally.
So, I poked around, checked the WordPress files and finally decided to update everything. New WordPress. New plugins. New coffee. In the process of updating the plugins, I first removed all of them from WordPress by simply moving the folder elsewhere temporarily. Voila! it worked! Well now. I’m so smart. It’s obviously some plugin not playing nice. I knew this all along!
So one by one I added them back in. Well, ok. I dumped most of them back in, and reloaded, and got the error screen again. So after taking chunks of them back out, eventually determined it was my tenuous friend, the “Events Calendar” plugin. This single plugin has caused me pain across many WordPress sites. It’s fragile. It breaks other stuff without regard for anyone’s feelings. But oh, it does what I need, so I put up with it!
So, out with the old, in with the new. I think I will keep a copy of Events Calendar around for the future, but I think it’s time to find a new way to manage my calendar within WordPress.
Windows + IIS + PHP + fastCGI Oh My!
I just did a fresh install of PHP 5.2.12.12 onto my fresh install of Windows 7 / IIS 7 machine and spent hours dealing with a very common fastCGI crash problem:
First, your browser returns: C:\PHP\php-cgi.exe – The FastCGI process exited unexpectedly
and further investigation into my event viewer brought me:
Faulting application name: php-cgi.exe, version: 5.2.12.12, time stamp: 0x4b29139b
Faulting module name: php5ts.dll, version: 5.2.12.12, time stamp: 0x4b291270
Exception code: 0xc0000005
Fault offset: 0x000f34bc
Faulting process id: 0xdc8
Faulting application start time: 0x01cab5a028d4df49
Faulting application path: C:\PHP\php-cgi.exe
Faulting module path: C:\PHP\php5ts.dll
Report Id: 66854a70-2193-11df-9e34-001676b6c11c
And then I started banging my head on my desk and wondering why installation of complex programming language frameworks has to be so difficult.
And eventually, after hours of surfing, tried a few things that eventually helped.
First, at the suggestion of one forum, I changed my local site-level IIS Handler Map to use “CGIModule” rather than “FastCGI” to see if that would help.
While this fixed the problem (PHP would finally load successfully, huzzah!), I wasn’t convinced that this was a solution. So I changed it back. (why? WHY??)
After looking though my PHP files, and my PHP.ini, noticed that several extensions were being asked to load in the PHP.ini that didn’t actually exist in the C:\PHP\ext\ folder. (Duh!)
I had copied my old PHP.ini file over from a previous PHP (isapi) installation, and the extension dll’s were no longer there! When I commented these missing extensions out in the PHP.ini file, the PHP pages loaded with fastCGI just fine. To verify that this was a problem, I re-added one of the missing extensions, and the fastCGI error/crash started happening again. I can’t vouch for what might happen in an Apache server environment, but know that within Windows, (at least *my* Windows) the missing extension file isn’t being ignored and it’s fatal.
As I couldn’t find anything suggesting otherwise online all day today, maybe this info will be useful for you!
What is the true cost of web development?
I frequently am asked about the cost of putting together a website for a client. Of course, the final answer will vary based on the particular needs of the client, what is desired from the website, etc. Things worth considering range from one’s goals for a website, how to reach their target audience, and what value-added services would be best to offer. All in all, there are too may factors to spell out a definitive list because quite simply, every website I build is fundamentally different in design and purpose. What I can comment on is that whatever your functional and design requirements are, you should be prepared to pay a representative amount for a web application that will be professionally designed and programmed, and which is reflective of your business or organization.
I can tell you more than a few stories about bids I provided for jobs that were later turned down for one reason or another -often price included- only to have the same customer re-contact me later pleading for help to recover their website, or finish a project that was never completed by my competition. It amazes me when clients tell me stories that the developers they originally hired become irrated with their requests for work or unresponsive to phone calls or emails. It is my belief that many self-taught web developers have simply not spent any time thinking about or practicing customer service. Perhaps this is a generational thing, though sadly it shouldn’t be.
I can remember well my earliest jobs in the retail sector where the mantra was drilled into me that the customer is always right. Indeed, if I am paying for goods or services, I should have the final say on what is satisfactory, particularly when expectations have been presented by those I am employing for their services. It’s built into our nature to want the best deal we can find when we set out to purchase goods or services, but as the familiar addage goes, we certainly do get what we pay for in almost every case. I would emplore you to consider this when you set about contemplating a new web application, an update to an exisiting site, or new additions to your current web offerings.
