Re: [Phpwiki-talk] Bug fix for removepage.php

[Jeff D. <da...@da...>]

Thanks for the patch (and the repeated kicks), Oliver.

> Cause: removepage.php looks for the actual page name by using
> $request->getArg, therefore in HTTP_POST_VARS when hitting the "Remove
> the page now" button.

Yes, but not quite.  $Request is a WikiRequest, and the constructor
for WikiRequest fills in 'pagename' from some other sources if it's
not in HTTP_POST_VARS.  (If USE_PATH_INFO is true, 'pagename' gets
filled in from PATH_INFO --- the bug you're reporting only shows
up when USE_PATH_INFO is off...)

> Another possibility could be to merge HTTP_POST_VARS and HTTP_GET_VARS
> in Request(), any comment on this?

In general, I think that's a bad idea.  For security reasons, one should
ignore GET args on POST requests, I think.

In this case (deducing pagename), though, I think that's the best way
to fix the problem...

There's an asymmetry between USE_PATH_INFO and !USE_PATH_INFO.
When making a POST request with USE_PATH_INFO, the pagename
can (and should, I think) be communicated through the request
URL (via PATH_INFO).  When making a POST request without
USE_PATH_INFO, this can't be done --- if we want to allow the
pagename to be communicated in the URL, GET args is the only
way...  (This only applies to pagename --- other query args,
of course, cannot be communicated through PATH_INFO...)

So (shortly) I'm going to fix WikiRequest::_deducePagename() 
(in main.php) so that it'll be able to figure out pagename from
HTTP_GET_VARS...

> Could this relate to the search functions not working on (some?) 
> systems whith USE_PATH_INFO=true? There was also missing the name of 
> the search page...

It might be related to other problems with USE_PATH_INFO=false, but I
doubt it has to do with USE_PATH_INFO=true problems.  Of course, I've been
wrong before...

Jeff