Welcome, Guest. [ Log In ]
Question   What's the difference between PHP-CGI and PHP as an Apache module?
Search KBase

Top 5 in this Area:
1. What's the difference between PHP-CGI and PHP as an Apache module?
2. PHP Security
3. Compiling your own custom PHP
4. Can I run a phpbb forum (message board) on my site?
5. Do you support this PHP module or extension?

What's the difference between PHP-CGI and PHP as an Apache module?
There are two ways you can choose to have your PHP executed at DreamHost. The default for new customers is now PHP-CGI. This is by far the preferred method. The benefits of running PHP-CGI are:
  • It is more secure. The PHP runs as your user rather than dhapache. That means you can put your database passwords in a file readable only by you and your php scripts can still access it!
  • It is more flexible. Because of security concerns when running PHP as an Apache module (which means it runs as our dhapache user), we have disabled a number of commands with the non-CGI PHP. This will cause installation problems with certain popular PHP scripts (such as Gallery) if you choose to run PHP not as a CGI!
  • It's just as fast as running PHP as an Apache module, and we include more default libraries.
There are a FEW VERY MINOR drawbacks to running PHP-CGI. They are:
  • Custom 404 pages won't work for .php files with PHP-CGI. Or will they? See n74's comment below!
  • Variables in the URL which are not regular ?foo=bar variables won't work without using mod_rewrite (example.com/blah.php/username/info/variable).
  • Custom php directives in .htaccess files (php_include_dir /home/user;/home/user/example_dir) won't work.
  • The $_SERVER['SCRIPT_NAME'] variable will return the php.cgi binary rather than the name of your script
If one of those is a show-stopper for you, you can easily switch to running PHP as an Apache module and not CGI, but be prepared for a bunch of potential security and ease-of-use issues! If you don't know what any of these drawbacks mean, you're fine just using the default setting of PHP-CGI and not worrying about anything!

Last updated: Nov 25, 2005.

Official Reply (2004-06-15 13:45:44 )
If you've been with Dreamhost for a long time PHP-CGI IS NOT THE DEFAULT. Check your domains.
User Post (2005-12-27 02:11:58 by flameboyc11)
I just want to point out that there is an issue with using system() and exec() if you are trying to call a php page and you have PHP-CGI enabled. It will call the script over and over again, but not complete until the thead is killed by some unknown (to me) process.

You can learn more about this problem by going here => http://bugs.php.net/bug.php?id=11430 It took me some time to find this out (after having my db hammered by thousands of inserts for no reason).
User Post (2005-12-24 18:30:29 by akrobotics)
I am new to DH and need to set up egroupware. DH's set up is entirey new to me and I don't want to be banging my head against open_basedir and other issues (some of which have been raised above....) Has anyone here set up egw at DH and if so, what might be your best guess as the smoothest way to address the issues above as well as anything else you might have to offer....
User Post (2005-12-07 08:21:57 by kizuki06)
Hi, has anyone experience problems with the Xoops script? I am not able to see the index.php
Thanks for any help
User Post (2005-12-06 09:52:18 by hughbiquitous)
iwein's post on MediaWiki was helpful, but needed a little enhancement:

.htaccess should look like this:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php?title=$1 [L,QSA]

Note the last line. Where I have /index.php, you may have /wiki/index.php, or whatever... the point is that it is the fully-rooted path under your domain.

Then, LocalSettings.php needs to have this:

$wgScriptPath = "";
$wgScript = "$wgScriptPath";
$wgRedirectScript = "$wgScriptPath/redirect.php";

## If using PHP as a CGI module, use the ugly URLs
$wgArticlePath = "$wgScript/$1";
#$wgArticlePath = "$wgScript?title=$1";

Basically it's just changing $wgScript to your rooted path again, and flipping the comments on the last two lines.

User Post (2005-11-30 13:20:25 by mooretimes)
For anyone using Gallery 1.5 with PHP-GGI here is what I had to to do to get clean URLS:

During gallery config, ignore the warnings and config as usual.

edit /gallery/.htaccess like so:

# BEGIN Gallery section
# (Automatically generated. Do not edit this section)
# Note: still under development, so format may change.
# If you edit this file, make a backup before runnng the Config. Wizard.

# END Gallery section. Add User changes below this line
AddType application/x-httpd-php .php

php_value post_max_size 20971520
php_value upload_max_filesize 20971520
php_value magic_quotes_gpc off
php_value session.save_handler files
php_value register_globals off

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /gallery/

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)/([0-9]+)$ /gallery/view_photo.php?set_albumName=$1&index=$2 [QSA]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)/([A-Za-z_0-9\-]+)$ /gallery/view_photo.php?set_albumName=$1&id=$2 [QSA]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)/$ /gallery/$1 [R]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^\.\?/]+)$ /gallery/view_album.php?set_albumName=$1 [QSA]

Add this line to your domain .htaccess:

AddType application/x-httpd-php .php

Edit the gallery config.php and enable rewrite:

$gallery->app->feature["rewrite"] = 1;

