[pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?

Peter Bowers pbowers at pobox.com
Sun May 22 10:27:34 CDT 2011

On Sun, May 22, 2011 at 4:36 PM, Oliver Betz <list_ob at gmx.net> wrote:
> Peter Bowers 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
> I don't think so if someone is using "$EnablePathInfo = 1;"
> Look at mwiki.php, lines 302ff. There is also another request method,
> with the "pagename" parameter instead of "n".

Yes, I saw that, but I *believe* it is something left over from
something obsolete in pmwiki.  As I look at the Cookbook/CleanUrls
page It appears that all the .htaccess examples I see there end up
putting the page name in ?n=X...  Theoretically someone could change
these .htaccess to ?pagename=X and presumably it would work, but I'm
not seeing code within pmwiki that would result in a link with

>>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
> Can I rely on pagename being set to the request when config.php is
> processed?

Yes, insofar as it is set.  But see below...

> Can I call MakePageName() early in config.php?

No, this is the function that often causes caching issues.  It calls
FmtPagename() which calls PageVar() which caches various info about
the page, perhaps prematurely.

>>Unfortunately $pagename can still be blank if the user is just looking
> Correct, I missed this. But this is more a skin problem - the "Logo"
> link has to be a full URL to the current default page instead of
> $ScriptUrl, else the language information is lost anyway.
> A link to $ScriptUrl will always start the default language.

Sorry, you've lost me here.  $ScriptUrl always points at pmwiki.php,
right?  I'm not sure I'm seeing the connection to a pagename or a
language or anything else...?

And the "Logo" link is normally set using PVs which are handled long
after farmconfig.php and config.php unless I'm misunderstanding
something...  (Isn't this set during the call to MarkupToHTML()?)

Maybe I've misunderstood the basic question.  Are you trying to get
access to the name of the page early on 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
> Exactly that's what I'm looking for.
>> Currently a simple preg_match on $pagename will work in
>>probably 99.5% (?) of situations, but it would be great to have a 100%
> Looking at MakePageName(), I'm afraid it's not so simple.

I think you'll find that the vast majority of MakePageName() is
irrelevant in this context (calling MPN() to get an accurate $pagename
during the execution of config.php). [1]

In actual but limited testing (tracing the value of $pagename in
config.php and then throwing a lot of different values at it) it
appears that only the case of a blank $pagename (when looking for the
default page) and the case of the trailing .html (both of which are
handled in ResolvePageName() ) are the issues.  The difference between
. and / between group and name is easy enough to solve to be

But whatever the case, whether 80% or 99.5%, I believe what is needed
is a 100% case we can depend on...

Could someone comment on the relative merit of putting this in
conjunction with
to try to give people an option:

add to config.php towards the top:
if (!$pagename) $pagename = $DefaultPage;
$pagename = preg_replace('/\.html$/', '', $pagename);
list($group, $name) = preg_match('/^(.*?)[.\/](.*)$/', $pagename);

I'm still not convinced this solves 100% of the issues, but presumably
takes it a lot closer...  Not being confident that it covers enough of
the instances I hesitate to document it in PmWiki/LocalCustomizations.


For instance, MPN() removes characters that shouldn't be in a pagename
from $pagename.  But in the vast majority of cases people are going to
access pages via links and those links will already be pointing to
correctly named pages (and in any event, line 310 would solve that).
MPN() removes anchors, but they aren't appearing as part of the value
of $pagename in my farmconfig.php (although I don't see where pmwiki
is removing them -- must be "magic occurs here" :-)  ).  MPN() handles
the case where someone specififes ?n=GroupName (without the pagename)
but at least on my system a redirect occurs and so I wouldn't have to
worry about this in config.php.

More information about the pmwiki-users mailing list