[pmwiki-users] Group and page name aren't recognized by pmwiki.php
jo at durchholz.org
Thu Mar 24 13:20:53 CST 2005
Patrick R. Michaud wrote:
> [...] REQUEST_URI isn't even supplied by IIS.
Argh... I can't believe it. I have seen lots of misinterpreted or badly
implemented standards, but this is worse than even the usual MS neglect.
>> Now let me propose another heuristics:
>> *if* PATH_INFO is set, let PmWiki take the group/page name from there.
>> This should be done between steps (2) and (3).
> What about the cases where PATH_INFO is set wrongly? This would
> throw things *way* off, because it would grab an incorrect
> PATH_INFO in preference to a correct SCRIPT_NAME/REQUEST_URI pair.
Agreed. Pity... (and not even Apache gets it right - I *really* wonder
why people even bother doing CGI...)
We *could* try to parse PATH_INFO backwards, but that would generate all
kinds of borderline cases, resulting in Microsoftish behavior (works
most of the time but isn't reliable in the long term). Not a good
>> What do you think?
> PmWiki's default is literally that -- a default that is designed
> to work on the widest variety of server/PHP configurations. There's
> nothing to prevent a site from doing its own custom/exact
> processing of $pagename in local/config.php according to the
> server variables and other information available.
There's still a problem with that. config.php starts with the $pagename
variable set, but it doesn't know where this information came from and
how reliable it is.
For my configuration, this means that I don't know whether the
information came from the query string (and hence is reliable) or came
from PmWiki's attempt at parsing SCRIPT_NAME (which would be bogus). In
other words, config.php wouldn't know whether it should do something or not.
I see several ways to solve this, in the order that they occurred to me
(and some of them are so evil that I list them only for completeness):
1) Remove the SCRIPT_NAME heuristics from pmwiki.php. (The query string
should be fine and can remain hardcoded.) Maybe make that heuristics
available as a function that config.php can call after applying its own
Cons: Backwards-incompatible: $pagename may be unset when entering
2) Create a separate url-parse-config.php. First run the query string
parse, if that fails, run url-parse-config.php if present, then (if
$pagename is still unset) use the SCRIPT_NAME heuristics so that the
rest of the PmWiki can assume that $pagename is always set.
Cons: Requires an additional configuration file, so installation becomes
a little more complicated.
3) Use a status variable that tells config.php where the $pagename
information came from.
Cons: If the URL parse code ever changes, all installations that depend
on the status variable will have to be reviewed.
4) Remove the path info parse from PmWiki. If there's no valid query
string, simply default to Main.Home. People who want a PathInfo are
encouraged to seek out mod_rewrite (and there's a Cookbook recipe for that).
Pros: PmWiki is decoupled from the idiosyncrasies of current web servers.
Cons: Breaks backwards compatibility. Requires rewriting all
PathInfo-style URLs in pmwiki and in skins to query style. Would make
PmWiki asymmetric, in that it would accept only query-style URLs but
might emit PathInfo-style ones (an invitation to misconfigurations).
I don't like any of these alternatives, but I can't think of a better one.
Personally, I think that variant 2 is the least evil one.
More information about the pmwiki-users