PHP 5 under IIS: It’s ready.

One of my first blog posts, PHP Installation: A myriad of options asserted that Windows and PHP 4 in ISAPI mode was a frustrating affair. I hereby offer a partial retraction in this regard as PHP 5 is MUCH different.

The folks at PHP recently announced the retirement of the 4.x version slated for December 2007. After which PHP 4 will continue to receive critical updates until August 2008. If you still run PHP 4, now is the time to starting thinking about getting everything up to version 5.

With that in mind, we’ve decided to upgrade all our development environments to PHP 5. Our standard development machines aren’t really all that fancy; 2 year old Dell P4 H/T based desktops running XP. Being a small group of developers, we’re liberal with the choice of IDE; some use PHPEdit, while I’m drawn between Zend IDE and Eclipse.

Our previous run-ins with PHP4 in ISAPI mode were not good. While PHP would usually run to some extent, we were often faced with segfault error message at the top of the output and often IIS would space out. Yes, we’d followed the lengthy install read-me on the site and still could not get PHP and IIS to play nicely. We pretty much gave up on PHP in ISAPI under IIS and settled with PHP in CGI mode for development purposes.

With the introduction of PHP 5.2 and the impending retirement date; we took the plunge and downloaded the latest PHP 5.2.3 Windows Binary Installer package from PHP.net.

To begin, we un-installed the PHP 4.4.x series CGI installation and removed all traces of PHP from IIS. The PHP.ini file was also backed-up and removed. Once complete, IIS was restarted and we moved on to the installation.

This was straight-forward; it’s a familiar MSI package loaded with all the extensions and required libraries. We stepped through the installation selecting ISAPI mode and the extensions we need for our application such as LDAP, MB_string and MSSQL. For the sake of path simplicity, we also overrode the default “C:\Program Files\PHP…” path with a more friendly “C:\PHP5″ folder. The installer recommended that we “Reboot” because well… it IS Windows after all, and it’s your duty to rebootie…

Once back up, a simple “test.php” was called up containing nothing more than a simple <?phpinfo();?> . Unfortunately this didn’t work. The content was dumped literally, unparsed in the browser; the ISAPI filter obviously didn’t render. A quick look in IIS revealed that in fact the ISAPI filter was NOT configured under the Application Configuration property pages. A few clicks and key strokes linked .PHP files with “C:\PHP5\PHP5ISAPI.DLL”; restarted IIS.

Tried the test page again with success! The phpinfo() method called confirmed we were now in ISAPI Server API;

We now have a working PHP 5 ISAPI installation under Windows XP!

In terms of our application’s compatibility with PHP5; there are many occurrences of about 4 different issues.

• mktime – called without setting a timezone
• strtotime – called without setting a timezone
• “Call-time pass-by-reference”
• Assigning the return value of new by reference is deprecated.

The main architecture of our application works as designed and most of the issues were fixed with a blanket search/replace within the application. The timezone stuff is a bit of a nuisance as we’d designed a great set of wrappers in PHP 4 to handle timezone adjustments. PHP5 handling of this sort of thing is vastly improved, but the list of available timezones is quite large and needs to be integrated into our app.

I look forward to exploring the new reflection classes and tightening up the OO model of our application to take advantage of the new PHP 5 class features. Check out PHP’s migration notes for more detailed information on the differences and changes between PHP 4 and 5.

- Paul

Zend’s Yin and Yang…

Earlier this week I ran into an issue with Eclipse PDT (PHP Development Tools) after upgrading to the latest version (Europa 3.?). My development platform is Windows XP and IIS, 3.2 P4 1GB RAM, IIS, PHP 5 ISAPI, MySQL. We call this the WIMP configuration (Windows IIS MySQl PHP) .

Some of the scripts in our application are quite large and something happened with the PDT; it simply takes forever for Eclipse to parse the script and extract all the classes/variables to render the Outline perspective. This gets really frustrating as it goes through this process on regular intervals as you work through the script. I can’t really complain about Eclipse up until now, its been my development workhorse for the past while and will eventually get fixed in this regard. I have faith. What do you want for free after all?

This lead me down a path where I uncovered things I’d rather not know or have experienced…

About 8-12 months ago (maybe longer now), we need to encode/obfuscate our application for delivery to a client so that they could run it on their own server/intranet. The application is written in PHP and normally all files are in plain-text that obviously offers no copy or tamper protection. Part of selecting PHP for this project included the knowledge that “Zend Technologies” provides Zend Guard/Zend Encoder to suit this requirement.

