2009/4/20 Patrick R. Michaud <pmich...@pobox.com>: > There are some (older) recipes and local customizations > that expect an unadulterated $pagename when coming into config.php, > so that they can easily perform various actions and transformations > based on what was given in the url as opposed to the transformed > result of ResolvePageName(). Moving ResolvePageName() to occur > before config.php makes it more difficult to handle those properly, > and causes quite a few backwards compatibility problems.
How about adding a static variable to ResolvePageName() that'd hold the previously resolved page name & allow for a quick return if the input $pagename matches that? > Perhaps we should've provided an "$origpagename" variable that > recipes and configs could use instead of the processed $pagename... > but alas, hindsight isn't very helpful here. We could see about > slowly migrating things to that model, but I suspect it would > be quite a long time before we could move ResolvePageName() > without breaking more existing sites than I'm comfortable with. Am I missing something, but isn't this original requested pagename already provided by $FmtPV['$RequestedPage'] (pmwiki.php line 310)? In fact, looking through the version history this variable was introduced at the same time as the ResolvePageName function, in pmwiki-2.1.beta21... eemeli _______________________________________________ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
