[pmwiki-users] Skin File Search Order

[DaveG]

Kathryn Andersen wrote:
>> {$Site}.{$SkinName}-SiteFooter {$Group}.SiteFooter {$Site}.SiteFooter
>>
>> I include a Site.{$SkinName}-SiteFooter within the skins wikilib.d.
>>
>> The problem with that approach is that the other files in the list 
>> basically get ignored; the only way for the user to not use 
>> Site.{$SkinName}-SiteFooter is to physically delete it from the skin 
>> wikilib.d. However, it does minimize the impact when the user switches 
>> to a new skin.
> 
> If the others get ignored, and the skin version always overrides, then I
> would find that really annoying, as a user.


>> 2] An alternate is to put {$Site}.{$SkinName}-SiteFooter at the end of 
>> the search order, but then we may end up with the skin not working 
>> 'out-of-the-box'.
> 
> Why?  I don't understand why it would fail.  I assume that you're
> providing your own version of {$Site}.{$SkinName}-SiteFooter, yes?
>  
Correct. However if it's last, we have this search order:
  {$Group}.SideBar {$Site}.SideBar {$Site}.{$SkinName}-SideBar

So in this case, since Site.SideBar exists by default, the user will 
never see the skin SideBar, and thus will not get the skin advertised on 
the box. In theory they will visibly see something doesn't looks right, 
so it's kind of a pointer, and they will have to modify their own 
SideBar in any case.

So perhaps there is merit in this approach.

> Another option could be like what I do with the Bonny skin's MenuBar;
> provide the option of enabling/disabling it, by
> 1) having a global variable that they can set, something like
> (SkinName)EnableMenuBar
> 2) Providing a version of Site.MenuBar which has a (:if:) test which
> checks the value of that variable, and only displays that content if
> that variable is true.
So use a variable to determine whether to use the 'out-of-the-box' skin 
version of the file, or the existing version.

This is more explicit, and doesn't rely on the use noticing something is 
awry.