Share » Forums » Install & configuration » PHP CGI - Problems and discussion

PHP CGI - Problems and discussion

PHP CGI - Problems and discussion

Tuesday 22 April 2003 8:42:00 pm - 9 replies

Modified on Tuesday 22 April 2003 8:49:21 pm by Ethan Schoonover

Author Message

Tray Broda

Thursday 24 April 2003 5:27:15 pm

I have to admit... I am concerned with the lack of discussion on this topic that clearly seems to affect many of us. Specifically, the lack of addressing this known bug/problem by the ez staff. Is anyone watching these threads??

-T

Jan Borsodi

Thursday 24 April 2003 11:16:46 pm

The open_basedir problem is explained here:
http://ez.no/developer/ez_publish_3/forum/install_configuration/open_basedir_problems

As for running eZ publish under php-cgi we've never tried this here. Could you give some instructions on how to run PHP as cgi?

--
Amos

Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq

Tray Broda

Friday 25 April 2003 8:05:38 am

I am running apache as a module (Apache2) with the most recent version of PHP (4.3.2RC1) and I still am encountering the same problem.

I get the admin logon screen, and eneter the admin/publish... It tries to take me to:

http://www.sitename.com/ezpublish/index.php/admin/user/login/

To which I get a 404 page can not be found error.

Any ideas?

The debug tracker is on, and on the logon page I have:

Timing: Apr 25 2003 11:09:56
Script start
Timing: Apr 25 2003 11:09:56
Module start 'user'
Timing: Apr 25 2003 11:09:56
Module end 'user'
Timing: Apr 25 2003 11:09:56
End

So nothing wrong there.

Please help!

-T

Ethan Schoonover

Tuesday 29 April 2003 8:37:27 am

Information on running PHP as CGI can be found at:

http://www.php.net/manual/en/security.cgi-bin.php

Note that this isn't too uncommon; as Tray notes, many of us face this on virtual hosting environments.

To be frank, at the end of the day I couldn't, despite many hours invested, solve this issue. I've installed an alternate CMS to manage my personal site as it was sufficient, in most ways, for the job. I still use ezpub on sites for clients as I can install 3.x on my company's dedicated host.

Tray Broda

Tuesday 29 April 2003 3:38:32 pm

Ethan-

It is unfortunate that this has not been solved, as I, too, have switched to an alternate CMS, and can not in the foreseeable future see changing to EZ, given the time sink in setting up a website. I was at a pivotal point in my client architecture/changeover system, which would have made a switch to an alternate CMS doable.... That point has passed now - and I, unfortuantely, see EZPublish in the rear view mirror... as I move forward....

It's sad... I was hoping to utilize this system as I had heard such great things about it.

-T

BTW: Which CMS did you end up choosing?

Jim Porter

Thursday 08 May 2003 5:17:16 am

I too have this problem running on IIS 5.1 on XP. Can't seem to get past whatever page I set as default.

Is there an answer to this one or should I stop wasting my time and move on as the last two posters did?

Jim

Karsten Jennissen

Thursday 08 May 2003 5:30:55 am

Before you move you should try setting the PHP memory limit to more than 8MB to rule out that this causes the problem. Try 16MB or even more.

See
http://ez.no/developer/ez_publish_3/documentation/ez_publish_3/typical_problems_and_solutions/not_enough_php_memory

Karsten

Ricky THomas

Monday 22 September 2003 3:06:59 pm

Question :: has the PHP CGI problems been resolved in ez 3.2 ? or does the patch still work in 3.2 ?

http://ez.no/developer/ez_publish_3/forum/install_configuration/my_final_patch_for_phpcgi

Idea :: Could I try this to get around the " initial " large amount of memory need by ezpublish.

Install ezpublish on another machine then move the folder and the database to my virtual host? are there any issues with doing that?

thanks

Ron Haines

Wednesday 16 March 2011 9:50:24 am

Ricky that link does not work any longer.

I think it's unfortunate when developers chose to censor a problem rather than fix it.

History has proven that it is not healthy for an web application, or any other application for that matter, to take a position of telling end users to change their systems instead of working for wide scope compatibility.

PHP in CGI mode is actually not all that uncommon that it shouldn't be addressed here. Furthermore, the only link I could find to a patch (your link above) which could provide a starting point for fixing this problem has been removed from the forums.

All in all this is very frustrating.

The past is past and cannot be changed, while the future is shaped by action taken in the present.

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu