Traditionally IIS and PHP have not mixed particularly well.  Things have gotten a lot better since the arrival of FastCGI and the Web Platform Installer, but there are still occasions when something occurs which flummoxes an ASP.Net guy like myself.

I recently moved this blog onto a Windows 2008 R2 server running IIS 7.5.  I’ll admit that I wasn’t really expecting any problems as I had already moved a MyBB forum onto the same server without any problems.  My normal level of IT paranoia had taken a leave of absence as I made the assumption that MyBB would be a far more demanding PHP application than WordPress, so there shouldn’t be any issues.

You know what they say about assumptions?  After all the data and files had been migrated I fired up my browser and initially got a blank page in return.  By default, FastCGI PHP does not return error messages – it is after all running on a production server.  So I dropped the following code into the top of the wp-config.php to manually enable errors.

ini_set('display_errors',true);

This duly returned the following error message:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 261904 bytes) in C:\inetpub\HostingSpaces\alexanderjohn\alexanderjohn.co.uk\wwwroot\wp-includes\functions.php on line 2109

Now, any quick Google search on this will immediately return a series of results all recommending the solution being to increase the memory_limit value in the php.ini from 128MB as the likely source is probably memory leaks in PHP.  This did seem a little counter intuitive – does WordPress really need that much memory?  I duly increase it several times, and each time I got a variation on the above error – all that changed was the Allowed memory size value increased to match the memory_limit value.

My next step was to check the various application pool settings.  They were all fine, and the site still refused to work with a new, dedicated pool.

Realistically, this only left WordPress as the culprit.  I duly downloaded the latest version and performed a manual upgrade.  Still no luck.

I then stripped out all the additional plugins and themes that were installed, and Hey Presto!, there was life.

I don’t know which plugin caused the problem as I have taken this opportunity to re-evaluate every plugin I was using.  This is something that I hadn’t done in a while, and to be honest, was well overdue.

As for the root core cause.  I would suspect that this down to some form of infinite loop.  If it is so, I am amazed that some developers are still adding iterations without some form of safety net.  At Calzada, it is actually part of our coding practice that any loop that has the potential of going infinite has some form of safety net.  At the end of the day, it is very hard to look professional to a customer when a product fails because of a very simple coding error.