[Pmwiki-users] Suggestions for Template Improvements

Patrick R. Michaud pmichaud
Thu Feb 26 07:22:33 CST 2004


On Thu, Feb 26, 2004 at 07:07:22AM -0800, Steven Leite wrote:
> 
>    Suppose I'm making a new Group template called:
> 
>    "MyNewGroup.tmpl".
> 
>    * Problem 1 *
>    My  wysiwyg  editor won't load the .tmpl file unless I explicitly tell
>    it  to  do  so  because  it  doesn't  recognize .tmpl as a valid .html
>    extension.   

So, name your new template "MyNewGroup.htm".  PmWiki doesn't care at all
what the template files are named.

>    * Problem 2 *
>    Currently  (as  of  the  6.4  release?) PmWiki checks for existance of
>    GroupName.css  and  automatically  includes  them  in  the html output
>    (which  is  great!), but  suppose  an html author creates a spiffy new
>    template, and aptly names it:
>    /pub/skins/MyNewGroup/MyNewGroup.htm
>    as well as a file called
>    /pub/skins/MyNewGroup/MyNewGroup.css.
> 
>    Currently,   PmWiki will  be  looking  in  the  wrong  place  for  the
>    MyNewGroup.css  file . 

Not at all.  If your template is a per-group template and the .css file
was designed jointly with the template, then I think your template should 
have
   <link rel='stylesheet' href='pub/skins/MyNewGroup/MyNewGroup.css' ... />
coded in it.  Most wysiwyg editors will include the <link...> elements
in the template anyway.

Just because PmWiki has a per-group .css feature doesn't mean you're 
required to use it for all of your .css files.  The per-group .css 
feature is really meant for sites that are using a shared template file 
for many groups but need a simple way to add group-specific stylesheet 
customization, which is different from the scenario you pose here of having
a separate template for each group.

>    Also,  there's currently no way to make the
>    new  template  work  without taking  further  (confusing) steps; those
>    being   that the html  author  must  create  yet  another  file called
>    MyNewGroup.php, and put it in yet another directory called /local.  If
>    that  wasn't  bad  enough,  he/she also has to edit the MyNewGroup.php
>    file  and  instruct PmWiki precisely where to find the new template by
>    specifying something wierd programming code like:
>    $PageTemplateFmt = 'pub/skins/MyNewGroup/MyNewGroup.htm';

False.  You can set $PageTemplateFmt='pub/skins/$Group/$Group.htm' in
config.php if you want per-group templates, no local/MyNewGroup.php is
required.

>    * Solution 2 *
>    PmWiki  should  automatically  check  the  /pub/skins  directory for a
>    folder   called   MyNewGroup,   containing   a  template  file  called
>    MyNewGroup.htm, and additionally, a css file called MyNewGroup.css.

Veto, at least for the moment.  I've already come to the conclusion that
having PmWiki do too many things "automatically behind the scenes" in the 
distribution, and it becomes more difficult to document.  See my comments in
the last paragraphs of http://pmichaud.com/pipermail/pmwiki-users_pmichaud.com/2004-February/003226.html.

Second, putting this behavior in by default may seem to imply to a new
admin that a template has to be created for every WikiGroup, similar to
the (incorrect) assumption that all per-group .css files have to be
stored in pub/css/$Group.css.  For sites that have dozens of groups
with shared templates, the per-group template approach doesn't make much
sense.

Finally, it is fairly simple to implement a short cookbook recipe that
can go in config.php and does exactly what you've described above:  

   SDV($PageCSSListFmt,array(
     'pub/skins/$Group/$Group.css' => '$PubDir/skins/$Group/$Group.css'));
   $tmpl = FmtPageName('pub/skins/$Group/$Group.htm',$pagename);
   if (file_exists($tmpl)) $PageTemplateFmt = $tmpl;

This recipe even handles the case where someone accesses a group that
doesn't have a template file by leaving $PageTemplateFmt set to its
previous value.  If this recipe proves to be popular and easy enough 
to document, I'll consider adding it to the distribution.

Pm



More information about the pmwiki-users mailing list