forum.coppermine-gallery.net

No Support => Feature requests => Topic started by: ulikoeln on December 08, 2004, 01:15:05 pm

Title: SCRIPT_NAME vs. PHP_SELF in future releases (cgi problem)
Post by: ulikoeln on December 08, 2004, 01:15:05 pm
Hi,

this is not a "function" type feature request ... mods feel free to move it
to a better place if necessary.

My suggestion would be to check the necessity of using "SCRIPT_NAME" in a few places
in the code and replace it with something that is more reliable. AFAIK, its currently used in
include/init.inc.php
functions.inc.php
db_ecard.php
themes/styleguide/theme.php
calendar.php
Unfortunately, many mods and hacks do it the same style.

There have been quite a number of reports about problems with this
setting, and most of the time the answer by other members or by
coppermine team members is "change line X from script_name to php_self".
In 1.3.2, it did work for me to change it to php_self in the files listed above,
but doing line-by-line hacks are not very elegant and is void after every upgrade.
Also, each additional mod has to be checked, too.

One of the big advantages (!) of coppermine is that it runs fine in
CGI-php / safe_mode environments like many webhosters have. This is great, please
leave it this way. In this environment, the script_name is often something like "/cgi-bin/php" or
"/path/to/some/wrapper/script".

There is already a config option for safe-mode problems, so why not do something
similar for the script_name problem. AFAIK, it is used mostly for constructing self-referential
URLs.  I think it would be easy to replace the explicit use of "script_name" with some
wrapper code in init.inc or some other central place where the proper URL or URL
part is detected and then either SCRIPT_NAME is overwritten or a different global variable
is set that can be used from there on.

What do you think?

Regards,
Ulrich

Title: Re: SCRIPT_NAME vs. PHP_SELF in future releases (cgi problem)
Post by: Joachim Müller on December 08, 2004, 06:11:23 pm
good point, will go on the todo-list.

Joachim