End of PHP as an Apache Module?

Just noticed that you no longer have the choice of running PHP as an Apache Module when setting up a new domain at DreamHost. If you’re currently running PHP as an Apache Module nothing has changed, but you’re no longer able to choose Apache when setting up a new domain or making changes to an existing domain.

The Manage Domains form has been changed accordingly:

Manage Domains - With Apache Module settings
Before: Manage Domains – With Apache Module settings

Manage Domains - Without Apache Module settings
Now: Manage Domains – Without Apache Module settings

I haven’t seen any official explanation of this step yet, but I’ve seen two support replies with the following text:

Sorry about the confusion! All new domains added to the control panel (or ones you change settings for, like that) currently run as CGI. There’s no longer an option to choose PHP as an Apache module, so everything’s all CGI-upped.

We actually removed the Apache module feature as it turned out to be causing higher loads than the former. Go figure, huh?

Source: QiRan.org

I have to update the Wiki on that – we disabled the use of turning off PHP as CGI as this was becoming an issue since when you turn it off, your applications run under Apache’s memory space, which then makes it hard for us to determine who is using resources.

Source: DreamHost Discussion Forum

So currently it isn’t clear if the reason to stop offering PHP as an Apache Module is increasing use of resources, or difficulties tracking the use of resources or maybe both, but hopefully we will get an unambiguously explanation from DreamHost soon.

If you any more info on this change, please post a comment…

Make sure to read the comments for Pete’s explanation of the change (Pete is working for DreamHost Support).

