[pmwiki-users] variables for customization

[Patrick R. Michaud]

Some minor notes

> 2) It's debatable whether FmtPageName even needs access to PHP globals. 
> PmWiki has done fine without it. 

FmtPageName has *always* provided access to PHP globals.  In fact,
without such access many things (most notably skins) simply wouldn't
work.  

> However, I'd still advocate doing it: 
> first, it may allow people to do novel and wonderful things, second, it 
> makes using format strings easier to use, because we don't have to 
> remember (or even know) the differences between globals and placeholders 
> anymore. ...

This is *exactly* the status quo; it has been the status quo for
years and years!  FmtPageName is just the function that performs a
variety of $-substitutions -- it does all of the substitutions 
I listed in an earlier message.

> In other words: if it looks the same, it should mean the same. If I find 
> $PageName in a format string, the naming is consistent with 
> (case-insensitive!) $pagename in the PHP code, so we expect the 
> semantics to be consistent. 

Please-please-please, how many times do I have to repeat that the
$PageName substitution has been deprecated (since 2.0.devel14), thus 
this particular mis-correspondence no longer exists!?!?

> my apologies for that [anger], I know 
> it's a bad habit but unfortunately it seems to be hardwired in my 
> personality. I hope everybody will bear with me.)

No problem or hard feelings on this end.

> >As far as keeping thing straight for those who need to understand
> >the differences, there are really only three things to know.  
> >
> >1.  Things like "{$Group}" and "{$LastModified}" are *markup*.  
> >    You can call them "variables" or "markup variables" if it pleases 
> >    you, but they don't really exist as variables anywhere in the 
> >    PmWiki code, nor is there an enforced correspondence between them
> >    and any PHP variable.  
> 
> My suggestion is to establish such a correspondence. 

Sorry, won't go there -- I fear it might be a bad idea from a
security perspective.  Establishing this correspondence means that
a (malicious) author can use markup to inspect the value of global
variables.

> >2.  A limited set of $-substitutions -- basically anything that 
> >    corresponds to a page attribute -- are not PHP variables and 
> >    are only available through the FmtPageName() subroutine.  

> Here my suggestion is to make this data available as PHP globals. It's 
> too useful in config.php and module/recipe code, and PmWiki knows best 
> how to compute them.

But PmWiki doesn't know what to do when local.php or some other
script changes the value of $pagename; then these PHP globals
would be incorrect, and any script that relies on them would do
the wrong then.

> To avoid confusion, there's the further suggestion that the FmtPageName 
> substitutions that refer to the page name as given in a parameter should 
> be named differently.
> It could be a prefix to the placeholder name, be it $LclPageName or 
> $XPageName or whatever.

By this you are therefore advocating that we change all of
existing instances of $Group, $Name, $Title, $PageUrl, $FullName,
in skins and recipes into these alternate equivalents?  That's 
backwards -- the versions that are used less often (i.e. the 
global variable versions) should have the longer, less-common names.

> >3.  With minor exceptions, basically everything else you see that
> >    looks like $VarName is a PHP variable.
> 
> No suggestions here :-)
> ... well, except that that "with minor exceptions" bit makes me raise an 
> eyebrow. Which exceptions? How do I identify them if I happen to stumble 
> over one?

The exceptions are the ones that appear in the $FmtV array, but I'm
not prepared to debate that one at all.

Pm