Some time had past and we were ready to proceed with the order to Zend for the latest and greatest obfuscation gadget.

Having made a contact in sales at Zend during a previous trial of what was called Zend Encoder, I decided to call and pick things up where we left off, which was basically a “I’ll get back to you.” So I rang my sales rep and relayed that we were ready to go and that we needed to purchase Zend Encoder.

The representative proceeded to explain that Zend Encoder was being phased out and being replaced with something called Zend Guard, a whole new product that integrates with the Zend Studio IDE and offers a whole new level of protection through a subscription based service or full all-out purchase of the software. This software was not yet released, and was still being Beta tested. I inquired as to why Encoder was being replaced and that I wasn’t interested in spending money on a commercial beta (Microsoft does a great job of forcing us to buy Beta software in a “Production” wrapper) and could I still buy Zend Encoder.

The rep continued to explain that Zend Encoder had been “cracked”, allowing the source code to be viewed from a previously encoded file. This was obviously a very serious problem for Zend and I did appreciate heads up and that waiting might be worth while.

As promised, when Zend Guard was out of Beta, my rep contacted me and we proceeded with the transaction. As part of the Zend Guard, a license for Zend Studio was bundled as well. If you’re a developer, you no doubt have your favorite “daily-driver” IDEs and probably don’t like to change them up very often; I was happy with Eclipse and saw no reason to change it up to Zend Studio… I’d give it a whirl at some point in the future.

This brings us to some time last week…

Now while this may seem to deviate from the subject of this post, I think its important because it illustrates the general trend (with some exceptions) of software “crumminess” that comes out of Zend Technologies.

Zend Guard

Firstly, it seems that Zend spends more time on their copy protection and licensing schemes than it does trying to make a cohesive piece of software. This became apperent when first installing Zend Guard. It fussed and bitched about the license file that Zend had provided, resulting in a call to Zend where some voodoo was performed and eventually a new license worked.

The user interface on this product really isn’t too hot, the left pane is a tree and the remaining is pretty standard looking application with Tab style UI layouts. You create a project, add/exclude files, choose settings, and make it go. It spits out encoded PHP files out the other end.

When it comes to actually encoding files, its a bit disappointing. Our code uses a technique that groups classes of similar functionality into a salable “module”. When a client is sold a module of new functionality, the sale is recorded and the module is activated by adding a row to the “module info” table. The application checks which modules are installed for a particular client and via the architecture dynamically includes and instantiates the related classes into the PHP name space. Due to the way the related class names are stored in database fields grouped to a top-level module, Zend Guard cannot understand class names expressed in strings that are then evaluated. The top-level protection cannot be applied to this type of application, meaning that any encoding applied to the application must be of a reduced quality/crackability; essentially the same level of encoding that was found in the cracked Zend Encoder. Zend’s advice in this regard is for us to change our code so that the obfuscator will work at the maximal protection level and our type of problem is not in the cards for repair. I recall the suggestion was to wrap a test to a special Zend function in an “is_callable” or “method_exists” call, then actually call that function to encode or get the class name. We were in no position to make a bunch of application changes to support a vendor thats supposed to be transparent and seamless.

The Zend Guard licensing seems to foul up every once in a while too; I don’t use Zend Guard everyday, just when we have a release requiring encoding. Last time I used it, go figure, it bitches that my license is invalid. Another call to Zend was placed and of course their e-mail support is as helpful as a hangnail. I ended up canceling my existing license from the Zend Pickup depot and re-issuing another license for Zend Guard once someone at Zend approved the cancellation of the current license. Zend Technologies doesn’t really seem to care that their license scheme sucks large and I feel that venting via this post is the best vehicle to inform potential Zend users of this fact.

Now the friggin icing on the cake with this is what happens next. You copy the encoded files over to the target web server, configure and run… boom. PHP does not natively support Zend Guard encoded pages. You need to download and install Zend Optimizer. Zend Optimizer latches a library onto PHP that enables the decoding/execution of these scripts. This is so lame it boggles the mind. Zend, the company that contributes and is responsible for the core PHP engine won’t or can’t include this library as part of the standard PHP distribution?? Every time I install the encoded application at a clients’ site I need to jump through hoops of fire to get the permission/authority to proceed with changes to production environments. Sometimes it’s IT departments, other times it’s ISP themselves!! Its not so much a technical difficulty as applying willy-nilly changes to production server core software makes IT managers nervous, and rightly so.

Getting back to the original reason for this post, I’m in bad shape with Eclipse, I just can’t run it in PDT mode; its way too damn slow and I’m in a development mode working on a some nifty database binding tools for some form of “database-on-a-database” type of work allowing users to design and define their own forms to supplement our application’s OEM records.