25 Responses to “End of PHP as an Apache Module?”

  1. Joe says:

    I’ve just noticed that none of my PHP scripts work any longer. For the one noted above, it appears to work, but the email is never received. I also use a script called PHPFanBase and none of those emails are received either.

  2. Ant says:

    I read somewhere that running PHP as CGI can limit some things, like mod_rewrite. Think that’s essential for setting up decent descriptive (i.e. google-friendly) permalinks in Wordpress for example. Havent got around to confirming that myself yet. Can anyone else confirm?

  3. Unofficial DreamHost Blog says:

    Joe – I had the same problem. Emails from scripts (like comment notifications etc.) was apparently delayed yesterday, but I got all of them at once last night. I’m pretty sure it’s not related to the PHP/Apache change.

  4. Unofficial DreamHost Blog says:

    Ant – I can reject that. This blog is running on PHP as CGI and uses both mod_rewrite and pretty permalinks. See the Knowledge Base for the differences between PHP-CGI and PHP as an Apache module.

  5. AlarConcepts says:

    How is that?? I thought that mod_rewrite only got it’s directives from the .htaccess file (at least that’s how I do it!) …but if PHP is running as a CGI, our custom .htaccess is ignored. Are there directives somewhere up the tree that we can’t change, but can simply ‘use’ as necessary or how does that work?

  6. Steven says:

    AlarConcepts: You custom .htaccess is not ignored. Apached processes the .htaccess file before invoking php. PHP does not even know you have an .htaccess file.

    The only time I could see this causing problems, is if (like some scripts) PHP is handling the friendly urls is some weird way. This almost never should be the case.

  7. AlarConcepts says:

    Steven: I’ve created domains with PHP in both ways, but I can set an .htaccess directive to say, disable register_globals … however, upon viewing the phpinfo(), it revealed that the .htaccess was not applying in the CGI-based installation (as noted by the register_globals still being set to ‘on’ in spite of my directive). I’m not meaning anything overly complicated…

    The link given above about the diffs of each install says “Custom php directives in .htaccess files (php_include_dir /home/user;/home/user/example_dir) won’t work.

    I’m very familiar with rewriting URLs via .htaccess, but have avoided using PHP as a CGI because I was under the impression that I couldn’t do that… are you saying that this is wrong?

    Also, if URL rewriting is available for the PHP as a CGI, how do you enable or disable it? I prefer to develop with raw URLs. =)

  8. Pete Happy DreamHost Employee says:

    A little info for you guys.

    PHP as CGI runs under a somewhat strict suEXEC environment, which is why a lot of php-related .htaccess directives get ignored. mod_rewrite directives are definitely okay under CGI (I use them myself.) Sadly, that’s just the breaks on a shared server, where security and usability must be balanced.

    The email problem where PHP mail was not being delivered was because our policy service died. We now have a system in place that checks every minute for the possible death of the policy server and restarts it so that you guys won’t be interrupted anymore while we try to figure out what on earth is causing it to die in the middle of the night.

    Lastly, it would appear the “hip new thing” is to sign up for a DreamHost account, create 50 different subdomains, host a lot of crazy CPU-intensive scripts (discuz forums, anyone?) and hide it all under mod_php so linux’s accounting system thinks dhapache is hogging everything and we have no way to track down who’s really doing it (well, no easy way.) Existing sites can keep their mod_php, but if you switch away from it, it’ll disappear on you. New sites can only be PHP CGI. So many new servers were being torn apart by this behavior that we had to make a change — our newest signups were starting to wonder why our older signups had such great service and they didn’t! We told them we love all our children equally, but the server crashes just didn’t reflect that… so away mod_php goes. On the plus side, if you’re a new customer, you should see a reduction in server outages soon.

  9. Unofficial DreamHost Blog says:

    Pete – Thanks for your great explanations. Always nice to get answers directly from DreamHost here…

    AlarConcepts – Did Pete’s comment answers your questions?

  10. Kelvin says:

    First up, thanks for the informative article… I was wondering where the option had gone!

    Secondly – a problem… I was using a php_value auto_prepend_file with all my sites to automatically include my homegrown PHP framework… Unfortunately this .htaccess directive is ignored when PHP is running as a cgi :(

    Any ideas for a solution?


    Kelvin :)

  11. Unofficial DreamHost Blog says:

    Kelvin – You can still switch to the Apache-module by inserting: “AddType application/x-httpd-php .foo” or “AddHandler application/x-httpd-php .php“ in your .htaccess file. 

    There’s more info in the comments in the old kbase and in the discussion forum.

    Hope this helps you out…

  12. Chris says:

    Thank you all above…Hopefully Dh will not switch off apache_php module entirely…

  13. AlarConcepts says:

    UDB – Yea, I think so …

  14. Pete Happy DreamHost Employee says:

    Wow! I love the big blue box. Does this mean I qualify as a “blue response”? Hah.. just a little WoW humor there, if you’re familiar with the game.

    Due to the sheer volume of people using mod_php, I don’t see us disabling it entirely any time soon.. However, I would not be surprised if there were NEW servers being created without it, and if brand new signups would eventually be unable to use the AddType or AddHandler method. mod_php is a shared hosting nightmare unfortunately.

    Something I’d like to see some time is a PHP FastCGI setup contributed to our Wiki that actually works. We have one but it doesn’t really seem to speed anything up (perhaps I’m doing it wrong.) PHP-FCGI is ultimately the best solution for people that need high performance.

  15. Unofficial DreamHost Blog says:

    That’s a deal. Pete’s and Jeff’s answers are now called a “blue response”. Wasn’t familiar with the World of Warcraft lingo, but Wikipedia to the rescue!

  16. Justin Grote says:

    Hey Pete, I just today found a way to set up FastCGI in such a way that you can use your own php.ini and, subsequently, your own extensions with the Dreamhost-provided PHP. As such, I was able to run the APC extension to pre-cache my pages, and boy did it make a difference.

    I cannot however get it to run a custom php binary through FastCGI, it has to use the Dreamhost-provided one for some reason. I think maybe I just screwed up somewhere in my PHP compilation, there shouldn’t be any reason it wouldn’t run with my custom one.

    Check out my site on the basic hosting plan running Joomla. It screams compared to a one-click install version of Joomla:


    My APC caching stats are here (temporarily) so you can see how well the cache is working:

    I’ll put up a wiki article once I refine the process, it currently involves building an entirely new custom PHP in your home directory. I may temporarily just provide easy extension binaries and a one-click install script to get your sites screaming on FastCGI/APC.

  17. Craig says:

    I’m trying to set up phpicalendar on my dh account and I think this discussion might have to do with the problems I’m having with webdav and permissions.

    Can anyone point me in the right direction to find the proper way to allow my phpicalendar pages view the .ics files withing my webdav directory which is owned by dapache?


  18. Floren says:

    Justin, do you have a howto for the APC install?
    I compiled APC on DreamHost with no problems… I have my own PHP version compiled also with FastCGI enabled.
    However, I don’t see APC info in the phpinfo file.

    Thanks for helping,


  19. Floren says:

    This is what I did so far:

    [server]$ mkdir src
    [server]$ cd src
    [server]$ dir
    [server]$ wget http://pecl.php.net/get/APC-3.0.10.tgz
    [server]$ gunzip -c APC-3.0.10.tgz | tar xf –
    [server]$ cd APC-3.0.10
    [server]$ /home/dreamuser/local/bin/phpize
    [server]$ ./configure –enable-apc –enable-apc-mmap –with-php-config=/home/dreamuser/local/bin/php-config
    [server]$ make
    [server]$ make install
    [server]$ cp /home/dreamuser/local/lib/php/extensions/no-debug-non-zts-20050922/apc.so /home/dreamuser/local/lib

    In php.ini, I added the following lines, under Dynamic Extensions:
    ; APC
    extension = “apc.so”
    apc.shm_size = 16

    Now, I don’t need to define the /php/extensions/no-debug-non-zts-20050922 folder because my extension_dir is automatically recognized in /local/lib folder.

  20. Nite says:

    If you look closely at your APC.php file, how long is the uptime ? When I installed it, my uptime would always be 0.

    Still looking forward to the tutorial.

    ” ./configure –enable-apc –enable-apc-mmap –with-php-config=/home/dreamuser/local/bin/php-config ” is what you’re using ? You don’t error out because you don’t have two dashes in front of the enable ? Example : -enable-apc VS –enable-apc ?

    How’d you know to use apc.shm_size = 16 ?

  21. Nite says:

    I nailed it.

    I got aPC to work.

    Props goes out to Justin Grote !

  22. nite says:

    It seems to me that the latest CVS of eAccelerator feels snappier than APC.

    Once you get everything installed with the proper install script, you can install whatever accelerator you want… all you do is comment out the accelerator coding inside the php.ini file with a ‘;’ when you want to disable it.

    If you’re using APC, be sure you copy the apc.php file sound inside the sources directory to the root of your domain name inside your ftp client so that you can load it up in a web browser. And if you’re using eA, the file is named control.php — but eA doesn’t have a graphical display like APC does.

  23. Anthony says:

    They don’t seem to have any problems running mod_php for shared hosting at Jumpline. I am a DH and Jumpline customer, and have never built sites – at three different hosts – using PHP-CGI. I wonder why is this a problem for DH now?

  24. Dave says:

    Those of you who have been able to get APC running on your php installs – it sure would be nice to see how you did it. thanks.

  25. Linked from: The Unofficial DreamHost Blog 1 Year