Hi
I am using php 4.0.6 compiled as a cgi executeable
rather than a loadable module. I know this affects
certain php global variables and wonder if this is the
case with the wiki error I am receiving.
I repaired the problem by editing lib/config.php as
follows:
161 //changed below for php as a cgi compatibilityi
by Tim
162 if (!defined('SCRIPT_NAME'))
163 {
164 $tmp = $GLOBALS["REQUEST_URI"];
165 //split of URL from post vars
166 $pos = strpos ($tmp, "?");
167 if ($pos === false)
168 {
169 define('SCRIPT_NAME',
$GLOBALS["REQUEST_URI"]);
170 }
171 else
172 {
173 define('SCRIPT_NAME',
substr($GLOBALS["REQUEST_URI"],0,$pos));
174 }
175 }
176 //end of chnages by Tim
Probably more elegant ways to do this but it seems to
work ok. Can you patch your cvs copy with the above
changes?
Thanks Tim
Logged In: YES
user_id=45814
I'd really like to keep $GLOBALS['SCRIPT_NAME'] as the
default value of SCRIPT_NAME, at least whenever possible.
Can you provide a few more details as to your set up? If
you could set up a public phpinfo script I could look at,
that would be great. At the very least could you tell me
what the bad URLs that the stock PhpWiki was generating look
like?
(A phpinfo script being a PHP script containing nothing but
the line:
<?php phpinfo(); ?>
Sample output at http://phpwiki.sf.net/test/phpinfo.php .)
Thanks!
Logged In: YES
user_id=201663
Hi
Thanks for the reply.
I have set up a phpinfo page at:
http://www.wrcgis.co.uk/phpwiki/info.php
The main problem is that when php is a cgi,
$GLOBALS['SCRIPT_NAME'] returns /cgi-bin/php rather than
the actual script file name.
My fix submitted still does completely not fix the problem
anyway, so if you have an alternative approach, I would be
interested to hear it. In particular the login functions
don't work. One restriction is that I need to run php as a
cgi for another application on the same machine. Although
I could possibly run it as both a .so and a cgi I suppose?
Cheers
Tim
Logged In: YES
user_id=45814
I'd try setting SCRIPT_NAME to $REDIRECT_URL, e.g.:
if (!defined('SCRIPT_NAME'))
define('SCRIPT_NAME', empty($GLOBALS['REDIRECT_URL']) ?
$GLOBALS['SCRIPT_NAME'] : $GLOBALS['REDIRECT_URL']);
How so is it that your fix did not completely fix the problem?
As for the log-in problem. Yes, PhpWiki's login method does
not currently work if running as CGI. This will be fixed
sometime (hopefully fairly soon...). Until then, if you can
run PhpWiki using mod_php, while running your other app as
CGI, that's a fine solution. (Mod_php is generally
preferable from a preformance standpoint, in any case.)
Closing very old bugs.