FIXED: The Problem with running PHP as FastCGI Application (WordPress and Plesk)

We’re currently on our way to Kissimmee, FL to join Parallels Summmit, an annual conference from the people who make Plesk. We’re also taking exams in Plesk 10.4.4 so we’re studying it in-depth – I’ve been using the software for over two years now but never had formal training in it. Well here goes!

In preparation for the exam tomorrow I’ve come across something the instructor mentioned: namely the benefits of running PHP as a FastCGI application instead of an Apache module. Sadly I’ve also come across some drawbacks when using this option in regards to WordPress. I thought I’d mention those here, alongside how to avoid those.

UPDATE: Thanks to Boldock this problem can be fixed 😉

Apache Module vs. FastCGI

First of all let’s have a look at why you’d want to run PHP as anything other than an Apache module. More times than I can count I’ve had to tweak ownership or file permissions in WordPress installations to make WordPress read / write / amend files – it needs this to use many of the cool features, such image uploads or one-click upgrades.

If PHP is run as an Apache Module, then when WordPress creates a file it does this as the “apache” user. Similarly, when it needs overwrite files it needs those files to be writable by the Apache group, or the files need to be owned by “apache” (or they need to be 777 so that everyone can overwrite them – which is not good).

If PHP would instead be run as FastCGI, then the actual file owner of the account could let PHP write to it’s own files – they woulnd’t need to be “apache” owned nor writable. That’s great news. Imagine you had 100 websites and all files would be owned by “apache” – it would be a nightmare to track down if a script has gone awry which site it originated from. Therefore, FastCGI is a dream come true. If it would work properly that is.

The Drawbacks for WordPress

Turns out that there are also a couple of drawbacks in regards to WordPress when it comes to using this new Plesk feature:

I tried to install a theme via the ZIP uploader (Over Easy by Woo Themes, it’s 909k in size so not very big), and all I got was a reproducible 500 Internal Server Error. This did not happen when I switched PHP back to being run as an Apache Module.

Also, mobile posting via WordPress for iOS does not work for image sizes large and above. Small and medium sizes still work, but the app gives a “Blog returned invalid data” error – not so when run as an Apache Module.

This could be a bug in Plesk, this could be a memory problem somewhere – I’ll certainly bring it up at the summit. Maybe all uploads of a certain size have a problem, even though it’s not related to the PHP max memory sizes (if tested it with up to 6GB!).

The Solution

The reason this seems to be happening is that FastCGI is running low on memory. By default the Apache configuration does not include a statement to allocate enough memory, but we can do this by adding the following line to httpd.conf (thanks to Baldock for this tip):

Restart Apache with “service httpd restart” and all your troubles go away.

Conclusion

FastCGI is a great idea in principle, and if your applications play ball then I’d vote for this option any time. However, if things don’t work out you need to find another way.

Adding the above to your apache config is one option, but only possible if you’re running a dedicated server or VPS. If that’s not the case, you can also switch PHP back to be run as standard CGI Application. It still works fine and provides site isolation over an Apache module.

There are a few other options you have: suPHP, mod_ruid2 and mpm-itk are things to look into, but that’s a bit more hard core to implement. See below for this suggestion from the Parallels Forum.

If everything else fails, I’m afraid you’re stuck with an Apache module and file permission hell.

Either way, stay sane…

Further Reading

Here are some useful links discussing this issue. I’ll add my own future findings on the comments below – feel free contribute.

About Jay Versluis

Jay is a medical miracle known as a Super Survivor. He runs two YouTube channels, five websites and several podcast feeds. To see what else he's up to, and to support him on his mission to make the world a better place, check out his Patreon Campaign.

30 thoughts on “FIXED: The Problem with running PHP as FastCGI Application (WordPress and Plesk)

  1. UPDATE:

    FastCGI appears to have some memory problem when it comes to uploading a file. Under Apache, I’ve never had a problem as long as the MAX POST SIZE and MAX FILE SIZE values are above the file I’m uploading.

    With FastCGI I can upload files up to 300kB or so, but everything above it returns a 500 Internal Server Error. This explains the mobile posting problem above. The 500 error happens with the WordPress media uploader as well as when you’re trying to upload a plugin or theme.

  2. first i will introduce me: I’m working hard to do something like you in france … not ready yet, but soon … so i’m very interested in your blog ;p

    For your problem you should had this on yout httpd.conf

    FcgidMaxRequestLen 33554432

    it works for me!

    1. Hi boldock,

      lovely to hear from you, and I’m glad all my notes will be put to good use in France 😉

      I’ve just added your line to my httpd.conf and IT WORKS!!! That’s awesome news – thank you so much for sharing the knowledge! I’ve done a quick search for this on Google and it’s one of the rather difficult pieces to get information about. Maybe this should become a standard setting in every httpd.conf file.

      On CentOS, this file is in /etc/httpd/conf/httpd.conf (just so I’ll remember).

    2. Thank you soooo much for this. I’ve been trying to figure out how to fix the memory limit error for weeks. Because it’s such a common error everybody just says “increase the limit” your solution worked!

    1. Thanks for the tip, sounds great indeed! Just to let other readers know this is not a free solution, there’s a one-off charge of $59.95 per instance. Silly question: does this work with dedicated machines?

  3. I have a problem that I can’t find where to add this line

    and conf folder is protected and it keeps saying permission denied

    Plesk v.11 with godaddy

    Thanks in advance.

      1. Could be that you’re in a VPS instead of a dedicated box. I think even though they give you full root access to a VPS certain directories are protected in such a setup.

        I think stuff like the conf and etc directory are governed by a higher node to protect the overall system (a VPS is usually one of about 100 instances on one machine). Have a word with Godaddy and see if they can help.

  4. Hey guys. I know this post is a couple months old but I’m going nuts over here and I don’t know many people using Apache with FastCGI for their PHP processing.

    I recently updated to PHP 5.4 and I cannot run the WP upgrade at all. Some of my sites are running WP 3.4.2 and when I try to update to 3.5, I receive this funky error in my Apache error_log:

    Creating default object from empty value in /var/www/mysite.com/wp-admin/includes/update.php on line 90, referer: http://mysite.com/wp-admin/update-core.php

    I’ve read about some patches to the WP core, but my code looks consistent with the patch. I run in to various PHP strict errors, usually due to plugins that need to be updated. Even after deactivating all my plugins and trying to run the update, I still receive that error.

    The weird thing is, WP totally says that the update is successful, yet it takes me right back to the ‘Welcome to WordPress 3.4.2’ screen instead of 3.5.

    1. Hi Mark,

      That is bizarre indeed – I would have thought PHP 5.4.x would work fine with WordPress. I’ve seen several posts pointing to the contrary though. Just to make sure it’s not the FastCGI module, have you tried running PHP as CGI or even Apache Module (if you can choose that is)? Worth trying to see if the upgrade works. If not I’d try

      yum downgrade php

Add your voice!