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.

Jay is the CEO and founder of WP Hosting, a boutique style managed WordPress hosting and support service. He has been working with Plesk since version 9 and is a qualified Parallels Automation Professional. In his spare time he likes to develop iOS apps and WordPress plugins, or draw on tablet devices. He blogs about his coding journey at http://wpguru.co.uk and http://pinkstone.co.uk.

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

  1. Hi.
    How you configure Plesk to run fastcgi ? I’m trying to use apc cache, but Parallels says that is not compatible.

    1. Hi Diego,

      You can change this under Hosting Settings in the individual subscription, or in the hosting plan and then update several subscriptions at once.

      You can choose to run PHP as a classic Apache Module, FastCGI or CGI. The problem I’ve described in this article has thankfully been fixed as of Plesk 11.

  2. Can u explain how to set fastcgi with Plesk? Can not find that option?
    It would be nice if someone write article how to setup MPM with plesk (who claim to not support it). Also SQL optimisation article would be great!

    1. Hi Luka,

      Sure thing: you can find the FastCGI option under Service Plans – select a plan – Hosting Parameters – Scripting. There’s a dropdown menu which lets you choose how to run PHP scripts (options are Apache Module, CGI and FastCGI).

  3. Hi,
    I need for compatibility the direct php apache modul with the version 5.6.6 or 5.6.7.

    Every one how I can to tat?

    I can php update only for cgi / fastcgi in drop down (with Plesk), but not direkt for the apache php.

    Can you help …

    Thanks ahead Frank.

    1. Hi Frank,

      I can’t tell you how, but I can tell you why: when Plesk runs PHP as CGI or FastCGI module, it is executed as the subscription’s system user and not as Apache. Therefore, when you add multiple versions of PHP to Plesk that way, the actual Apache daemon is not affected by that change. The system wide Apache version number depends on the distribution’s vendor packages.

      The only two distributions I know of that support PHP 5.6.6 / 5.6.7 right now are Fedora (rawhide) and Debian (Jessie). Both are in beta stages at the time of writing. If you desperately need PHP 5.6 for the overall Apache daemon on your Plesk system, your only option is to completely remove it from the system and compile it from source (good luck with that).

  4. Hi Jay,

    Im hopefull to compile in plesk same like cgi & fast cgi php (drop down menu) in Plesk…
    Only with Apache2 php with drop down menu to switch version.

    The problem is, my programmer written a very big PHP, the script load arround 7.000 articels to my shopsystem, and this works only with Apache2 PHP, not with CGI or fastCGI, CGI and fastcgi brocken the transfer after 12min….

    Thanks for you’re information…

    Thanks for luck ;)…
    Greadings Frank.

  5. Hi,

    I compiled again and again, and now works with CGI :)…

    … I hope it will work if I recompile again :).

    I can say now, It works better, als only with Apache2!

    Maybe it’s the engine.

    Nice Weekend and Greedings Frank.

  6. So the PHP files are all owned by the same web user that runs them? That is very convenient. But what a security nightmare – one tiny chink in the armour of one script, and you have a rampant hacker putting backdoors into every, single, PHP script on that site. There is a reason why you need to mess around with file and directory permissions to get a site running. That reason is security.

    1. Your comment is a bit off-topic here, but isn’t that the point of running PHP as CGI module or using suPHP? So that every website is run as a separate user? Otherwise ALL websites would be run by Apache, and THAT is the security nightmare you’re talking about.

Add your voice!