[pmwiki-users] Group and page name aren't recognized by pmwiki.php

[Joachim Durchholz]

Patrick R. Michaud wrote:
> On Tue, Mar 22, 2005 at 10:59:15PM +0100, Joachim Durchholz wrote:
> 
>> I'm having serious trouble getting the "nice URL" recipes from the 
>> Cookbook to work. I'm not sure where exactly the problem is, I
>> suspect misunderstandings on my side and/or a PmWiki bug.
>>[...]
> 
> Are you following http://www.pmwiki.org/wiki/Cookbook/CleanUrls?
> It seems like it should do exactly what you're looking for here.
> If not, why not?

Recipes are a great way to get one started, but that's no reason not to 
double-check that they work the way they are intended to. Since the 
CleanUrls page handles topics that are influenced by a complicated 
external setup (the Apache configuration), that recipe is in a 
particularly sorry state (something that I plan to do something about as 
soon as I have a clearer picture of the factors involved).

>> The .htaccess file looks like this:
>>
>>   RewriteEngine on
>>   RewriteCond %{REQUEST_URI} !^/*(pmwiki\.php|pub)/+.*$
>>   RewriteRule ^(.*)$ pmwiki.php/$1 [L,NS]
> 
> This last RewriteRule is bad, because it's going to try to redirect
> everything to pmwiki.  That's probably not what you want.  Most
 > of the CleanUrls recipes take advantage of the fact that group
 > names begin with an uppercase letter.

Well, this construction is quite exactly what I want, since Group names 
can begin with other things than just A-Z (for example, they can start 
with umlauts). I think the recipes are often naive in this regard.

For this reason, I consider it safer to exclude what I know must be 
excluded (i.e. pmwiki.php and pub, and probably the uploads directory as 
well), and consider everything else a group/page name.

> Also, rather than give PmWiki pathnames, just switch it to the ?n=
> syntax:
> 
>    RewriteRule ^([A-Z].*)$ pmwiki.php?n=$1 [L,qsappend]
> 
> With this in place, you shouldn't have to worry at all about
> RewriteCond.

I didn't think of that because the descriptions of what mod_rewrite does 
(or doesn't do) with the query string deterred me. Also, I didn't like 
the prospect of ?n in internally-generated pathnames - such a pathname 
might end up in a place where end users can see it.

The above RewriteRule might be appropriate for a query-string site.

I also made some disturbing about the consistency of syntax usage in 
PmWiki itself and in skins. At least those skins that I have downloaded 
use PathInfo syntax for links on the template page (so these skins would 
break on a query syntax-only site); also, PmWiki itself seems to 
alternate between PathInfo and query syntax when it comes to hardcoded 
and predefined page URLs. Here's a list of occurrences that seem to 
assume a particular setting of EnablePathInfo (most assume 1, some 
assume 0):

Pmwiki.php:
   '/\\$PageUrl/' => '$ScriptUrl/$Group/$Name',
scripts/crypt.php:
   href='$ScriptUrl?n=PmWiki.PasswordsAdmin'>PasswordsAdmin</a> for more
scripts/mailposts.php:
   ."  ($ScriptUrl/Main/AllRecentChanges)\n\n\$MailPostsList\n");
scripts/pagelist.php:
   SDV($FPLByGroupGFmt,"<dt><a href='\$ScriptUrl/\$Group'>\$Group</a>
     /</dt>");
   SDV($FPLGroupIFmt,"<li><a
     href='\$ScriptUrl/\$Group'>\$Group</a></li>");
scripts/pagerev.php:
   href='\$ScriptUrl/\$DiffAuthorPage'>\$DiffAuthor</a>");
pub/skins/pmwiki/pmwiki.tmpl:
   <form action='$ScriptUrl/$[Main/SearchWiki]'>
   <a href='$ScriptUrl/$[Main/SearchWiki]'>$[SearchWiki]</a>:
   <div class='pagegroup'><a href='$ScriptUrl/$Group'>$Group</a> /</div>
   <a href='$ScriptUrl/$[$Group/RecentChanges]'>$[Recent Changes]</a>
   <a href='$ScriptUrl/$[$Group/RecentChanges]'>$[Recent Changes]</a> -
   <a href='$ScriptUrl/$[PmWiki/WikiHelp]'>$[WikiHelp]</a> -
   <a href='$ScriptUrl/$[Main/SearchWiki]'>$[SearchWiki]</a></div>
pub/skins/print/print.tmpl:
   <h1 class='pagename'><a href='$ScriptUrl/$Group'>$Group:
     $Name</a></h1>

> If there's a reason why the simple recipe in Cookbook.CleanUrls
> won't work, let me know and we'll go from there.

Yup, I found it. It's this code in pmwiki.php, near line 225:

if (!$pagename &&
   preg_match('!^'.preg_quote($_SERVER['SCRIPT_NAME'],'!').'/*([^?]*)!',
     $_SERVER['REQUEST_URI'],$match))
   $pagename = urldecode($match[1]);

The first parameter of pref_match evaluates to a regex that matches 
something like '/path/to/wiki/pmwiki.php' (with an optional appended 
'/Group/Page' and/or a '?QueryString'); however, rewriting just elided 
the script name, so it doesn't match.

Doing some case analysis of Apache's behaviour and googling for the CGI 
specification however showed me that there's an environment variable 
named PATH_INFO that contains just what PmWiki needs: PATH_INFO. It 
contains an initial slash if it's present, PmWiki doesn't like it, so I 
inserted the following code snipped before the above code:

   if (!$pagename &&
       preg_match('!^/*(.*)!', $_SERVER['PATH_INFO'], $match))
     $pagename = $match[1];

The documentation in config.php gives some warning that a PathInfo 
setting may not always work depending on server/PHP configuration.
However, looking at the CGI spec revealed that PATH_INFO is required to 
have precisely the value that PmWiki wants (modulo the initial slash 
that needs to be stripped off).
So I'm baffled: why doesn't PmWiki use PATH_INFO?

Regards,
Jo