__FILE__ error on install with Gallery 2.1.2

cameron mcbride

Joined: 2006-09-25
Posts: 3
Posted: Mon, 2006-09-25 15:46

Hello People,

I'm not that much of a php person. I've been using an older gallery1 version for a while, and wanted to upgrade to gallery2. I've run into some installation errors putting it on my hosted site (OpenBSD machine running apache, rootr.net).

This looks to be a little bug in either gallery2 (false expectations of what __FILE__ should give with this version of php) or with the openbsd version of php installed (an incorrect __FILE__ result).

In the 3rd step (system checks) I get:

Error: your PHP __FILE__ directive is not functioning correctly. Please file a support request with your webserver administrator or in the Gallery forums.

(btw, I had to hack AuthenticateStep.class for it to find the login.txt - which now makes sense)

I checked a simple __FILE__ call in a separate php script and it seemed to work correctly. Perhaps it gets confused by the php 'class' files. The result in the forms seems to provide a url referenced from the install/index.php file.
So, the CheckFileDirective() fails since '/steps/SystemChecksStep.class' does not equal the expected '/install/steps/SystemChecksStep.class'

If it helps, my browser says that the generating url is:
http://mydomain.com/gallery2/install/index.php?(...session info, etc)

What I'd really like is to figure out where the problem is (gallery2 or php). Is __FILE__ really acting up?

TIA,

Cameron


Gallery version: 1.2.1 (Blackjack)
PHP version: 4.2.3
PHPInfo Link: http://emcbride.com/ws/info.php
Webserver: Apache/1.3.27 (Unix) mod_lisp/2.35 mod_webkit/0.5 mod_perl/1.27 PHP/4.2.3 mod_ruby/1.0.6 Ruby/1.6.8 mod_ssl/2.8.12 OpenSSL/0.9.7-beta3

(all the rest are irrelevant, we haven't got past the step 3 of the install)
 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2006-09-25 16:48

No, G2 doesn't expect the wrong result for the __FILE__ check. You can use google search, the __FILE__ is old and fixed for most platforms.
__FILE__ is supposed to return an absolute filesystem path, not a relative one.

php 4.2.3 is a few years old.
Please upgrade to php 4.4.x or to php 5.1.x.
 
cameron mcbride

Joined: 2006-09-25
Posts: 3
Posted: Mon, 2006-09-25 17:53
valiant wrote:
No, G2 doesn't expect the wrong result for the __FILE__ check. You can use google search, the __FILE__ is old and fixed for most platforms.
__FILE__ is supposed to return an absolute filesystem path, not a relative one.

OK, thanks for this confirmation. I did search around a bit before posting, but I didn't find anything definitive. Did you happen across a link that discusses this bug and when it was resolved? Looking at the bug database seems to have a bunch of references to __FILE__ type issues. (is this one in gallery2 caused by a require_once?)

valiant wrote:
php 4.2.3 is a few years old.
Please upgrade to php 4.4.x or to php 5.1.x.

I'll follow up with my hosting provider, but I don't really want to install / maintain a new php environment (like I said, I'm not really a php person). I wonder if there are any workarounds.

Thanks again, and any additional info you come across will be much appreciated.

Cameron
 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2006-09-25 18:00

http://bugs.php.net/search.php?search_for=__FILE__&boolean=0&limit=All&order_by=php_version&direction=ASC&cmd=display&status=All&php_os=&phpver=&assign=&author_email=&bug_age=0
from
http://bugs.php.net/bug.php?id=16231

Quote:
[4 May 2002 12:27am UTC] lodder at yacc dot com dot au

Had some feedback from Scott Kearney from Harvard Uni:-

He also experienced this on an OSF/1 platform. One of his colleagues
traced this to a directory permissions issue.

It appears that if a higher level directory has execute permission but
not read permission, this problem appears.

Changing the higher level directories to permission 555 fixed this. This
is a good workaround but I don't want to compromise my system security
to get an application to work ;-)

Thanks to Scott and his colleagues for their input.

i've read the same once.

anyway, if that doesn't solve it for you, it's a php bug.
and php 4.2.x is REALLY OLD!

your webhost needs to upgrade php anyway, it's too old. too many bugs have been fixed. many of them related to security vulnerabilities.
 
cameron mcbride

Joined: 2006-09-25
Posts: 3
Posted: Mon, 2006-09-25 18:49
valiant wrote:
from
http://bugs.php.net/bug.php?id=16231

Quote:
[4 May 2002 12:27am UTC] lodder at yacc dot com dot au

Had some feedback from Scott Kearney from Harvard Uni:-

He also experienced this on an OSF/1 platform. One of his colleagues
traced this to a directory permissions issue.

It appears that if a higher level directory has execute permission but
not read permission, this problem appears.

Changing the higher level directories to permission 555 fixed this. This
is a good workaround but I don't want to compromise my system security
to get an application to work ;-)

Thanks to Scott and his colleagues for their input.

Wow, yeah - that workaround did the trick. Yuck. I don't like it at all. And thanks for this link, cause I missed it (it seems there were several __FILE__ bugs in various versions of php).

Quote:
anyway, if that doesn't solve it for you, it's a php bug.
and php 4.2.x is REALLY OLD!

your webhost needs to upgrade php anyway, it's too old. too many bugs have been fixed. many of them related to security vulnerabilities.

Yes, they do. I completely agree. Let's see if I can convince them of the same.

Thanks for the help!

Cameron