[pmwiki-devel] ResolvePageName() before config.php

[Petko Yotov]

On Monday 20 April 2009 09:49:30 Peter & Melodye Bowers wrote:
> > On Monday 20 April 2009 08:27:47 Peter Bowers wrote:
> > > Wouldn't it make better sense to call ResolvePageName() *before*
> > > config.php is included?  Is there a down-side to this?
> >
> > Yes there is. The variables $DefaultPage, $DefaultGroup, $DefaultName,
> > $GroupPattern, $NamePattern, need to be set in config.php by many wikis
> > before calling ResolvePageName(). Notably and importantly, setting a
> > different encoding, like in XLPage() or xlpage-utf-8.php should be done
> > prior
> > > > to ResolvePageName(), or pages with international characters break or 
> > disappear (they may show in pagelists but you cannot open them, or
> > vice-versa).
>
> OK, makes sense with the bigger picture.  So what is the preferred way of
> handling this issue?  Should recipe authors explicitly not depend on the
> value of $pagename while config.php is being processed?  If we need to
> depend on the value of $pagename should we specify that ResolvePageName()
> be called before usage?  Should we explicitly call it within the recipe?
> Should we suggest include_once("scripts/stdconfig.php") instead of calling
> ResolvePageName()?  What's the best practice in connection with this?

I always advise wiki admins to :
* first define any custom PageStore class, like SQLite, CompressedPageStore or
  PerGroupSubDirectories, 
* next call XLPage() which needs the definitive (rw) $WikiDir already set in
  order to find the wiki page containing the translations,
* and/or include_once scripts/xlpage-utf-8.php (this could be happen 
  automatically in the XLPage)
* next include any other scripts and recipes, which could call
  ResolvePageName() as needed.

You may write in the installation instructions that the recipe could be 
included "near the end of config.php", or "after toolbox.php", etc.

Thanks,
Petko