On Sun, May 22, 2011 at 12:26 PM, Oliver Betz <[email protected]> wrote: > Randy Brown wrote: > >> Suggestion: get the language code from the URL by writing a PHP >> function to return the language code embedded in the page's group >> (the first part of the "?n=" parameter. Since that doesn't require > > since I'm using "pretty URLs", there is no ?n parameter. > > There are several possibilities of group and name encoding (dot, > slash, order of appearance) that I don't want to duplicate the PmWiki > functions if I can avoid it.
My understanding of pretty URLs is that they simply change www.example.com/pmwiki/Group/Page to www.example.com/pmwiki/pmwiki.php?n=Group/Page behind the scenes. Thus the $_REQUEST['n'] (or $_GET['n']) is still available regardless of the use of pretty URLs. But that's somewhat irrelevant because $pagename is already set to that value by the time config files are included... Unfortunately $pagename can still be blank if the user is just looking for a default page or have trailing ".html" or etc. This can be fixed by a call to ResolvePageName(), but you are correct in noting that this causes problems with caching (due to the call to MakePageName() IIRC) if used too early in config.php... :-( I would love to see either (1) a change to core to provide access to $pagename (validated), $name, and $group throughout config.php and farmconfig.php. Or (2), at least an "officially sanctioned" way to access these values via PHP early on in farmconfig and/or config.php... Currently a simple preg_match on $pagename will work in probably 99.5% (?) of situations, but it would be great to have a 100% solution that doesn't cause caching problems... -Peter _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
