[Pmwiki-users] skins

Patrick R. Michaud pmichaud
Mon Oct 25 07:06:20 CDT 2004


On Mon, Oct 25, 2004 at 01:49:51PM +1000, Nathan Jones wrote:
> I really struggled with the $PageTemplateFmt scheme in PmWiki1.
> Specifying a path to a .tmpl file drove me nuts, and so did the fact that
> some CSS was in pub/skins (eg. pmwiki.css) and some was in pub/css (eg.
> stdlayout.css).

Well, PmWiki 2 no longer uses a stdlayout.css, so all of the standard skin
stuff is indeed local to the skin directory.  (pub/css is still used for
local.css, $Group.css, $Group.$Name.css, but I'm not sure what will
happen there.)

> >Q1: The problem still exists that an administrator cannot modify files
> >    "in place" but must make a copy.
> 
> Hmm. Is it feasible to have an equivalent of what happens with wiki.d and
> wikilib.d? 

I haven't been able to come up with a good way to do it.

> >Q3: The variable used to specify the skin ($PageSkinFmt) doesn't seem
> >    to have any direct correspondence to the name of the template file
> >    used to control the layout (screen.tmpl).
> 
> Why should it? I find it comforting to know that there is a default name
> for the template file, so all I have to deal with is the directory name.

Some find it comforting to see the template name explicitly in the
configuration variable.

> [...]
> Also, to my mind, a skin is not just a template, but a complete layout,
> with template, CSS and logos.

I agree; but many people who don't have a lot of experience with external CSS
files tend to think of a skin in terms of a single template file.

> >I really noticed this issue when trying to write the LayoutBasics
> >documentation--everything is okay until you get to the steps that say
> >"make a copy of the pub/skins/pmwiki directory" and "set $PageSkinFmt to
> >point to your new directory".  [...]
>
> This is an argument for more explanatory documentation, not for a
> different scheme. 

While this may indeed be an argument in favor of better documentation,
it's not necessarily an argument against a different scheme.  If something
is hard to describe, it's worthwhile to see if there's a better scheme that
would be easier to use and describe.

> The solution is to explain the basic steps (copy
> directory, modify contents, set variable), then elaborate by showing how
> to copy a directory, what files the admin may want to change, and what
> needs to go in config.php. I wrote a draft, but it's too big to post 
> here, so I changed Pmwiki/LayoutBasics. Feel free to restore old 
> version, or edit as desired.

One, thanks for posting the draft directly into the documentation -- it's
easy to edit things there.  The fact that the basic steps are "too big
to post here" may indicate that they're too lengthy in general.  I think
we might want to factor the basic steps for file uploading into a separate
page.

> This was also a possible cause for confusion in PmWiki1 and is not easily
> avoidable. However, explanations in the documentation should help. 

Agreed.

Pm



More information about the pmwiki-users mailing list