Zend Studio

When we bought Zend Guard, the bundle included a license for Zend Studio. Having tried a demo, and liked it but been put off by the price, I thought it might be wise to give it another go. With the license cost issue out of the way, I had a great feeling when I launched the installer, I was seconds away from what I knew to be a good IDE!

I opted to not install the Zend Platform and its baggage because having read posts that describe the resulting massacre of your PHP and web server installations. I walk this plank a bit later, but first I’d like to finish with Zend Studio.

Zend Studio is a great IDE. It’s a Java app, its fast, and plows through all the scripts that would normally choke Eclipse. It has great code completion features and the code Outline (Eclipse calls it Outline, I’m away from my dev machine right now so I can’t get the right name) is very smart, walking included files and determining class types on the fly. It has a heap of really helpful tools like built in PHPDocumentor, CVS integration, Code Folding and really great contextual/syntax help to name a few.

Zend Studio has debugging capabilities too, I’ve seen them go and they are as good as (dare I say) Microsoft Visual Studio or .NET/ASP debugging with the ability to step lines of code and see and tweak your variables in state. I want(ed) this.

I don’t blame Zend Studio for what happened next.

I’ve been working on something mildly complex and I was having trouble obtaining the desired output as an object I was working with was getting its reference mangled at some point and I needed to see where. I thought this would be the perfect opportunity to use the debugging features included with Zend Studio. Right there, on the toolbar is an option to debug. I opt to try it and see how far off the installation is as I skipped the Zend Platform install. Yep, it wants to have Zend Platform installed first.

Alright, back to the Zend website for the Zend Platform. Unlike the previous Zend Platform, the latest wants something called Zend Core installed. Back to the website, and download Zend Core.

Zend Core gets installed, then everything goes to hell. My ISAPI PHP installation is now broken, but the web server is still answering PHP calls…. very slowly. Looking in the Task Manager reveals 5 to 10 “php-cgi.exe” processes. Trying to restart the IIS is a waste of time; it stalls and stops responding altogether. Reboots take forever, resulting in a big-red-button shutdown after 20 minutes of waiting.

Very little information exists about what exactly Zend Core does and what one should do to fix it when it goes wrong and I wasn’t really in the mood to start in on a support email conversation that would most likely drag on for weeks.

This is signals the end of my Zend debugging escapades, I don’t have the time or energy to devote in figuring out how Zend wants its fancy “cgi” PHP to be installed and why I should bother. I mean this PHP installation DOES work, but its the slowest thing ever, pages that would render in 0.05 seconds are now well past the 45 second mark which by even the worst standards is unacceptable. I’ve gone back to my PHP 5.2 in ISAPI mode on IIS for development purposes using Zend Studio as my daily-driver IDE and do my debugging using test-points and debug output from our home-brew inline debugger.

Zend, nobody outside your organization understands your product lines. They seem to make perfect sense to you but in my opinion the rest of the world does not really care nor do you try to make us care.

Zend, unify your products already. Get the Zend Optimizer in the PHP core… I mean it is you that wrote the PHP engine right? It’s not like you charge for it! Did someone screw up so bad that you need a separate product to optimize it? Have you deliberately added some inefficiencies that the Optimizer fixes? If so, SHAME and shenanigans on you. Zend Core, and Zend Platform … what’s next? Zend Framework? Uh! Oops! You beat me to it.

Zend, you need to fix the licensing scheme/software/mechanism on Zend Guard. You have to realize that this software is run by developers on development machines that are often changed, reformatted or have their partitions changed. I dread opening Zend Guard for fear that its license is invalid and I’ll have to deal with your support website.

Zend, your website is one of the slowest around. If your intent is to showcase Zend products for speed and efficiency then your website is not doing you any favors. Why do I need to login 2 or 3 times each visit? Have you not figured out how to pass authenticated sessions on between servers? I’d be more than happy to assess, explain and/or fix this for you under a consulting engagement.

Zend, Zend Studio is the best development IDE for PHP out there. If you really care about PHP, you need to cater to your developers. $299 is a bitter pill for many to swallow, don’t be so greedy with the tools that enable the people that keep you around. Microsoft is GIVING away its Express versions of it’s .NET IDE’s and they are quite good; too bad the language and OS aren’t my cup of tea.

I have a hard time being very critical of Zend as they are responsible for PHP and I make a good living as a PHP developer and application architect. Beyond the core Zend Engine and a debuggerless Zend Studio, Zend Technologies has done an excellent job of taking my money and killing my inner child. I’d love to get on-board with all this stuff, but just one thing after another leads to a certain reputation after awhile and it drives me bonkers!

