Foswiki uses skin templates as the basis of all the screens it uses to interact with users. Each screen has an associated template file that contains the basic layout of the screen. This is then filled in by the code to generate what you see in the browser.
Foswiki ships with a default set of template files that give a very basic, CSS-themable, look-and-feel. Foswiki also includes support for skins that can be selected to give different, more sophisticated, look and feel. A default Foswiki installation will usually start up with the PatternSkin already selected. Skins may also be defined by third parties and loaded into a Foswiki installation to give more options. To see how Foswiki looks when no skin is selected, view this topic with a non-existant skin.
Topic text is not affected by the choice of skin, though a skin can be defined to use a CSS (Cascading Style Sheet), which can sometimes give a radically different appearance to the text.
Changing the default skin
Foswiki ships with the PatternSkin activated by default. You can set the skin for the whole site (via SitePreferences), a single web (via its WebPreferences topic) or topic, for each user individually, or even per request - see Activating Skins below for more details.
Defining Skins
You may want to define your own skin, for example to comply with corporate web guidelines, or because you have a aesthetic vision that you want to share. There are a couple of places you can start doing this.
Skin templates are located by looking at a list of possible locations, including topics and files in the templates directory. The lookup process is configurable, and is described in SkinTemplates#FindingTemplates. You can choose to define your skin entirely in topics, entirely in files in templates, or in a mixture of both.
The easiest way to start creating a new skin is to layer it over an existing skin, only overriding those parts of the existing skin that you want to customise. Foswiki can be configured to fall back to another skin if a template is not defined in your skin. A custom skin can be as small as one file!
Most skins, even those that look radically different to the default, use this layering approach, by basing themselves on the default skin templates (those template files with no skin name e.g view.tmpl, edit.tmpl etc). These templates provide a minimal interface that is easy to understand and build on. Another advantage of this approach is that if new features are exposed in the default templates, your skin has a chance to pick them up "for free".
If you use PatternSkin as your starting point, and you want to modify the layout, colors or even the templates to suit your own needs, have a look first at the topics PatternSkinCustomization and PatternSkinCssCookbook. These topics also provide practical instructions how to create custom skin template files.
Note: Don't call your skin text or rss as these two skin names have reserved meanings, see below at hard-coded meanings.
The following template names are used for Foswiki screens, and are referenced in the Foswiki core code. If a skin doesn't define its own version of a template file, then Foswiki will fall back to the next skin in the skin path, or finally, to the default version of the template file.
(Certain template files are expected to provide certain TMPL:DEFs - these are listed in sub-bullets)
addform - used to select a new form for a topic
attachagain - used when refreshing an existing attachment
attachnew - used when attaching a new file to a topic
attachtables - defines the format of attachments at the bottom of the standard topic view
oopsgeneric - a basic dialog for user information; provides "ok" button only
oopslanguagechanged - used to confirm a new language when internationalisation is enabled
oopsleaseconflict - used to format lease Conflict messages
lease_active, lease_old
preview - used for previewing edited topics before saving
rdiff - used for viewing topic differences
registernotify - used by the user registration system
registernotifyadmin - used by the user registration system
rename - used when renaming a topic
renameconfirm - used when renaming a topic
renamedelete - used when renaming a topic
renameweb - used when renaming a web
renamewebconfirm - used when renaming a web
renamewebdelete - used when renaming a web
searchbookview - used to format search results in book view
searchformat - used to format search results
search - used to format inline search results if no formatting is specified
settings
view - used by the view CGI script
viewprint - used to create the printable view
foswiki.tmpl is a master template conventionally used by other templates, but not used directly by code.
Note: Make sure templates do not end with a newline. Any newline will expand to an empty <p /> in the generated html. It will produce invalid html, and may break the page layout.
Partial customisation, or adding in new features to an existing skin
You can use recursion in the TMPL:INCLUDE chain. For example, if view.tmpl contains %TMPL:INCLUDE{"foswiki"}%, the templating system will include the next SKIN in the skin path.
To create a customisation of the Pattern skin, where you only want to remove the edit & WYSIWYG buttons from the view screen, you create only a view.yourlocal.tmpl:
and then set SKIN=yourlocal,pattern in SitePreferences, a particular web's WebPreferences, or in an individual topic, depending on the desired scope of the skin.
Settings in Skins
You can use template directives, ordinary macros, and other predefined settings in your skins. Some commonly used macros in skins:
Broadcast message at the beginning of your view template, can be used to alert users of scheduled downtimes; can be set in SitePreferences
Using Cascading Style Sheets
CSS files are gererally attachments to the skin topic that are included in the skin templates - in the case of PatternSkin in the template css.pattern.tmpl.
The default skins include a "Go" box, also called "Jump" box, to jump to a topic.
The box also understands URLs, e.g. you can type http://www.google.com/ to jump to an external web site. The feature is handy if you build a skin that has a select box of frequently used links, like Intranet home, employee database, sales database and such. A little JavaScript gets into action on the onchange method of the select tag to fill the selected URL into the "Go" box field, then submits the form.
Here is an example form that has a select box and the "Go" box for illustration purposes. You need to have JavaScript enabled for this to work:
Navigate:
Note: Redirect to a URL only works if it is enabled in configure (Miscellaneous, {AllowRedirectUrl}).
FLASHNOTE Notifications
PatternSkin has a notification message display using the variable FLASHNOTE. For example:
Set FLASHNOTE = Skins documentation
See the alert at the top of this topic.
Attachment Tables
Controlling the look and feel of attachment tables is a little bit more complex than for the rest of a skin. By default, the attachment table is a standard Foswiki table, and the look is controlled in the same way as other tables. In a very few cases you may want to change the content of the table as well.
The format of standard attachment tables is defined through the use of special template directives which by default, are defined in the attachtables.tmpl template using the %TMPL:DEF directive syntax described in SkinTemplates. These macros are:
<a href="http://foswiki.org/">
<img src="%PUBURL%/%SYSTEMWEB%/ProjectLogos/foswiki-badge.png"\
alt="Powered by Foswiki" height="42"\
title="Powered by Foswiki" />
</a>
Generating:
Browsing Installed Skins
You can try out all installed skins in the SkinBrowser.
Activating Skins
Foswiki uses a skin search path, which lets you combine skins additively. The skin path is defined using a combination of preference settings and URL parameters.
Foswiki works by asking for a template for a particular function - for example, 'view'. The detail of how templates are searched for is described in SkinTemplates, but in summary, the templates directory is searched for a file called view.skin.tmpl, where skin is the name of the skin e.g. pattern. If no template is found, then the fallback is to use view.tmpl. Each skin on the path is searched for in turn. For example, if you have set the skin path to local,pattern then view.local.tmpl will be searched for first, then view.pattern.tmpl and finally view.tmpl.
The basic skin is defined by the SKIN preference:
* Set SKIN = catskin, bearskin
You can override this using the URL parameter skin, such as
?skin=catskin,bearskin:
Setting the ?skin parameter in the URL replaces the existing skin path setting for the current request only.
You can also extend the existing skin path using covers:
* Set COVER = ruskin
This pushes a different skin to the front of the skin search path, so the final skin path will be ruskin, catskin, bearskin.
There is also a cover URL parameter that can be used to push yet more skin names in front of the COVER preference.
So the final value of the skin path is given by:
value of the cover URL parameter
value of the COVER preference
value of the skin URL parameter, if it is non-null
value of the SKIN preference, if the skin URL parameter is not given
For example, if we have
* Set SKIN = muscle,bone
* Set COVER = epidermis
and a URL with the parameter ?cover=hair,dermis then the final skin path will
be hair, dermis, epidermis, muscle, bone.
Or we might specify a skin URL parameter, ?skin=flesh. With the same preferences this will set the skin path epidermis, flesh.
Note that you cannot use the cover URL parameter to remove a skin applied by the COVER preference. Once a COVER preference is defined, it is always applied.
Hard-Coded Skins and Covers
text
The text skin is reserved for Foswiki internal use.
rss*
Skin names starting with rss also have a special meaning; if one or more of the skins in the skin path starts with 'rss' then 8-bit characters will be encoded as XML entities in the output, and the content-type header will be forced to text/xml.
cover=print
The cover URL parameter has some hardcoded effects that are not present when the same setting is prepended to the skin. The templates set the CSS media type by examining the cover value.
cover=print sets media="all" for the print.css stylesheet. This causes the CSS to render identically for all media. What you see on the screen will be similar to what will be printed.
skin=print,pattern links to the print.css stylesheet only for print media. This causes the CSS to honor the current media. The screen results will be different from what is actually printed.