[pmwiki-users] variables for customization

Joachim Durchholz jo at durchholz.org
Thu Jul 7 09:00:41 CDT 2005


Patrick R. Michaud wrote:

> 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.  

Ok. Fine.

>>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!?!?

Um... the persistence that $PageName crops up with just *might* be an 
indicator how strong the drive towards unified naming is ;-)

>>>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.

No, no, no. The idea is that *if* a PHP global is available for 
substitution, the placeholder should look the same as the variable.

>>>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.

Ok, but config.php could damage PmWiki in arbitrary ways anyway. I don't 
think that this adds to the problem.

>> 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.

"Less often" is a matter of perspective. For the recipe writer, the 
current page name is (usually) more important than the page names in 
links; for the PmWiki core, it's just the other way round.


... well, whatever the details: the one thing that I really, really, 
really would like to see is that a name like $Group means the same, 
whether it's a PHP global, a placeholder, or {$var} markup. The only 
variation that I'd find justified is if a name is unavailable.

I'm not going to make proposals how that should be achieved for each 
name. I'm pretty certain that some naming decisions would have to be 
changed to achieve that.

However, I value consistency over convenience. If a name needs to be 
made longer to achive consistency, then so be it. If it requires going 
through all recipes, then so be it. Improving consistency to a point 
that the kind of confusion we've had doesn't occur anymore should pay 
off in the long term (the loss in convenience is marginal compared to 
the gain, IMHO).

'nuff said.

Regards,
Jo



More information about the pmwiki-users mailing list