Forums / Install & configuration / Breakthrough? That widespread "not beyond the opening screen" problem

Breakthrough? That widespread "not beyond the opening screen" problem

« 
Previous topic
|
Install & configuration
|
Next topic
 »
Author Message

Peter Quennell

Friday 21 May 2004 4:26:31 am

We also have (or rather, had) what seems the widespread frustration here of the Install getting us to the opening screen and then no further.

We have studied the very hard work of others on these forums to nail this one. Now we think we can share a solution that makes the difference. It would now seem to allow EZ Publish to be run with any hoster.

It's courtesy of our tremendous hosters, Internet Connection, in Maryland USA, and Geo Carncross, their talented chief programmer. (Dear EZP Inc & Community: if they do have it right, please give them due credit?)

So we had the problem. Our developer tried various things, and then he read here that it might be impossible to run EZ Publish with those hosters (a large majority we would think) that are offering PHP as a CGI with suEXEC.

So he referred the possibility (or the impossibility) to Internet Connection - and within two hours, Geo Carncross had our problem solved, the installation rock-solid, and this explanation:

***

This is my first experience with this software....

[Yes] on our systems, PHP is installed as a CGI [and] SuEXEC is installed....

There is a bug in ezPublish, in lib/ezutils/classes/ezsys.php line 768 which references (originally) $phpSelf but should use $requestURI - this is because $phpSelf will _OFTEN_ contain how PHP and this page can be
called again, but it won't contain the path information.

I have fixed this bug for you, but you should consider submitting it to the makers of ezPublish as other people certainly are having this problem.

***

We are now sure hoping this helps the community - and EZP Inc of course, who have come up with such an impressive product.

 

James Packham

Friday 21 May 2004 4:50:30 am

You should really submit this as a bug and offer your suggested fix, if you want to make sure that the ez crew give it a look over - The forums are community supported, so there's no guarantee that they'll read this.

If you've already done this (I had a quick look in the bug reports and couldn't see it) then you can probably ignore this :)

Regards,

James

Peter Quennell

Friday 21 May 2004 7:51:01 am

James:

Excellent suggesstion. I will try to do something useful overn there.

I'm really just the amateur here - the corporate manager - and normally just lurk.

But I did find some 30 posts in half a dozen threads on this same problem, earlier in this forum.

***

There is an important addition to the above fix from Geo Carncross of internetconnection.net

[quote]

It helps that I'm familiar with similarly shaped problems...

One also needs their [EZ Publish's] php.ini file to contain: cgi.fix_pathinfo=1

[/quote]

Nick B

Sunday 15 August 2004 10:37:01 pm

Hi Peter,

Can you tell us whether this was fixed in the latest version or not? Also, the line numbers have changed so I can't try to apply the fix myself. Any help would be appreciated!

Thanks!

Steve Schang

Saturday 25 September 2004 4:45:25 pm

To get EZPublish-3.4.2 to work on a shared hosting plan with PHP installed as a CGI and SuEXEC I modified the ezsys.php file. Before modifying ezsys I could install EZPublish with no problems using the install wizard. However, I could never access ../index.php/plain_admin. EZPublish would always default to the index.php page.

Here is what I changed
lib/ezutils/classes/ezsys.php
Line 756
Change
$phpSelf = eZSys::serverVariable( 'PHP_SELF' );
To
$phpSelf = eZSys::serverVariable( 'REQUEST_URI');

If anyone knows of any problems this may cause please let me know. I am new to PHP and only tried this fix based on the orginal fix proposed in this thread.

André R.

Sunday 05 October 2008 9:44:20 am

From a comment in the php doc:

Note that PHP_SELF will not be equal to REQUEST_URI under Apache if mod_rewrite has been used to move one URL to another--PHP_SELF will contain the rewritten address, and REQUEST_URI will contain the URL the user sees in their browser.

So the fix probably won't work if you use rewrite rules.
EDIT: This fix isn't valid as of 3.4 and higher where a '?' is added to work around this.
However that fix made all GET requests break, including search, so to really support cgi a better solution is needed.
Another comment in the php docs to understand why PHP_SELF is used and why the '?' is added in cgi mode:

Given a URL of http://www.example.com/Info.php/Page/Home

Apache 2.2.4/Win32/PHP 5.2.2/Apache 2.0 Handler
----> PHP_SELF = Info.php/Page/Home

Apache 1.3.37/Unix/PHP 5.2.2/CGI
----> PHP_SELF = Info.php

Apache 1.3.33/Unix/5.1.4/FastCGI
----> PHP_SELF = Info.php

(Sorry for spamming ths old thread..)

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Gaetano Giunta

Sunday 05 October 2008 11:30:05 am

Since we're already spamming this thread, I might as well add in my 2c as well... ;)

http://gggeek.altervista.org/2007/02/13/a-comparison-chart-of-php-environment-variables/

Principal Consultant International Business
Member of the Community Project Board