[Pmwiki-users] Skins, revisited

[Steven Leite]

Some comments about skin usage in general:

* I prefer a "default" folder which contains my "custom" skin.
* If the "default" folder is empty (or non-existant), then the "pmwiki"
skin is use (in essence, the default-default skin.
* I prefer that other skins be used in one of two ways:

1.  The admin can create folders (of Group or Page names) in the skins
folder,(eg.  pub/skins/Main/Main.tmpl, or
pub/skins/Main/SandBox/SandBox.tmpl) where they are "automatically" used
by PmWiki (no modifications needed to the config.php file.

2.  The user can specify a skin in the url:  via skin=fancyskin or
setskin=fancyskin (where skin= is a one-time usage of the skin for a
particular page, and setskin= permanently sets the skin until it is
reset or set to something different.  Resetting would just be a matter
of setskin= with no argument).

It's unclear to me which should take priority, a skin designated
specifically for a Group/Page, or a user's command to setskin=.  I think
the existence of a Group/Page skin should take priority as it might be
dependant on a skin for proper page rendering.

I wrote a small module for pmwiki v1.x called easy-templates.php which
can be found in the Cookbook.  I also have a similar one called
x-templates.php which I am using for V2.x.  I haven't put this in the
Cookbook yet, but if any one is interested let me know and I will do it.

I'm wondering if any of the changes proposed below will work for or
against what I've described above.  I got lost in all the different
variable names and don't understand why we need so many $Variables to
handle skins (although, I'm sure there's a good reason for it) :-)

Just my 2 cents ..

-Steven Leite




On Friday, October 29, 2004 1:09 PM [GMT+1=CET],
Patrick R. Michaud <pmichaud at pobox.com> wrote:

> Okay, I think I finally have a handle on skin configuration--here's
> what
> I've ended up with for 2.0.devel20.
>
> The variables for controlling page display are $PageSkinFmt and
> $PrintSkinFmt. $PageTemplateFmt and $PrintTemplateFmt are deprecated,
> but will continue to be supported for the forseeable future.
>
> $PageSkinFmt can be any of the following:
>    - the name of a directory in pub/skins/ containing a screen.tmpl
> template
>    - the name of a template file relative to pub/skins/
>    - the name of a template file relative to the current directory
>      (acts the same as $PageTemplateFmt in 1.x).
>
> Thus, if pub/skins/myskin/ contains the files for the desired skin,
> then
> one can set:
>
> $PageSkinFmt='myskin';                # uses
> 'pub/skins/myskin/screen.tmpl' $PageSkinFmt='myskin/screen.tmpl';
> # same thing $PageSkinFmt='myskin/blue.tmpl';      # use
> 'pub/skins/myskin/blue.tmpl'
>
> Within a template, the variable $SkinDirUrl is set to be the url of
> the directory containing the template (assuming that $PubDirUrl has
> been correctly set).  Thus, a template file can specify something like
> '$SkinDirUrl/myskin.css' to refer to the myskin.css file in the same
> URL location/directory as the template.
>
> Similar rules hold for $PrintSkinFmt, except that if a directory is
> specified it will look for a 'print.tmpl' file instead of
> 'screen.tmpl'.
>
> The result of this is that someone wanting to modify a skin can copy
> *either* the entire directory or just the individual template file to
> be modified, set $PageSkinFmt to the new directory or template file,
> and
> things "just work".
>
> Also, there's a bonus for people doing WikiFarms:  $PageSkinFmt looks
> in
> both the farm's and field's pub/skins/ directories for the template
> file,
> and sets $SkinDirUrl accordingly.  Thus a farm administrator can
> develop/install a set of common skins that are easily available to
> each
> of the wiki field administrators.
>
> Finally, cookbook skin authors can now provide skins that simply
> unpack
> into the sites pub/skins/ directory.  For example, if a cookbook skin
> has its template stored as fancyskin/screen.tmpl, then enabling the
> skin
> is as simple as
>
>     $PageSkinFmt = 'fancyskin';
>
> in config.php.
>
> Comments, questions, suggestions welcome.  This feature will be
> released
> in 2.0.devel20.
>
> Pm