Tag Archives: PHP

Uploading files in WordPress on IIS – WTF moment.

There are whole slew of blog posts and technical articles on configuring IIS and windows permissions to enable file uploads in WordPress sites. I’ve read them before and had cause to re-visit them over the last couple of days as I struggled to get uploads working on this site. Whenever I attempt to upload a file, the site would just site their until an HTTP timeout message appeared. No HTTP 500, just a PHP timeout error.

My IIS and folder permissions were correct as were all the paths in php.ini. As I was testing tweaks or configuration changes, I could see the temporary files being written in the PHP temp folder. In other words, the actual PHP upload was working. Something was blocking the copying of these files to the WordPress site. Was it WordPress itself or a Windows permission?

To compound my confusion, WordPress’ own update functionality was working without a hitch, so this meant the site had the correct write permissions at least on the wp-content folder.

After several hours of fustration I found the problem and it wasn’t with IIS, PHP or Windows. It was with a WordPress setting. I eventually wandered over to WordPress’ Settings > Media and the uploads folder path contained a reference to a W drive. I have absolutely no idea where this has come from. This site has never been on a server with a W drive. However, once set back to the default of wp-content/uploads, file uploads worked again.

IIS FastCGI Fatal Error: Allocated memory size exhausted

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.


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.