If it doesn't work the first time through. I had to do these steps a few times before it started working. Weird, I know.

User Post (2005-11-27 17:37:01 by snarkie)
If you're trying to run STS on an osCommerce install (which is pretty much anyone using osCommerce) and finding that nothing but the default template works, PHP-CGI is likely the culprit. Because $_SERVER['SCRIPT_NAME'] returns "php.cgi" no matter what, STS goes looking for "php.cgi.html" as the template name for EVERY page of osCommerce, instead of searching for "product_info.php.html" or "index.php.phtml," etc. like it should.

Posting a very easy fix here in case anyone comes across this document looking for help like I did. :) Basically the same var changes posted above for other applications. No need to turn off PHP-CGI! Just make the following change.

File: catalog/includes/sts_display_output.php
Line: 47 or so

$scriptname = getenv('SCRIPT_NAME');
$scriptname = getenv('SCRIPT_URL');

Your custom templates should work fine now. Huzzah!
User Post (2005-10-15 10:35:45 by hmap)
I think it's also woth noting that my custom error page (404, at least) works just fine at DH without modification from the get go. Hmm. I'll try adding my own php.ini.
User Post (2005-10-15 10:16:45 by hmap)
After switching to DH, I get a malformed XML error when first loading my site in FF. My site is also no longer valid XHTML, due to the SESSION ID being passed in the url which fouls up the validation. I have a php flag in my .htaccess file which turned off use_trans_sid when PHP was running as an apache module, but I'm assuming this is ignored by this PHP running as CGI.

How can I fix this at DH?
User Post (2005-08-07 03:43:39 by sykong)
The patch by veganarian doesn't work for me. In fact, the one given by n74 works even with parameters in the url.

Only thing is I had to add another line when the url is a directory so that users are not directed to the error page but to my index.php file.


RewriteEngine On
RewriteRule (.+) /404.html
User Post (2005-06-27 17:34:29 by fullo)
the easiest way is to include in the .htaccess this php.ini directive

php_flag cgi.fix_pathinfo 1
User Post (2005-06-11 11:22:20 by auxblood)
Does anybody know if "jproulx"'s solution of adding the following line to .htaccess would allow me to use auto_prepend_file when running PHP as CGI:

AddType application/x-httpd-php .foo

I need to keep running PHP as CGI because I'm using exec() in a few places, but I'm trying to figure out a way to still use auto_prepend_file and auto_append_file which apparently only work under Apache.
User Post (2005-04-22 09:20:17 by iwein)
If you want to run MediaWiki with php-cgi and use clean URLs, this is the way to do it (I think)

Here's your public_html/wiki/.htaccess:

cat .htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /wiki/index.php?title=$1 [L,QSA]

And here's the one change I made in your LocalSettings.php:

## If using PHP as a CGI module, use the ugly URLs
$wgArticlePath = "$wgScriptPath/$1";
#$wgArticlePath = "$wgScript?title=$1";

And now all of the non-hardcoded index.php URLs work fine

Found this here: http://forum.textdrive.com/viewtopic.php?pid=24398#p24398
User Post (2005-04-13 15:35:58 by veganarian)
I would like to make a patch/fix to n74's fix. The following line:
Rewritecond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
should be either:
RewriteCond %{SCRIPT_NAME} !-f

The reason for this change: n74's initial version tried to see if a file existed, like it should, but it did not properly account for parameters in the URL (i.e., file.php?arg=value). The following data shows a sample of how'd the values used above would look like (sample random data).

DOCUMENT_ROOT /home/user/webroot/
SCRIPT_NAME /home/user/webroot/folder/file.php
SCRIPT_FILENAME /folder/file.php
REQUEST_URI /folder/file.php?argument=value

You may test this if you wish.

Additionally, to the end of the rewrite rule, you might want to add "[QSA]" (without the quotes) to append the Query String (the ?argument=value part) to the rewritten URL. For a generic 404 error page, as the original was designed for, this would not be necessary.

So, to finish up, I provide you with an improved version

# Start 404 error page
<IfModule mod_rewrite.c>
RewriteEngine On

##this next part was submitted by n74 at ?area=2933
##it solves the "No input file specified" issue
# RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f #this fails with any GET parameters
RewriteCond %{SCRIPT_NAME} !-f
RewriteRule (.+) /404.phpx?request=$1 [PT]

Hope that helps
User Post (2005-03-21 00:31:54 by streetcar)
does anyone know if this would affect phpicalendar? i'm really php-lame and don't know where to begin checking the code..
User Post (2005-02-12 22:33:52 by chompy)
Another feature that won't work with PHP-CGI is the ability to hook into HTTP Basic Authentication with PHP. Luckily, jproulx's tip (above) works beautifully when you want your site to use PHP-CGI, but you need to run PHP as an Apache module in special cases.
User Post (2004-12-16 09:48:55 by trevorturk)
In Wordpress, adding:
at the second line of your wp-config.php file seems to help.
User Post (2004-11-11 02:31:28 by n74)
Good news everybody... I think I solved the "No input file specified", no custom 404 pages for .php files problem:

