Israel Brewster wrote: > Just got a response from the developer of the PHP script > (serendipity). Turns out the problem lies there, and not with the > rewrite rule. Apparently what's going on is that the php script uses > the REQUEST_URI to determine what to display. If it doesn't recognize > the REQUEST_URI (as is the case with /nagios) it just displays the > main page. It would appear that while mod_rewrite successfully > rewrites the URL and calls the PHP script, it doesn't actually change > the REQUEST_URI, so the script is still acting on /nagios, which it > doesn't recognize. I'll admit this is somewhat beyond me at the > moment, perhaps I need to look more into the difference between the > REQUEST_URI that the php script is seeing and what, exactly, > mod_rewrite is changing. At any rate, that at least explains the problem. > yeah, if you compare the number and type of rewrites for this package with the way that wordpress used to operate, there is a lot of correlation, instead now wordpress uses a much simpler form of rewrite which directs the REQUEST_URI to the application for subsequent alteration, as is the case with your serendipity app. My idea would be to handle all the serendipity rules with the app, leaving a much smaller set of rules which would happily coexist and be easy to modify. I know you say you aren't a php developer, but it wouldn't be that hard to locate and alter the script, perhaps though it would be difficult to subsequently update Serendipity and you would feel this would be a step too far. my $0.02 - when wordpress changed their rewrite rules from 2k down to 4 lines it was great! -- Matthew Farey --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|