change in globals.php

[Richard Bateman]

Rick,

I found one of those things that got left out of globals.php that was
actually important =] I have looked through and found what I consider
to be an adequate fix.

This issue arises if you want to use mod_rewrite to cut "index.php" out
of your urls. I like doing this on some of my sites. The problem is
that the $_SERVER['SCRIPT_NAME'] variable doesn't correctly detect the
url of the root of the script if you enable it; it gets the PATH_INFO
passed in after it.

The easy fix is:

(lines before and after left in for context)

$virtualPath = isset($_SERVER['PATH_INFO']) ? $_SERVER['PATH_INFO']
: '';

//*** Fix for when we are using URL rewrites:
if (substr($realPath, strlen($virtualPath) * -1) == $virtualPath)
{
$realPath = substr($realPath, 0, strlen($realPath) -
strlen($virtualPath));
}

define('root_url', $protocol . $host);

This removes the path info from the script_url variable and makes
everything work correctly again. Would it be possible to integrate this
into the core repository?

Richard

[Richard Bateman]

Just as a side note; an example apache configuration for configuring
apache is as follows:

2 <VirtualHost *:80>
3 ServerName tests.kd7bbc.org
4 DocumentRoot /Data/httpd/webroot/newradioform_dev/
5
6 ServerAdmin ric...@batemansr.us
7
8 CustomLog /var/log/apache2/tests-combined_log combined
9 ErrorLog /var/log/apache2/tests-error_log
10 TransferLog /var/log/apache2/tests-access_log
11
12 RewriteEngine on
13
14 RewriteCond %{THE_REQUEST} !^(.*)/public(.*)$
15 RewriteRule ^(/.*)$
/Data/httpd/webroot/newradioform_dev/index.php [E=PATH_INFO:$1]
16 </VirtualHost>

In case anyone else would like to play with it (but again, the fix
mentioned below is required to make it work with zoop)

Richard

[Rick Gigger]

I'm going to have to look at this very closely. There were some
really strange and terrible bugs that sprung up on us from corner
cases that were caused by that code in Pehppy. In those situations
the url would be parsed wrong and the BASE tag would be set
incorrectly and none of the css/js would load. I will be hesitant to
put that in until I can verify that it won't break any normal code. I
agree that we want to be able to get rid of index.php in the URL but
after having to do some weird hacks to the code below (or someting
like it) in Pehppy I am going to have to figure out the corner cases
that were throwing it off and make sure we have a solution that
doesn't cause those same problems.

Thanks,

Rick

[Rick Gigger]

Thanks I will try that out. It would be good to get that into the
documentation somewhere. Maybe a wiki article on the subject? I
believe the problems it caused for me though were actually when
index.php was still in the URL.

Rick

[Richard Bateman]

Interesting. The only time that it should be possible for that to cause
a problem would be if for some reason you had the same thing in the
script_url that you had in the path_info at the rightmost part.

Here is the code that was in pehppy:
$Sname = $_SERVER["SCRIPT_NAME"];

$PATH_INFO = (substr($PATH_INFO, 0, 1) == "/") ? $PATH_INFO : "/" .
$PATH_INFO;

if (substr($Sname, strlen($PATH_INFO) * -1) == $PATH_INFO)
{
$Sname = substr_replace ($Sname, "", strlen($PATH_INFO) * -1);
}

To be honest, I have no idea why I used substr_replace; of course, from
the looks of things, it still does the same thing as the new code. I
can't think of why you would ever have a SCRIPT_NAME that ended with the
same thing that was in path_info, though, unless you wanted to put
index.php in the path_info somewhere, i.e.

http://myserver/index.php/index.php

In this case, since SCRIPT_NAME would be http://myserver/index.php and
PATH_INFO would be index.php, it would cause a problem.
I guess a more dangerous occurance would be:

http://myserver/users/pages/index.php/users/pages/index.php

But since it requires the entire PATH_INFO to be at the end of
SCRIPT_NAME, it seems unlikely that this would happen often, or that
there would even be a use case that required it. Can you remember any
of the corner cases that caused you problems? Is it possible that it
was caused by a different part of the code in the original globals.php?

Let's face it... I wrote that code sitting on Ryan's recliner 8 years
ago (or so). It was really really ugly. :-P If you can give me some
better examples of what causes it to break, maybe I can come up with a
better workaround (maybe an improvement to the url_rewrites code that
will fix the problem; I'll look into that)

Richard

[Rick Gigger]

On Sep 9, 2008, at 7:57 AM, Richard Bateman wrote:

>
>
> Interesting. The only time that it should be possible for that to
> cause
> a problem would be if for some reason you had the same thing in the
> script_url that you had in the path_info at the rightmost part.

Yeah, it wasn't that. Those weren't the same. It was something
else. I don't know what it was. I'll have to figure it out. We do
need this functionality but I don't want to put it in until I do.

Rick

[Richard Bateman]

I've been playing around to see if there is any way I can configure
mod_rewrites to fake out the SCRIPT_NAME variable itself, but
unfortunately that's aparently a variable that PHP creates -- or at
least overwrites -- and I can't figure out how to change it. I could
set a different environment variable to be what ought to be there, but
that seems like far unglier of a hack than we should need. :-/

Until you have time to look at it, I'll just keep my version patched. I
really can't figure out how that code could possibly cause any problems
other than with the end of SCRIPT_NAME being the same as PATH_INFO,
since it seems like that's all the code does... If you have time
sometime to try to find the problem again, I'd be curious. I'm hoping
it's just a problem that was with other weird code in globals. I use
this all the time (and occasionally on sites that I like to be able to
access directly, i.e. not through rewrites, as well) and I'd be happier
if I didn't have to continue to maintain a separate copy of that file.

But, whatever you have time for =]

Thanks for the help,

Richard

[Rick Gigger]

Yeah, I am pretty busy right now but I will look at it as soon as I
get a chance.

Thanks,

Rick