possible fix for the CGI problem

Friday 05 March 2004 3:27:59 am

Hi,
Having investigated what was going on with the CGI issue, I have come to a simple solution which seems to work well in my case. It should be noted that I have only tested this in a 3.3-3 setup which has url rewriting enabled, so i'm not sure how it will work for any other setup. Usual disclaimers apply.

in /lib/ezutils/classes/ezsys.php change line 703 from;

$phpSelf = eZSys::serverVariable( 'PHP_SELF' );

to;

if(isset($_SERVER['_'])){
//we are running as a cgi
$phpSelf = eZSys::serverVariable( 'REQUEST_URI' );
}else{
//we are running as a module
$phpSelf = eZSys::serverVariable( 'PHP_SELF' );
}

and that's it. It seems like the PHP_SELF variable is not set in the CGI, but on initial investigation it is the same as the REQUEST_URI variable. By checking if it is a CGI (by testing for the _ variable) we can choose between these options. So, try it out and see if it works in your situation and report back. Maybe it will need combining with the other patch which is floating around. Let's try to fix this annoying problem which seems to be affecting quite a lot of people.

As I said, my site is working well now. Hope yours does too :-)

All the best,

Ben Pirt

PS I'm sure this doesn't conform to eZ coding standards, so if someone wants to make it comply and post back, that would be great.

Monday 08 March 2004 1:24:22 am

Glad to hear that CGI support is in 3.4
For now though, if we do this;

if (php_sapi_name() == 'cgi')
//we are running as a cgi
$phpSelf = eZSys::serverVariable( 'REQUEST_URI' );
}else{
//we are running as a module
$phpSelf = eZSys::serverVariable( 'PHP_SELF' );
}

eZ publish 3.3 will run on a CGI setup too.
Thanks for the tip on php_sapi_name,
All the best,
Ben Pirt