# in /home/user/yourdomain/.htaccess
ErrorDocument 404 /404.html
RewriteEngine on
Rewritecond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteRule \.php$ /404.html

Simply change either /404.html to anything you'd like...
I hope this helps. (oh and change .php to .phtml or .php3 if you need to)
User Post (2004-10-25 08:58:47 by jam_dan)
I have switched off the "Run PHP as CGI?" in hopes of remedying the open_basedir in effect problem .... From what I've read thus far, I don't see where the really serious security risks to doing this might be .... unless we are talking about other DH users that might have disabled the CGI as well, does that mean that people can access other's account filesystems through PHP scripts? Sure, that would be quite a security risk ..... is this the case, and is there a way around it?
User Post (2004-09-26 16:12:16 by quern)
Getting mod_rewrite to work with PHP-CGI:

Like many on the forums, I've bashed my head against a brick wall trying to follow install information for various scripts and their .htaccess RewriteRules. By trial and error, the following does what I expect in .htaccess:

RewriteEngine on
RewriteRule ^(.*)$ wiki.php?title=$1 [L,QSA]

That is, <http://mydomain.com/Main> is served from <http://mydomain.com/wiki.php?title=Main>
User Post (2004-08-26 08:29:50 by jproulx)
If you want to keep some of the same functionality of running PHP as an Apache Module with a PHP-CGI enabled account, you can put the following line in your .htaccess file

AddType application/x-httpd-php .foo

Anything with a .foo extension in your site directory will be run against the PHP Apache Module, so you'll have access to proper $_SERVER variables and certain php apache_* functions.
User Post (2004-08-06 15:29:13 by teamchachi)
If you're using php-cgi there is an easy work-around for the .htaccess php_include_dir problem:

ini_set("include_path", ".:/path/to/directory" );

ini_set() allows you to temporarily override the include path settings in the php.ini

It also works for overriding a lot of other settings in the default php.ini as well...

Just add this code to any page in your PHP application that requires an include path.
User Post (2004-07-23 08:50:22 by cherrypj)
This fix is especially important if you use Wordpress (http://wordpress.org) and want to install the Exhibit plugin (http://www.asymptomatic.net/wp-hacks).

In exhibit10.php, there is a block of code near the very beginning (line 46) that says:


Remove that whole block and replace it with:

User Post (2004-06-20 15:49:15 by mdpaciga)
If you compile your own PHP CGI, it's possible to fix two of the drawbacks listed above:

- Variables in the URL (example.com/blah.php/username/info/variable)
- $_SERVER['SCRIPT_NAME'] returning php.cgi rather than your script.

To fix these issues, add the following to your php.ini:


I don't know if there are drawbacks to using this, but it fixed my script problems.
User Post (2004-06-17 00:56:04 by cliffclof)

----------R E A D T H E A B O V E----------

I've been with dreamhost for so long my 'Run PHP as CGI' was unchecked and I never thought to read user comments. Expected the simple answer to be near the top.

Whew. Dreamhost you ROCK! Lovin it.
User Post (2004-05-25 18:11:34 by rols)
and of course none of the php apache functions, like apache_note, apache_setenv & virtual work in CGI mode. Those functions can be very
useful for passing data around between handlers or serving up
dynamic content.
User Post (2004-05-25 03:11:01 by draknek)
I misunderstood the first drawback, so I'll elaborate to prevent others being confused.

You can still use a PHP script to customise your 404 error page.
The problem mentioned is that if someone tries to access a .php page that does not exist, rather than the normal 404 error page, they will simply see "No input file specified."

I hope this prevents others making the same mistake I did.
User Post (2004-04-08 10:41:12 by dasil003)
There is also one very major drawback which compromises a great many scripts out there:

The variables $_SERVER['SCRIPT_FILENAME'] and $_SERVER['SCRIPT_NAME'] no longer refer to your PHP script, but to Dreamhost's php.cgi script. You can fix this by explicitly assigning new values to them. There are quite a few variables that tend to have the same value but can vary according to circumstance, and Dreamhost's setup is a prime example. So the following may work for you or not.


Also if your script uses $HTTP_SERVER_VARS instead of the newer $_SERVER then you need to set those values also as they DO NOT refer to the same value if you change one.

Note that SCRIPT_URL under Dreamhost's config is generally the same as PATH_INFO. The exception is if you have re-write rules so that you can use PATH_INFO 'normally', then SCRIPT_URL will contain that PATH_INFO (probably not desirable for most scripts). In such a case you have two other options for a SCRIPT_URL without additional PATH_INFO tacked on. The first is to simply use PATH_INFO (ironically re-used by Dreamhost without the real PATH_INFO attached), but that is highly dependent on the peculiarities of DH. I think the better variable is REDIRECT_URL, because that would work for any kind of internal rewrites in addition to Dreamhost's rewrites.

I know this is all terribly confusing. I'm planning on writing an in-depth analysis of server PHP file variables, becuase I havne't been able to find any documentation on the nuances of it yet.