- Paul

PHP Installation: A myriad of options

I suppose that a site that discusses PHP and Linux affairs should probably have some sort of documentation or links to reasonable how-tos on the subject. However, the thought of detailing a PHP/Apache/MySQL installation doesn’t appeal to me much either, so I’ll take a different slice on this. Rather than regurgitating the same steps as every other PHP How-To, I’ll talk about some configuration choices based on the machine’s role.

Alright then, you want to install PHP on your PC or “server” type machine. I’d hazard that you’re either already running Linux or have the misfortune of running Windows. While PHP runs on just about on hardware and OS combo, the Unix flavours perform better and seem to be more stable, not to mention there is less voodoo involved in making it work right.

In a nutshell, PHP is typically run in one of two different modes, either in CGI mode or SAPI mode.

In CGI mode, when a PHP page is called the webserver invokes the PHP executable to evaluate and execute the named script. The PHP binary is read into memory each time effectively isolating the execution. This mode is popular with certain ISP’s as it allows PHP to be further secured to client web home and configured to constrain to certain policies such memory and execution restrictions. There is some overhead performance cost with the CGI mode, but it is reliable and unlikely to knock over a shared host when properly configured. Most Windows IIS installations will run in CGI mode.

In SAPI mode things are a little different. The PHP code is complied into both a CGI and library form. This library is configured for use within the webserver and when PHP pages are being rendered, the in-memory library is used instead of an isolated process such as CGI mode. Under Apache, this seems to work great both on Linux and Windows. SAPI under Windows IIS tends to be a frustrating, futile exercise. PHP in SAPI mode tends to perform very well, less disk I/O overhead is achieved by taking full advantage of webserver caches, and optional PHP OpCode caches that further boost performance. In a shared environment it can be somewhat more complicated to configure some client restrictions and access rights, but there are many resources dedicated to locking-down PHP in these such configurations.

If you are a Windows user running IIS, don’t waste your time. Go with the standard CGI installation and save yourself the agony of running the SAPI module. PHP in CGI mode under Windows is bomb-proof and is very easy to install. Getting the SAPI to work under IIS isn’t all that difficult but it never seems to be very stable; no matter what, it will begin to complain about exception errors, and will open pop-up windows on the server complaining about something or other, sometimes locking up the webserver altogether. It just doesn’t seem to be very robust or clear if PHP is supposed to be production quality under IIS.

If you’re a Linux user, life is good for you in this regard. Check the details of your distribution, chances are there is a PHP package that can installed with only a few clicks of your mouse. Recently, Fedora Core has been my distro of choice and its PHP packages are great; they come compiled with all sorts of extras such as GD, LDAP and a few other neat-o extensions.

The next question that may come up is which version of PHP to install? PHP is currently being developed in 3 major versions, both  4, 5 and 6. At this time, PHP 4 support will be discontinued by the end of 2007 with only critical security fixes applied on a case-by-case basis until August 2008. PHP 5 is the way to go, its stable, production quality and has a future.

Compiling PHP from scratch is a good way to go on Linux but can be nuisance if it gets installed along side a pre-packaged file such as an RPM or if you have a lot of dependencies for extensions you need to include.

If you decide to roll-your-own PHP, I recommend starting from scratch; remove any repackaged webserver and PHP if already installed. Acquire the sources for PHP, Apache and any additional (-devel) dependencies for the extensions you want to build. I can’t really speak to compiling PHP under Win32 as I’ve never attempted it; there just doesn’t seem to be a good reason to do so, most extensions are precompiled and available from PHP.net directly.

Recommendations?

For a Windows based PHP developer, the PHP CGI under IIS works great and is easy to install and upgrade while not performing as well as similar hardware under Linux and Apache. Every time someone uses a Windows IIS MySQL PHP (WIMP) configuration in production, God kills a kitten. Just don’t do it.

For a Linux based PHP developer. You most likely have it the easiest of all. Depending on your distribution, it’ll probably only take you a few clicks using the package manager. If not, roll-your-own.

For Production purposes, a scratch built Apache 2.x and PHP5 SAPI running on Solaris/BSD/Linux compiled with only the required extensions. This is then optimized with an OpCode cache such as APC (Alternative PHP Cache) providing a robust and extremely fast PHP server capable of making short work of even the most complex PHP scripts.

Where to get platform specific installation info? Go straight to the horse’s mouth: PHP Installation Documentation