<--

Using Variables

To use a variable type its name. For example,

• type %T% to get (a preferences variable)
• type %TOPIC% to get TWikiVariables (a predefined variable)
• type %CALCULATE{ "$UPPER(Text)" }% to get TEXT (a variable defined by a plugin)

Note:

• To leave a variable unexpanded, precede it with an exclamation point, e.g. type !%TOPIC% to get %TOPIC%
• Variables are expanded relative to the topic they are used in, not the topic they are defined in
• Type %ALLVARIABLES% to get a full listing of all variables defined for a particular topic

Variable Names

Variable names must start with a letter, optionally followed by letters, numbers and underscore '_' characters. Both upper-case and lower-case characters can be used, %MYVAR%, %MyVar%, %My2ndVar%, and %My_Var% are valid names. Variables are case sensitive, e.g. %MyVAR% and %MYVAR% are not the same.

By convention all settings, predefined variables and variables handled by extensions are always UPPER-CASE.

Preferences Variables

Unlike predefined variables, preferences variables can be defined by the user in various places.

Setting Preferences Variables

You can set variables in all the following places:

1. system level in TWiki.TWikiPreferences
2. plugin topics (see TWikiPlugins)
3. local site level in Main.TWikiPreferences
4. user level in individual user topics in Main web
   • If UserSubwebs is in effect, the topic specified by %USERPREFSTOPIC% in the user's subweb is read instead
   • If $TWiki::cfg{DemoteUserPreferences} is true, this step is deferred to a later step. On this TWiki installation, $TWiki::cfg{DemoteUserPreferences} is false
5. web level in WebPreferences of each web
6. If EXTRAPREFERENCES is defined at this point, it's regarded as having comma separated list of topics. Those topics are read in the listed order as if they were WebPreferences
7. topic level in topics in webs
8. session variables (if sessions are enabled)
9. user level preferences are set at this point if $TWiki::cfg{DemoteUserPreferences} is true as mentioned at the step 4

Settings at higher-numbered levels override settings of the same variable at lower numbered levels, unless the variable was included in the setting of FINALPREFERENCES at a lower-numbered level, in which case it is locked at the value it has at that level.

If you are setting a variable and using it in the same topic, note that TWiki reads all the variable settings from the saved version of the topic before it displays anything. This means you can use a variable anywhere in the topic, even if you set it somewhere inconspicuous near the end. But beware: it also means that if you change the setting of a variable you are using in the same topic, preview will show the wrong thing, and you must save the topic to see it correctly.

The syntax for setting variables is the same anywhere in TWiki (on its own TWiki bullet line, including nested bullets):
[multiple of 3 spaces] * [space] Set [space] VARIABLENAME [space] = [space] value

Examples:

   * Set VARIABLENAME1 = value
      * Set VARIABLENAME2 = value

Spaces between the = sign and the value will be ignored. You can split a value over several lines by indenting following lines with spaces - as long as you don't try to use * as the first character on the following line.

Example:

   * Set VARIABLENAME = value starts here
     and continues here

Whatever you include in your variable will be expanded on display, exactly as if it had been entered directly.

Example: Create a custom logo variable

• To place a logo anywhere in a web by typing %MYLOGO%, define the Variable on the web's WebPreferences topic, and upload a logo file, ex: mylogo.gif. You can upload by attaching the file to WebPreferences, or, to avoid clutter, to any other topic in the same web, e.g. LogoTopic. Sample variable setting in WebPreferences:

      * Set MYLOGO = %PUBURL%/%WEB%/LogoTopic/mylogo.gif

You can also set preferences variables on a topic by clicking the link Edit topic preference settings under More topic actions. Use the same * Set VARIABLENAME = value syntax. Preferences set in this manner are not visible in the topic text, but take effect nevertheless.

Controlling User Level Preferences Override

By default, user level variables are set at the step 4 as stated in the previous section. That means a user can finalise some preferences variables so that web level or topic level setting cannot override it. This may result in a situation the web or page owner doesn't expect. $TWiki::cfg{DemoteUserPreferences} has been introduced to avoid it. If it's set to true, user level variables are set at the last step instead of the step 4.

But this is not enough. To guarantee a certain result, you need to finalise critical preferences variables set at the web or topic level, which is cumbersome. So preferences variables DENYUSERPREFEENCES and ALLOWUSERPREFEENCES have been introduced.

• DENYUSERPREFEENCES and ALLOWUSERPREFEENCES may have comma separated list of variable names
• If a preferences variable is listed in DENYUSERPREFEENCES, the variable cannot be overridden at the user level. There is a special value "all", which means no preferences variables can be overridden at the user level
• If ALLOWUSERPREFEENCES is set and not empty, only the listed preferences variables can be overridden. There is a special value "all", which means any preferences variable can be overridden at the user level. But actually, "all" is not necessary since a blank value or not setting ALLOWUSERPREFEENCES has the same effect
• DENYUSERPREFEENCES takes precedence over ALLOWUSERPREFEENCES. If a variable is listed on both, it cannot be overridden. If DENYUSERPREFEENCES is "all", the value of ALLOWUSERPREFEENCES doesn't matter.

   * Set DENYUSERPREFERENCES = all

   * Set ALLOWUSERPREFERENCES = TINYMCEPLUGIN_DISABLE, SKIN

   * Set DENYUSERPREFERENCES = TINYMCEPLUGIN_DISABLE, SKIN

You will get the most benefit of DENYUSERPREFEENCES and ALLOWUSERPREFEENCES by setting $TWiki::cfg{DemoteUserPreferences} to true. That way, each web can specify how much user level preferences overriding is allowed.

Parameterized Variables (Macros)

It is possible to pass parameters to TWiki variables. This is called a macro in a programming language.

To define a parameterized variable, set a variable that contains other variables, such as:

   * Set EXAMPLE = Example variable using %DEFAULT%, %PARAM1% and %PARAM2%
   * Set DEMO = Demo using %DEFAULT{ default="(undefined)" }%,
                %PARAM1{ default="(undefined)" }% and %PARAM2{ default="(undefined)" }%

A special %DEFAULT% variable denotes the default (nameless) parameter of the calling variable. Variables optionally may list a default="..." parameter that gets used in case the calling variable does not specify that parameter.

To use a parameterized variable (or call a macro), add parameters within the curly brackets, such as:

   * %EXAMPLE{ "foo" PARAM1="bar" PARAM2="baz" }%
   * %DEMO{ "demo" PARAM2="parameter 2" }% -- note that PARAM1 is missing

• %EXAMPLE{ "foo" PARAM1="bar" PARAM2="baz" }%
• %DEMO{ "demo" PARAM2="parameter 2" }% -- note that PARAM1 is missing

Parameters in the variable definition are expanded using the following sequence:

1. Parameter from variable call. In above example, %PARAM1% gets expanded to bar.
2. Session variable and preferences settings

Example

Define variables:

   * Set DRINK = red wine
   * Set FAVORITE = My %DEFAULT{default="favorite"}% dish is %DISH{default="steak"}%,
                    my %DEFAULT{default="favorite"}% drink is %DRINK%.

Use Variables:

%FAVORITE{ DISH="Sushi" DRINK="Sake" }%

%FAVORITE{}%

%FAVORITE{ "preferred" }%

<--
Redefine what is defined in INCLUDE: 

 Set EXAMPLE = Example variable using favorite, (undefined) and (undefined)
 
 Set DEMO = Demo using favorite,                (undefined) and (undefined)
 
 Set DRINK = red wine
 
 Set FAVORITE = My favorite dish is steak,                    my favorite drink is %DRINK%.
 
-->

Access Control Variables

These are special types of preferences variables to control access to content. TWikiAccessControl explains these security settings in detail.

Local values for variables

Certain topics (a users home topic, web site and default preferences topics) have a problem; variables defined in those topics can have two meanings. For example, consider a user topic. A user may want to use a double-height edit box when they are editing their home topic - but only when editing their home topic. The rest of the time, they want to have a normal edit box. This separation is achieved using Local in place of Set in the variable definition. For example, if the user sets the following in their home topic:

   * Set EDITBOXHEIGHT = 10
   * Local EDITBOXHEIGHT = 20

Use this powerful feature with great care! %ALLVARIABLES% can be used to get a listing of the values of all variables in their evaluation order, so you can see variable scope if you get confused.

Frequently Used Preferences Variables

The following preferences variables are frequently used. They are defined in TWikiPreferences#Miscellaneous_Settings:

• %BB% - line break and bullet combined
• %BB2% - level 2 bullet with line break
• %BB3% - level 3 bullet with line break
• %BB4% - level 4 bullet with line break
• %BR% - line break
• %BULLET% - bullet sign
• %CARET% - caret symbol
• %VBAR% - vertical bar
• %H% - Help icon
• %I% - Idea icon
• %M% - Moved to icon
• %N% - New icon
• %P% - Refactor icon
• %Q% - Question icon
• %S% - Pick icon
• %T% - Tip icon
• %U% - Updated icon
• %X% - Alert icon
• %Y% - Done icon
• %RED% text %ENDCOLOR% - colored text (also %YELLOW%, %ORANGE%, %PINK%, %PURPLE%, %TEAL%, %NAVY%, %BLUE%, %AQUA%, %LIME%, %GREEN%, %OLIVE%, %MAROON%, %BROWN%, %BLACK%, %GRAY%, %SILVER%, %WHITE%)
• %REDBG% text %ENDBG% - colored background (also %YELLOWBG%, %ORANGEBG%, %PINKBG%, %PURPLEBG%, %TEALBG%, %NAVYBG%, %BLUEBG%, %AQUABG%, %LIMEBG%, %GREENBG%, %OLIVEBG%, %MAROONBG%, %BROWNBG%, %BLACKBG%, %GRAYBG%, %SILVERBG%, %WHITEBG%)

There are additional useful preferences variables defined in TWikiPreferences, in Main.TWikiPreferences, and in WebPreferences of every web.

Predefined Variables

Most predefined variables return values that were either set in the configuration when TWiki was installed, or taken from server info (such as current username, or date and time). Some, like %SEARCH%, are powerful and general tools.

• Show all TWiki Variables
• Predefined variables can be overridden by preferences variables (except a few such as TOPIC and WEB)
  • This has long been the case but may not be desirable since even something as fundamental as %IF{...}%, %SCRIPT{...}%, and %INCLUDE{...}% can be overridden
  • So TWiki-6.0.1 has introduced a way to protect predefined variables from being overridden by preferences variables
  • The preferences variable OVERRIDABLEPREDEFINEDVARIABLES having a comma separated list of predefined variables specifies which predefined variables are overridable
  • By default, it's set to "all" (set at TWiki.TWikiPreferences), which means any predefined variable can be overridden, which is for compatibility with prior releases. You can set it to a different value in Main.TWikiPreferences and you may finalise it
  • If it's set as below, all predefined variables are protected

       * Set OVERRIDABLEPREDEFINEDVARIABLES =
    

  • If it's set as below, DATE and LANGUAGE predefined variables can be overridden but all the other predefined variables cannot

       * Set OVERRIDABLEPREDEFINEDVARIABLES = DATE, LANGUAGE
    

• Extensions may extend the set of predefined variables (see individual extension topics for details)
• Take the time to thoroughly read through ALL preference variables. If you actively configure your site, review variables periodically. They cover a wide range of functions, and it can be easy to miss the one perfect variable for something you have in mind. For example, see %INCLUDINGTOPIC%, %INCLUDE%, and the mighty %SEARCH%.

Search or List Variables by Category

All TWiki Variables: ACTIVATEDPLUGINS, ADDTOHEAD, ALLVARIABLES, AQUA, ATTACHURL, ATTACHURLPATH, AUTHREALM, BASETOPIC, BASEWEB, BB, BB2, BB3, BB4, BLACK, BLUE, BR, BROWN, BUBBLESIG, BULLET, CALC, CALCULATE, CARET, CHILDREN, COLORPICKER, COMMENT, CONTENTMODE, COPY, DASHBOARD, DATE, DATEPICKER, DISPLAYTIME, DISPLAYTIME2, EDITACTION, EDITFORMFIELD, EDITTABLE, ENCODE, ENDBG, ENDCOLOR, ENDCOLUMNS, ENDSECTION, ENTITY, ENV, EXAMPLEVAR, FAILEDPLUGINS, FORMFIELD, FOURCOLUMNS, GET, GMTIME, GMTIME2, GRAY, GREEN, GROUPS, H, HEADLINES, HIDE, HIDEINPRINT, HOMETOPIC, HTTP, HTTPHOST, HTTPS, I, ICON, ICONURL, ICONURLPATH, IF, INCLUDE, INCLUDINGTOPIC, INCLUDINGWEB, JQENDTAB, JQENDTABPANE, JQTAB, JQTABPANE, LANGUAGE, LANGUAGES, LAQUO, LIME, LOCALSITEPREFS, LOGIN, LOGINURL, LOGOUT, LOGOUTURL, M, MAINWEB, MAKETEXT, MAROON, MDREPO, META, METASEARCH, N, NAVY, NBSP, NOP, NOTIFYTOPIC, OLIVE, ORANGE, P, PARENTBC, PARENTTOPIC, PINK, PLUGINDESCRIPTIONS, PLUGINVERSION, PUBURL, PUBURLPATH, PURPLE, Q, QUERYPARAMS, QUERYSTRING, RAQUO, RED, REDBG, REG, REMOTEADDR, REMOTEPORT, REMOTEUSER, RENDERLIST, REVINFO, REVINFO2, S, SCRIPTNAME, SCRIPTSUFFIX, SCRIPTURL, SCRIPTURL2, SCRIPTURLPATH, SCRIPTURLPATH2, SEARCH, SERVERTIME, SERVERTIME2, SESSIONID, SESSIONVAR, SESSIONVARIABLE, SET, SETGETDUMP, SILVER, SITENAME, SITESTATISTICSTOPIC, SLIDESHOWEND, SLIDESHOWSTART, SPACEDTOPIC, SPACEOUT, STARTINCLUDE, STARTSECTION, STATISTICSTOPIC, STOPINCLUDE, SYSTEMWEB, T, TABLE, TEAL, THREECOLUMNS, TM, TOC, TOC2, TOPIC, TOPICLIST, TOPICTITLE, TOPICURL, TWIKIWEB, TWISTY, TWOCOLUMNS, U, URLPARAM, USERINFO, USERNAME, USERREPORT, USERSIG, USERSWEB, VAR, VBAR, WEB, WEBLIST, WEBPREFSTOPIC, WHITE, WIKIHOMEURL, WIKILOGOALT, WIKILOGOIMG, WIKILOGOURL, WIKINAME, WIKIPREFSTOPIC, WIKITOOLNAME, WIKIUSERNAME, WIKIUSERSTOPIC, WIKIVERSION, WIP, X, Y, YELLOW, total 185 variables

Documenting TWiki Variables

This section is for people documenting TWiki variables of the TWiki core and TWiki extensions.

Each variable is documented in a topic named Var<name> in the TWiki web. For example, a %LIGHTSABER% variable has a documentation topic called VarLIGHTSABER. The topic is expected to have a specific format so that reports in this TWikiVariables topic, in TWikiVariablesSearch and in category topics work as expected.

Basic structure of a variable documentation topic:

• Parent set to TWikiVariables
• An anchor named the same like the topic, such as #VarLIGHTSABER
• A ---+++ (level 3) heading with variable name, --, short description
• A bullet with description of the variable (optional)
• A Syntax: bullet with example syntax
• A Parameters: bullet with a table explaining the parameters (optional)
• An Example: bullet or two with examples
• An Expands to: bullet with expanded variable (optional)
• A Note: bullet with notes (optional)
• A Category: bullet with one or more of the TWiki variables categories:
  AdministrationVariables, ApplicationsAndComponentsVariables, AttachmentsAndFilesVariables, ChartingAndDrawingVariables, DatabaseAndFormsVariables, DateAndTimeVariables, DevelopmentVariables, EditingAndContentUpdateVariables, EmailAndNotificationVariables, ExportAndPublishingVariables, FormattingAndRenderingVariables, ImportVariables, LinkingAndNavigationVariables, SearchingAndListingVariables, SecurityAndAccessControlVariables, SkinsAndTemplatesVariables, SystemInformationVariables, TablesAndSpreadsheetsVariables, UIAndVisualizationVariables, UsersAndAuthenticationVariables, WorkflowAndAutomationVariables
• A Related: bullet with related links. Links have conditional IF so that links work properly locally in variable documentation topics and in the TWikiVariables topic

Example content of a VarLIGHTSABER topic:

#VarLIGHTSABER
---+++ LIGHTSABER -- laser sword to fend of unethical competition
   * The =%<nop>LIGHTSABER{}%= variable is handled by the LightsaberPlugin.
   * Syntax: =%<nop>LIGHTSABER{ _parameters_ }%=
   * Parameters:
     | *Parameter* | *Description* | *Default* |
     | =color="..."= | Color: =red=, =glue=, =green= | =white= |
     | =sound="..."= | Sound: =none=, =standard=, =loud= | =none= |
   * Example: =%<nop>LIGHTSABER{ color="red" }%= shows a red Lightsaber
   * Expands to: =%LIGHTSABER{ color="red" }%=
   * Note: The Lightsaber is a fictional weapon in the Star Wars universe, a "laser sword."
   * Category: FormattingAndRenderingVariables, UIAndVisualizationVariables
   * Related: [[%IF{"'%INCLUDINGTOPIC%'='TWikiVariables'" then="#"}%VarPLASMA][PLASMA]], LightsaberPlugin

TWiki Forms - Foundation of TWiki Applications

Add structure to content with forms attached to twiki topics. TWiki forms (with form fields) and formatted search are the base for building database applications.

Overview

By adding form-based input to free form content, you can structure topics with unlimited, easily searchable categories. A form is enabled for a web and can be added to a topic. The form data is shown in tabular format when the topic is viewed, and can be changed in edit mode using edit fields, radio buttons, check boxes and list boxes. Many different form types can be defined in a web, though a topic can only have one form attached to it at a time.

Typical steps to build an application based on TWiki forms:

1. Define a form template
2. Enable the form for a web
3. Add the form to a template topic
4. Build an HTML form to create new topics based on that template topic
5. Build a FormattedSearch to list topics that share the same form

Tip: The blog How to Create a TWiki Application on TWiki.org is a good tutorial to get started with TWiki forms based applications.

Defining a Form

A Form Template specifies the fields in a form. A Form Template is simply a page containing a TWiki table, where each row of the table specifies one form field.

1. Create a new topic with your form name: YourForm, ExpenseReportForm, InfoCategoryForm, RecordReviewForm, whatever you need.
   The name of a Form Template topic must end in Form.
2. Create a TWiki table, with each column representing one element of an entry field: Name, Type, Size, Values, Tooltip message, and Attributes (see sample below).
3. For each field, fill in a new line; for the type of field, select from the list.
4. Save the topic

Example:
| *Name* | *Type* | *Size* | *Values* | *Tooltip message* | *Attributes* |
| TopicClassification | select | 1 | NoDisclosure, PublicSupported, PublicFAQ | blah blah... |   |
| OperatingSystem | checkbox | 3 | OsHPUX, OsLinux, OsSolaris, OsWin | blah blah... |   |
| OsVersion | text | 16 | | blah blah... |   |

Name	Type	Size	Values	Tooltip message	Attributes
TopicClassification	select	1	NoDisclosure, PublicSupported, PublicFAQ	blah blah...
OperatingSystem	checkbox	3	OsHPUX, OsLinux, OsSolaris, OsWin	blah blah...
OsVersion	text	16		blah blah...

See structure of a form for full details of what types are available and what all the columns mean.

You can also retrieve possible values for select, checkbox or radio types from other topics:

Example:

• In the WebForm topic, define the form:
  

  Name	Type	Size	Values	Tooltip message	Attributes
  TopicClassification	select	1		blah blah...
  OperatingSystem	checkbox	3		blah blah...
  OsVersion	text	16		blah blah...

  
  Leave the Values field blank.

• Then in the TopicClassification topic, define the possible values:
  | *Name*            |
| NoDisclosure      |
| Public Supported  |
| Public FAQ        |
  

  Name
  NoDisclosure
  Public Supported
  Public FAQ

Field values can also be set using the result of expanding other TWiki variables. For example,

%SEARCH{"Office$" scope="topic" web="%USERSWEB%" nonoise="on" type="regex" format="$web.$topic" separator=", " }%

When used in the value field of the form definition, this will find all topic names in the Main web which end in "Office" and use them as the legal field values.

Adding a Form to a Topic

• To add a Form, follow the "More topic actions" link at the bottom of a topic, select "Add or Replace Form".
  • Select a Form Template topic. These are topics with names ending in Form that contain a Form Template table.
  • A Form is typically added to a template topic, either to the WebTopicEditTemplate topic in a web, or a new topic that serves as an application specific template topic.
  • Modify the template topic to set the initial Form values.

• Additionally a new topic can be given a Form using the formtemplate parameter in the (edit or save) URL. Initial values can then be provided in the URLs or as form values:
  • other than checkboxes: name, ex: ?BugPriority=1
  • checkbox: namevalue=1, ex: ?ColorRed=1.
    Boxes with a tick must be specified.
  • Example: This will add a textfield for the new topic name and a "Create"-Button to your topic. When the button is pressed, the topic editor will open with the form "MyForm" already attached to the new topic.

        <form name="newtopic" action="%SCRIPTURLPATH{"edit"}%/%WEB%/">
           <input type="hidden" name="formtemplate" value="MyForm" />
           New topic name <input type="text" name="topic" size="40" />
           <input type="submit" class="twikiSubmit" value="Create" />
        </form>
           

• Note: You can create a topic in one step, without going through the edit screen. To do that, specify the save script instead of the edit script in the form action. When you specify the save script you have to use the "post" method. Example:

      <form name="newtopic" action="%SCRIPTURLPATH{"save"}%/%WEB%/" method="post">
         .....
      </form>
         

• The edit and save scripts understand many more parameters, see TWikiScripts#edit and TWikiScripts#save for details.

• Tip: For TWiki applications you can automatically generate unique topicnames.

• Note: Initial values will not be set in the form of a new topic if you only use the formtemplate parameter.

Changing a Form

• To change a Form, follow the "More topic actions" link at the bottom of a topic, select "Add or Replace Form", and select a new Form.

• You can change a form definition, and TWiki will try to make sure you don't lose any data from the topics that use that form.

• If you add a new field to the form, then it will appear next time you edit a topic that uses the form.

• If you delete a field from the form, or change a field name, then the data will not be visible when you edit the topic (the changed form definition will be used). If you save the topic, the old data will be lost (though thanks to revision control, you can always see it in older versions of the topic)

• If two people edit the same topic containing a form at exactly the same time, and both change fields in the form, TWiki will try to merge the changes so that no data is lost.

Structure of a Form Template

A Form Template specifies the fields in a form. A Form Template is simply a page containing a TWiki table, where each row of the table specifies one form field.

Each row of the table defines one element of an input field:

The Name, Type and Size columns are required. Other columns are optional. The form template must have a header row, e.g. at least | *Name* | *Type* | *Size* | is required. Columns:

• Name column: Name is the name of the form field.

• Type, Size, Value columns: Type, Size and Value describe the type, size and initial value of this form field. Type text, checkbox, select and more are described in the Form Field Types section below.

• Tooltip message column: The Tooltip message will be displayed when the cursor is hovered over the field in edit view.

• Attributes column: Attributes may contain additional key="value" form field attributes, separated by space.
  • A hidden="1" attribute indicates that this field is hidden, e.g. not shown in view mode. However, the field is available for editing and storing information. The deprecated H attribute has the same function, it is still supported but might be removed in a future TWiki release.
    Tip: The TWiki form header is suppressed in view mode if all fields of the form are hidden. For better usability it is good to hide the whole form if the display and interaction of all form fields is done externally. For example, the display and modification of form field values can be done in a header topic that is included in each page.
  • An mandatory="1" attribute indicates that this field is mandatory. The topic cannot be saved unless a value is provided for this field. If the field is found empty during topic save, an error is raised and the user is redirected to an oops page. Mandatory fields are indicated by an asterisks next to the field name. The deprecated M attribute has the same function, it is still supported but might be removed in a future TWiki release.
  • Additional form field type specific attributes can be used, such as onfocus="..." and spellcheck="..".

For example, a simple form just supporting entry of a name and a date would look as follows:

| *Name* | *Type* | *Size* |
| Name   | text   | 80     |
| Date   | date   | 30     |

Field Name Notes:

• Field names have to be unique.
• A very few field names are reserved. If you try to use one of these names, TWiki will automatically append an underscore to the name when the form is used.
• You can space out the title of the field, and it will still find the topic e.g. Aeroplane Manufacturers is equivalent to AeroplaneManufacturers.
• If a label field has no name, it will not be shown when the form is viewed, only when it is edited.
• Field names can in theory include any text, but you should stick to alphanumeric characters. If you want to use a non-wikiname for a select, checkbox or radio field, and want to get the values from another topic, you can use [[...]] links. This notation can also be used when referencing another topic to obtain field values, but a name other than the topic name is required as the name of the field.
• Leading and trailing spaces are not significant.

Field Value Notes:

• The field value will be used to initialize a field when a form is created, unless specific values are given by the topic template or query parameters. The first item in the list for a select or radio type is the default item. For label, text, and textarea fields the value may also contain commas. checkbox fields cannot be initialized through the form template.
• Leading and trailing spaces are not significant.
• Field values can also be generated through a FormattedSearch, which must yield a suitable table as the result.
• Variables in the initial values of a form definition get expanded when the form definition is loaded.
  • If you want to use a | character in the initial values field, you have to precede it with a backslash, thus: \|.
  • You can use <nop> to prevent TWiki variables from being expanded.
  • The FormatTokens can be used to prevent expansion of other characters.

General Notes:

• The topic definition is not read when a topic is viewed.
• Form definition topics can be protected in the usual manner, using TWikiAccessControl, to limit who can change the form template and/or individual value lists. Note that view access is required to be able to edit topics that use the form definition, though view access to the form definition is not required to view a topic where the form has been used.

Form Field Types

Each table row of a form template defines one element of an input field:

Many types of form fields are available. Some are TWiki internal, some are provided by extensions. Find more TWiki form field extensions on TWiki.org. The Size, Value and Attributes depend on the Type used. Form field types:

Type	Description	Size	Value
text	One-line text field	Text box width in number of characters	Initial (default) content
textarea	Multi-line text box	Columns x rows, such as 80x6; default is 40x5	Initial (default) content
label	Read-only text label		Text of the label
checkbox	One or more checkboxes that can be toggled individually	Number of checkboxes shown per line	Comma-space-separated list of item labels - can be a dynamic SEARCH
checkbox+buttons	Like checkbox, adding [Set] and [Clear] buttons
radio	Radio buttons, mutually exclusive; only one can be selected	Number of radio buttons shown per line	Comma-space-separated list of item labels - can be a dynamic SEARCH
combobox	Text field & select combination box, rendered as a text input field and a button to open up a selector box	Text box width in number of characters	Comma-space-separated list of options of the select box - can be a dynamic SEARCH
select	Select box, rendered as a picklist or a multi-row selector box depending on the size value	• 1: Show a picklist • Number > 1: Multi-row selector box of specified size • Range e.g. 3..10: Multi-row selector box with variable size - the box will never be smaller than 3 items, never larger than 10, and will be 5 high if there are only 5 options	Comma-space-separated list of options of the select box - can be a dynamic SEARCH
select+multi	Like select, turning multi-select on, to allow Shift+Click and Ctrl+Click to select (or deselect) multiple items
select+values	Like select, allowing definition of values that are different to the displayed text. An option is defined as value: title, where the value is the value passed on form submit, and title is the option text shown to the user. For example: | Field 9 | select+values | 3 | One, 2: Two, III: Three | Various values formats | shows OneTwoThree but the values of options Two and Three are 2 and III, respectively. A legacy title=value syntax is supported as well, for example: One, Two=2, Three=III.
select+multi+values	Combination of select+multi and select+values
color	Single-line text box and a color picker to pick a color. The color can also be typed into the text box, such as #123456. An attribute of type="popup" shows a button that, when clicked, opens a color picker popup.	Text box width in number of characters	Initial (default) color
date	Text input field and a button next to it to pick a date from a pop-up calendar. The date can also be typed into the text box.	Text box width in number of characters	Initial (default) date

Note on Attributes:

• Common attributes: hidden, mandatory, class, form, onblur, onfocus, onchange, onselect, onmouseover, onmouseout, spellcheck, style, tabindex, title, translate
• Type-specific attributes:
  • text type: id, max, maxlength, min, pattern, placeholder
  • textarea type: autocomplete, id, maxlength, minlength, pattern, placeholder, wrap
  • label type: id, max, maxlength, min
  • combobox type: max, maxlength, min, pattern, placeholder

Values in Other Topics

As described above, you can also retrieve possible values for select, checkbox or radio types from other topics. For example, if you have a rows defined like this:

| *Name*                 | *Type* | *Size* |
| AeroplaneManufacturers | select |        |

The AeroplaneManufacturers topic must contain a table, where each row of the table describes a possible value. The table only requires one column, Name. Other columns may be present, but are ignored.

For example:

| *Name* |
| Routan |
| Focke-Wulf |
| De Havilland |

Notes:

• The Values column must be empty in the referring form definition.

Using a form template on a different web

You can use a form template on a different web by specifying a form template in the WEB.TOPIC format.

In addition, you can put a comma separated list of webs in the TWIKIFORMPATH variable. It's referred to only when a form template is spcified without a web (TOPIC instead of WEB.TOPIC). The webs in TWIKIFORMPATH are examined in the listed order until the specified template is found.

TWIKIFORMPATH may contain TWiki variables. For example:

   * Set TWIKIFORMPATH = %APPLICATION_WEB%, %WEB%

If TWIKIFORMPATH is defined, the current web is examined only if all the webs listed in it don't have the form template.

Extending the range of form data types

You can extend the range of data types accepted by forms by using TWikiPlugins. All such extended data types are single-valued (can only have one value) with the following exceptions:

• any type name starting with checkbox
• any type name with +multi anywhere in the name

Hints and Tips

Editing Just Form Data, Without Topic Text

In some cases you want to change only the form data. You have the option of hiding the topic text with two methods:

• To display only the form whenever you edit a topic, set the preference variable EDITACTION to value form (see details).
• To change the edit action in a URL, add a action=form parameter to the edit URL string, such as
  %SCRIPTURL{edit}%/%BASEWEB%/%BASETOPIC%?t=%SERVERTIME{$epoch}%;action=form (see details).

Build an HTML Form to Create New Form-based Topics

New topics with a form are created by simple HTML forms asking for a topic name. For example, you can have a SubmitExpenseReport topic where you can create new expense reports, a SubmitVacationRequest topic, and so on. These can specify the required template topic with its associated form. Template topics has more.

A Form Template specifies the fields in a form. A Form Template is simply a page containing a TWiki table, where each row of the table specifies one form field.

Update Specific Form Fields

All the form fields are shown and can be updated when editing a topic that has a form. It is possible to have more control over the layout of a form, or update just a subset of the form fields by using a custom HTML form. For example, in a bug tracker, each topic would include a header topic that shows a form with some fields to update specific form fields of the bug item. Use the EDITFORMFIELD variable to easily create this form in the header topic. Example:

%EDITFORMFIELD{ "form" type="start" action="save" topic="%BASETOPIC%" }%
| Priority: | %EDITFORMFIELD{ "Priority" topic="%BASETOPIC%" }% |
| Status:   | %EDITFORMFIELD{ "Status"   topic="%BASETOPIC%" }% |
|  | %EDITFORMFIELD{ "form" type="submit" value="Update" }% |
%EDITFORMFIELD{ "LastUpdate" type="hidden" value="%SERVERTIME{$year-$mo-$day}%" }%
%EDITFORMFIELD{ "form" type="end" }%

Assuming the base topic has a BugForm with Priority and Status fields of type select, a LastUpdate field of type text, and some other fields. Above form shows a table with selectors for Priority and Status, and an Update button. On form submit, the Priority, Status and LastUpdate fields are updated in the base topic.

Searching for Form Data

TWiki Forms accept user-input data, stored as TWikiMetaData. Meta data also contains program-generated info about changes, attachments, etc. To find, format and display form and other meta data, see TWikiMetaData, EDITFORMFIELD, FORMFIELD, SEARCH and METASEARCH variables in TWikiVariables, and TWiki Formatted Search.

Example
TWiki users often want to have an overview of topics they contributed to. With the $formfield parameter it is easy to display the value of a classification field next to the topic link:

| *Topic* | *Classification* |
%SEARCH{"%USERSWEB%.UserName" scope="text" nosearch="on" nototal="on" sort="modified" reverse="on"
format="|<b>[[$web.$topic][$topic]]</b> |<nop>$formfield(TopicClassification) |" web="Sandbox"}%

Searching forms this way is obviously pretty inefficient, but it's easy to do. If you want better performance, take a look at some of the structured wiki extensions that support higher performance searching e.g. TWiki:Plugins.DBCachePlugin.

Gotcha!

• Some browsers may strip linefeeds from text fields when a topic is saved. If you need linefeeds in a field, make sure it is a textarea.

TWiki Templates

Definition of the templates used to render all HTML pages displayed in TWiki

Overview

Templates are plain text with embedded template directives that tell TWiki how to compose blocks of text together, to create something new.

There are two types of template:

• Master Templates: Define the HTML used to display TWiki pages.
• Template Topics: Define default text when you create a new topic

Tip: TWiki:TWiki.TWikiTemplatesSupplement on TWiki.org has supplemental documentation on TWiki templates.

Master Templates

Master templates are also used in the definition of TWikiSkins.

Master templates are stored as text files with the extension .tmpl. They are usually HTML with embedded template directives. The directives are expanded when TWiki wants to generate a user interface screen.

How Template Directives Work

• Directives are of the form %TMPL:<key>% and %TMPL:<key>{"attr"}%.
• Directives:
  • %TMPL:INCLUDE{"file"}%: Includes a template file. The file is found as described below.
  • %TMPL:DEF{"block"}%: Define a block. All text between this and the next %TMPL:END% directive is removed and saved for later use with %TMPL:P.
  • %TMPL:END%: Ends a block definition.
  • %TMPL:P{"var"}%: Includes a previously defined block.
  • %{...}%: is a comment.
• Two-pass processing lets you use a variable before or after declaring it.
• Templates and TWikiSkins work transparently and interchangeably. For example, you can create a skin that overloads only the twiki.tmpl master template, like twiki.print.tmpl, that redefines the header and footer.
• Use of template directives is optional: templates work without them.
• NOTE: Template directives work only for templates: they do not get processed in normal topic text.

TMPL:P also supports simple parameters. For example, given the definition %TMPL:DEF{"x"}% x%P%z%TMPL:END% then %TMPL:P{"x" P="y"}% will expand to xyz.

Note that parameters can simply be ignored; for example, %TMPL:P{"x"}% will expand to x%P%z.

Any alphanumeric characters can be used in parameter names. You are highly recommended to use parameter names that cannot be confused with TWikiVariables.

Note that three parameter names, context, then and else are reserved. They are used to support a limited form of "if" condition that you can use to select which of two templates to use, based on a context identifier:

%TMPL:DEF{"link_inactive"}%<input type="button" disabled value="Link>%TMPL:END%
%TMPL:DEF{"link_active"}%<input type="button" onclick="link()" value="Link" />%TMPL:END%
%TMPL:P{context="inactive" then="inactive_link" else="active_link"}% for %CONTEXT%

Finding Templates

The master templates shipped with a twiki release are stored in the twiki/templates directory. As an example, twiki/templates/view.tmpl is the default template file for the twiki/bin/view script.

You can save templates in other directories as long as they are listed in the {TemplatePath} configuration setting. The {TemplatePath} is defined in the Miscellaneous section of the configure page.

You can also save templates in user topics (IF there is no possible template match in the templates directory). The {TemplatePath} configuration setting defines which topics will be accepted as templates.

Templates that are included with an explicit '.tmpl' extension are looked for only in the templates/ directory. For instance %TMPL:INCLUDE{"example.tmpl"}% will only return templates/example.tmpl, regardless of {TemplatePath} and SKIN settings.

The out-of-the-box setting of {TemplatePath} supports the following search order to determine which template file or topic to use for a particular script or %TMPL:INCLUDE{"script"}% statement. The skin path is set as described in TWikiSkins.

1. templates/web/script.skin.tmpl for each skin on the skin path
   • this usage is supported for compatibility only and is deprecated. Store web-specific templates in TWiki topics instead.
2. templates/script.skin.tmpl for each skin on the skin path
3. templates/web/script.tmpl
   • this usage is supported for compatibility only and is deprecated. Store web-specific templates in TWiki topics instead.
4. templates/script.tmpl
5. The TWiki topic aweb.atopic if the template name can be parsed into aweb.atopic
6. The TWiki topic web.SkinSkinScriptTemplate for each skin on the skin path
7. The TWiki topic web.ScriptTemplate
8. The TWiki topic %SYSTEMWEB%.SkinSkinScriptTemplate for each skin on the skin path
9. The TWiki topic %SYSTEMWEB%.ScriptTemplate

• script refers to the script name, e.g view, edit
• Script refers to the same, but with the first character capitalized, e.g View
• skin refers to a skin name, e.g dragon, pattern. All skins are checked at each stage, in the order they appear in the skin path.
• Skin refers to the same, but with the first character capitalized, e.g Dragon
• web refers to the current web

For example, the example template file will be searched for in the following places, when the current web is Thisweb and the skin path is print,pattern:

1. templates/Thisweb/example.print.tmpl deprecated; don't rely on it
2. templates/Thisweb/example.pattern.tmpl deprecated; don't rely on it
3. templates/example.print.tmpl
4. templates/example.pattern.tmpl
5. templates/Thisweb/example.tmpl deprecated; don't rely on it
6. templates/example.tmpl
7. Thisweb.PrintSkinExampleTemplate
8. Thisweb.PatternSkinExampleTemplate
9. Thisweb.ExampleTemplate
10. TWiki.PrintSkinExampleTemplate
11. TWiki.PatternSkinExampleTemplate
12. TWiki.ExampleTemplate

Template names are usually derived from the name of the currently executing script; however it is also possible to override these settings in the view and edit scripts, for example when a topic-specific template is required. Two preference variables can be used to override the templates used:

• VIEW_TEMPLATE sets the template to be used for viewing a topic
• EDIT_TEMPLATE sets the template for editing a topic.

Tip: If you want to override existing templates, without having to worry that your changes will get overwritten by the next TWiki update, change the {TemplatePath} so that another directory, such as the %USERSWEB% appears at the front. You can then put your own templates into that directory or web and these will override the standard templates. (Note that such will increase the lookup time for templates by searching your directory first.)

TMPL:INCLUDE recursion for piecewise customization, or mixing in new features

If there is recursion in the TMPL:INCLUDE chain (eg twiki.classic.tmpl contains %TMPL:INCLUDE{"twiki"}%, the templating system will include the next twiki.SKIN in the skin path. For example, to create a customization of pattern skin, where you only want to over-ride the breadcrumbs for the view script, you can create only a view.yourlocal.tmpl:

%TMPL:INCLUDE{"view"}%
%TMPL:DEF{"breadcrumb"}% We don't want any crumbs %TMPL:END%

The default {TemplatePath} will not give you the desired result if you put these statements in the topic Thisweb.YourlocalSkinViewTemplate. The default {TemplatePath} will resolve the request to the template/view.pattern.tmpl, before it gets to the Thisweb.YourlocalSkinViewTemplate resolution. You can make it work by prefixing the {TemplatePath} with: $web.YourlocalSkin$nameTemplate.

Default master template

twiki.tmpl is the default master template. It defines the following sections.

Template Topics

The second type of template in TWiki are template topics. Template topics define the default text for new topics. There are four types of template topic:

When you create a new topic using the edit script, TWiki locates a topic to use as a content template according to the following search order:

1. A topic name specified by the templatetopic CGI parameter
   • if no web is specified, the current web is searched first and then the TWiki web
2. WebTopicEditTemplate in the current web
3. WebTopicEditTemplate in the Main web
4. WebTopicEditTemplate in the TWiki web

Variable Expansion

TWikiVariables located in template topics get expanded as follows when a new topic is created.

1. Default variable expansion

The following variables used in a template topic automatically get expanded when new topic is created based on it:

2. Preventing variable expansion

In a template topic, embed text that you do not want expanded inside a %STARTSECTION{type="templateonly"}% ... %ENDSECTION{type="templateonly"}% section. For example, you might want to write this in the template topic:

%STARTSECTION{type="templateonly"}%
This template can only be changed by:
   * Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup
%ENDSECTION{type="templateonly"}%

%NOP% can be used to prevent expansion of TWiki variables that would otherwise be expanded during topic creation. For example, escape %SERVERTIME% with %SER%NOP%VERTIME%.

3. Causing variable expansion in a section

You can forcefully expand TWikiVariables by placing them inside a type="expandvariables" section in the template topic, such as:

 ...  

Example:

If you have the following content in a template topic:

   * %SYSTEMWEB%.ATasteOfTWiki - view a short introductory presentation on TWiki for beginners
   * %SYSTEMWEB%.WelcomeGuest - starting points on TWiki
   * %SYSTEMWEB%.TWikiUsersGuide - complete TWiki documentation
   * Sandbox.%HOMETOPIC% - try out TWiki on your own
   * Sandbox.%TOPIC%Sandbox - just for me

you will get this raw text in new topics based on that template topic:

   * TWiki.ATasteOfTWiki - view a short introductory presentation on TWiki for beginners
   * TWiki.WelcomeGuest - starting points on TWiki
   * TWiki.TWikiUsersGuide - complete TWiki documentation
   * Sandbox.WebHome - try out TWiki on your own
   * Sandbox.JimmyNeutronSandbox - just for me

4. Specifying variables to be expanded individually

You may want to mix variables to be expanded and variables not to be. By prepending a variable name with EOTC__ (EOTC followed by two underscores; EOTC stands for Expand On Topic Creation), you can have the variable expanded.

Here's an example.

%EOTC__SEARCH{"."
 topic="%URLPARAM{prefix}%*"
 nonoise="on"
 format="$percntINCLUDE{$topic}$percnt" separator="$n"
}%

Specifying a Form

When you create a new topic based on a template, you often want the new topic to have a form attached to it. You can attach a form to the template topic, in which case it will be copied into the new topic.

Sometimes this isn't quite what you want, as it copies all the existing data from the template topic into the new topic. To avoid this and use the default values specified in the form definition instead, you can use the formtemplate CGI parameter to the edit script to specify the name of a form to attach.

See TWikiScripts for information about all the other parameters to edit.

Automatically Generated Topic Names

For TWiki applications it is useful to be able to automatically generate unique topic names, such as BugID0001, BugID0002, etc. You can add AUTOINC<n> to the topic name in the edit and save scripts, and it will be replaced with an auto-incremented number on topic save. <n> is a number starting from 0, and may include leading zeros. Leading zeros are used to zero-pad numbers so that auto-incremented topic names can sort properly. Deleted topics are not re-used to ensure uniqueness of topic names. That is, the auto-incremented number is always higher than the existing ones, even if there are gaps in the number sequence.

Examples:

• BugAUTOINC0 - creates topic names Bug0, Bug1, Bug2, ... (does not sort properly)
• ItemAUTOINC0000 - creates topic names Item0000, Item0001, Item0002, ... (sorts properly up to 9999)
• DocIDAUTOINC10001 - start with DocID10001, DocID10002, ... (sorts properly up to 99999; auto-links)

Characters after AUTOINC<n> are preserved, but are not taken into account when calculating the next increment. Use this to create topic names that have a unique identifier (serial number) and a descriptive text.

Example:

• BlogAUTOINC0001-my-first-blog - creates topic name Blog0001-my-first-blog
• BlogAUTOINC0001-my-crazy-cats - creates topic name Blog0002-my-crazy-cats
• BlogAUTOINC0001-fondue-recipe - creates topic name Blog0003-fondue-recipe

Example link to create a new topic:

[[%SCRIPTURLPATH{edit}%/%WEB%/BugIDAUTOINC00001?templatetopic=BugTemplate;topicparent=%TOPIC%;t=%SERVERTIME{"$day$hour$min$sec"}%][Create new item]]

Template Topics in Action

Here is an example for creating new topics (in the Sandbox web) based on a specific template topic and form:

The above form asks for a topic name. A hidden input tag named templatetopic specifies ExampleTopicTemplate as the template topic to use. Here is the raw text of the form:

%EDITFORMFIELD{ "new" type="start" action="edit" topic="Sandbox.%TOPIC%" }%
   * New example topic: 
     %EDITFORMFIELD{ "topic" type="text" value="ExampleTopicAUTOINC0001" size="30" }%
     %EDITFORMFIELD{ "templatetopic" type="hidden" value="%SYSTEMWEB%.ExampleTopicTemplate" }%
     %EDITFORMFIELD{ "topicparent" type="hidden" value="%HOMETOPIC%" }%
     %EDITFORMFIELD{ "onlywikiname" type="hidden" value="on" }%
     %EDITFORMFIELD{ "onlynewtopic" type="hidden" value="on" }%
     %EDITFORMFIELD{ "form" type="submit" value="Create" }%
%EDITFORMFIELD{ "form" type="end" }%

Here is the equivalent form using a hand-crafted HTML form:

<form name="new" action="%SCRIPTURLPATH{edit}%/Sandbox/%HOMETOPIC%">
   * New example topic: 
     <input type="text" name="topic" value="ExampleTopicAUTOINC0001" size="30" />
     <input type="hidden" name="templatetopic" value="%SYSTEMWEB%.ExampleTopicTemplate" />
     <input type="hidden" name="topicparent" value="%HOMETOPIC%" />
     <input type="hidden" name="onlywikiname" value="on" />
     <input type="hidden" name="onlynewtopic" value="on" />
     <input type="submit" class="twikiSubmit" value="Create" />
</form>

Note: You can create a topic in one step, without going through the edit screen. To do that, specify the save script instead of the edit script in the form action. When you specify the save script in an HTML form tag you have to use the "post" method. This is done automatically when using the EDITFORMFIELD variable. Example when using the HTML form tag:

<form name="new" action="%SCRIPTURLPATH{save}%/Sandbox/" method="post">
    ...
</form>

The edit and save scripts understand many more parameters, see TWikiScripts#edit and TWikiScripts#save for details.

TIP: You can use the %WIKIUSERNAME% and %DATE% variables in your topic templates to include the signature of the person creating a new topic. The variables are expanded into fixed text when a new topic is created. The standard signature is:
-- %WIKIUSERNAME% - %DATE%

Using Absolute vs Relative URLs in Templates

When you use TWikiVariables such as %PUBURL% and %PUBURLPATH% in templates you should be aware that using %PUBURL% instead of %PUBURLPATH% puts absolute URLs in the produced HTML. This means that when a user saves a TWiki page in HTML and emails the file to someone outside a company firewall, the receiver has a severe problem viewing it. It is therefore recommended always to use the %PUBURLPATH% to refer to images, CSS, Javascript files etc so links become relative. This way browsers just give up right away and show a usable html file.

Related Topics: TWikiSkins, TWikiForms, TWikiScripts, DeveloperDocumentationCategory, AdminDocumentationCategory

TWiki Skins

A skin overlays regular templates to provide specific look and feel to TWiki screens.

Overview

TWiki uses TWikiTemplates files 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.

TWiki ships with a default set of template files that give a very basic, CSS-themable, look-and-feel. TWiki also includes support for skins that can be selected to give different, more sophisticated, look and feel. A default TWiki installation will usually start up with the PatternSkin already selected. Skins may also be defined by third parties and loaded into a TWiki installation to give more options. To see how TWiki looks when no skin is selected, view the current page with a non-existing skin.

TWiki topic content is not affected by the choice of skin, however a skin can be defined to use a CSS (Cascading Style Sheet) which can provide a radically different appearance to the text layout.

Relevant links on TWiki.org:

• TWiki:TWiki.TWikiSkinsSupplement - tip: supplemental documentation on TWiki skins
• TWiki:Plugins.SkinPackage - list of all contributed skin packages
• TWiki:Plugins.SkinDevelopment - discussion and feedback on contributed skins
• TWiki:Plugins.SkinBrainstorming - open forum for new skin ideas
• TWiki:Plugins.SkinPackageHowTo - template to create a new skin package

See other types of extensions: TWikiAddOns, TWikiContribs, TWikiPlugins

Changing the default TWiki skin

TWiki ships with the TopMenuSkin activated by default. You can set a skin for the whole site, a single web, a single topic, or for each user individually. This is done by setting the SKIN preferences setting to the name of a skin. If the skin you select doesn't exist, then TWiki will pick up the default templates. For example, to make the SKIN setting work across all topics and webs, put it in TWikiPreferences.

Skins can cascade using a skin path explained below. One skin can be based on another one, and extensions can introduce additional screen elements. For example, the TagMePlugin adds tag elements to the TopMenuSkin, and the TopMenuSkin is based on the PatternSkin, resulting in this skin path:

   * Set SKIN = tagme, topmenu, pattern

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.

The TWikiTemplates files used for skins are located in the twiki/templates directory and are named according to the skin: <scriptname>.<skin>.tmpl. Skin files may also be defined in TWiki topics - see TWikiTemplates for details.

To start creating a new skin, copy the default TWikiTemplates (like view.tmpl), or copy an existing skin to use as a base for your own skin. You should only need to copy the files you intend to customize, as TWiki can be configured to fall back to another skin if a template is not defined in your skin. Name the files as described above (for example view.myskin.tmpl).

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.

For your own TWiki skin we encourage you to show a small TWiki logo at the bottom of your skin:

<a href="http://twiki.org/"><img src="%PUBURL%/%SYSTEMWEB%/TWikiLogos/T-badge-88x31.gif" alt="This site is powered by the TWiki Enterprise Collaboration Platform" width="88" height="31" title="This site is powered by the TWiki Enterprise Collaboration Platform" border="0" /></a>

Renders as:

Note: TWiki.org has no marketing budget, e.g. we rely on TWiki users to spread the word of TWiki. You can support the open source project by adding logos that point back to TWiki.org, and by mentioning TWiki in social media.

The standard TWiki skins show the logo in the %WEBCOPYRIGHT% variable.

Note: Two skin names have reserved meanings; text skin, and skin names starting with rss have hard-coded meanings.

The following template files are used for TWiki screens, and are referenced in the TWiki core code. If a skin doesn't define its own version of a template file, then TWiki 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
  • ATTACH:files:footer, ATTACH:files:header, ATTACH:files:row, ATTACH:versions:footer, ATTACH:versions:header, ATTACH:versions:row
• changeform - used to change the form in a topic
• changes - used by the changes script
• edit - used for the edit screen
• form
• formtables - used to defined the format of forms
  • FORM:display:footer, FORM:display:header, FORM:display:row
• login - used for loggin in when using the TemplateLoginManager
  • LOG_IN, LOG_IN_BANNER, LOG_OUT, LOGGED_IN_BANNER, NEW_USER_NOTE, UNRECOGNISED_USER
• moveattachment - used when moving an attachment
• oopsaccessdenied - used to format Access Denied messages
  • no_such_topic, no_such_web, only_group, topic_access
• oopsattention - used to format Attention messages
  • already_exists, bad_email, bad_ver_code, bad_wikiname, base_web_missing, confirm, created_web, delete_err, invalid_web_color, invalid_web_name, in_a_group, mandatory_field, merge_notice, missing_action, missing_fields, move_err, missing_action, no_form_def, no_users_to_reset, notwikiuser, oversized_upload, password_changed, password_mismatch, problem_adding, remove_user_done, rename_err, rename_not_wikiword, rename_topic_exists, rename_web_err, rename_web_exists, rename_web_prerequisites, reset_bad, reset_ok, save_error, send_mail_error, thanks, topic_exists, unrecognized_action, upload_name_changed, web_creation_error, web_exists, web_missing, wrong_password, zero_size_upload
• oopschangelanguage - used to prompt for a new language when internationalisation is enabled
• 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 inline search results in book view
• searchformat - used to format inline search results
• search - used by the search CGI script
• settings
• view - used by the view CGI script
• viewprint - used to create the printable view

twiki.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 customization, or adding in new features to an existing skin

You can use recursion in the TMPL:INCLUDE chain (e.g. twiki.pattern.tmpl contains %TMPL:INCLUDE{"twiki"}%, the templating system will include the next twiki.SKIN in the skin path (which is explained below). For example, to create a customization of pattern skin, where you only want to remove the edit & WYSIWYG buttons from view page, you create only a view.yourlocal.tmpl:

%TMPL:INCLUDE{"view"}%
%TMPL:DEF{"edit_topic_link"}%%TMPL:END%
%TMPL:DEF{"edit_wysiwyg_link"}%%TMPL:END%

Variables in Skins

You can use template variables, TWikiVariables, and other predefined variables to compose your skins. Some commonly used variables in skins:

The Jump Box and Navigation Box

The default skins include a 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 Jump Box for illustration purposes. You need to have JavaScript enabled for this to work:

Note: Redirect to a URL only works if it is enabled in configure (Miscellaneous, {AllowRedirectUrl}).

Using Cascading Style Sheets

CSS files are gererally attachments to the skin topic that are included in the the skin templates - in the case of PatternSkin in the template styles.pattern.tmpl.

• To see how CSS is used in the default TWiki skin, see: PatternSkin
• If you write a complete new skin, this is the syntax to use in a template file:

<style type='text/css' media='all'>@import url('%PUBURLPATH%/%SYSTEMWEB%/MySkin/mystyle.css');</style>

Attachment Tables

The format of standard attachment tables is defined through the use of special TWiki template macros which by default, are defined in the attachtables.tmpl template using the %TMPL:DEF macro syntax described in TWikiTemplates. These macros are:

The format of tables of file versions in the Upload screen can also be changed, using the macros:

The ATTACH:row macros are expanded for each file in the attachment table, using the following special tags:

Packaging and Publishing Skins

See TWiki:Plugins/SkinPackagingHowTo and TWiki:Plugins/SkinDeveloperFAQ

Browsing Installed Skins

You can try out all installed skins in the TWikiSkinBrowser.

Activating Skins

TWiki uses a skin search path, which lets you combine skins additively. The skin path is defined using a combination of TWikiVariables and URL parameters.

TWiki works by asking for a template for a particular function - for example, 'view'. The detail of how templates are searched for is described in TWikiTemplates, 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 a SKIN setting:

• Set SKIN = catskin, bearskin

You can also add a parameter to the URL, such as ?skin=catskin,bearskin:

• https://wiki.loeschblatt.online/do/view/TWiki/TWikiSkins?skin=catskin,bearskin

Setting SKIN (or the ?skin parameter in the URL) replaces the existing skin path setting, for the current page only. You can also extend the existing skin path as well, using covers.

• Set COVER = ruskin

This pushes a different skin to the front of the skin search path (so for our example above, that final skin path will be ruskin, catskin, bearskin). There is also an equivalent cover URL parameter. The difference between setting SKIN vs. COVER is that if the chosen template is not found (e.g., for included templates), SKIN will fall back onto the next skin in line, or the default skin, if only one skin was present, while COVER will always fall back onto the current skin.

An example would be invoking the printable mode, which is achieved by applying ?cover=print. The view.print.tmpl simply invokes the viewprint template for the current skin which then can appropriately include all other used templates for the current skin. Where the printable mode be applied by using SKIN, all skins would have the same printable appearance.

The full skin path is built up as follows: SKIN setting (or ?skin if it is set), then COVER setting is added, then ?cover.

Conditional Skin Activation

TWiki skins can be activated conditionally using IfStatements. For example, you might want to use a mobile skin for iPhone and Android user agents, and the default skin otherwise. This example uses the print skin on iPhone and Android:

   * Set SKIN = %IF{
      "'%HTTP{"User-Agent"}%'~'*iPhone*' OR '%HTTP{"User-Agent"}%'~'*Android*'"
      then="print, pattern"
      else="topmenu, pattern"
     }%

Hard-Coded Skins

The text skin is reserved for TWiki internal use.

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.

Related Topics: TWikiSkinBrowser, AdminDocumentationCategory, DeveloperDocumentationCategory, TWiki:TWiki.TWikiSkinsSupplement

-- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.MikeMannix, TWiki:Main.CrawfordCurrie

TWiki Plugins

Add functionality to TWiki with readily available plugins; create plugins based on APIs

Overview

You can add plugins to extend TWiki functionality, without altering the core code. A plug-in approach lets you:

• add virtually unlimited features while keeping the main TWiki code compact and efficient;
• heavily customize an installation and still do clean updates to new versions of TWiki;
• rapidly develop new TWiki functions in Perl using the plugin API.

Everything to do with TWiki plugins - demos, new releases, downloads, development, general discussion - is available at TWiki.org, in the TWiki:Plugins web.

TWiki plugins are developed and contributed by interested members of the community. Plugins are provided on an 'as is' basis; they are not a part of TWiki, but are independently developed and maintained.

Relevant links on TWiki.org:

• TWiki:TWiki.TWikiPluginsSupplement - tip: supplemental documentation on TWiki plugins
• TWiki:Plugins.PluginPackage - list of all contributed plugin packages
• TWiki:Plugins.PluginDevelopment - discussion and feedback on contributed plugins
• TWiki:Plugins.PluginBrainstorming - open forum for new plugin ideas
• TWiki:Plugins.PluginPackageHowTo - template to create a new plugin package

See other types of extensions: TWikiAddOns, TWikiContribs, TWikiSkins

Installing Plugins

The TWiki:Plugins web on TWiki.org is the repository for TWiki plugins. Each plugin such as the TWiki:Plugins.ChartPlugin has a topic with user guide, step-by-step installation instructions, a detailed description of any special requirements, version details, and a working example for testing. There's usually a number of other related topics, such as a developers page, and an appraisal page.

Most TWiki plugins are packaged so that they can be installed and upgraded using the configure script. To install a plugin, open up the Extensions tab, follow the "Find More Extensions" link, and follow the instructions. A plugin needs to be enabled after installation.

Plugins can also be installed manually: Download the zip or tgz package of a TWiki plugin from the TWiki.org repository, upload it to the TWiki server, unpack it, and follow the installation instructions found in the plugin topic on TWiki.org.

Special Requirements: Some plugins need certain Perl modules to be pre-installed on the host system. Plugins may also use other resources, like graphics, other modules, applications, and templates. You should be able to find detailed instructions in the plugin's documentation. Use the package manager of the server OS (yum, apt-get, rpm, etc) to install dependent libraries.

If available, install CPAN (Comprehensive Perl Archive Network) libraries with the OS package manager. For example, to install IO::Socket::SSL on Fedora/RedHat/CentOS, run yum install perl-IO-Socket-SSL. CPAN modules can also be installed natively, see TWiki:TWiki.HowToInstallCpanModules.

On-Site Pretesting

If you have a mission critical TWiki installation and you are concerned about installing new plugins, you can test new plugins before making them available by creating a second test TWiki installation, and test the plugin there. It is also possible to configure this test TWiki to use the live data. You can allow selected users access to the test area. Once you are satisfied that it won't compromise your primary installation, you can install it there as well.

InstalledPlugins shows which plugins are: 1) installed, 2) loading properly, and 3) what TWiki:Codev.PluginHandlers they invoke. Any failures are shown in the Errors section. The %FAILEDPLUGINS% variable can be used to debug failures. You may also want to check your webserver error log and the various TWiki log files.

Some Notes on Plugin Performance

The performance of the system depends to some extent on the number of plugins installed and on the plugin implementation. Some plugins impose no measurable performance decrease, some do. For example, a Plugin might use many Perl libraries that need to be initialized with each page view (unless you run mod_perl). You can only really tell the performance impact by installing the plugin and by measuring the performance with and without the new plugin. Use the TWiki:Plugins.PluginBenchmarkAddOn, or test manually with the Apache ab utility. Example on Unix:
time wget -qO /dev/null /do/view/TWiki/AbcPlugin

If you need to install an "expensive" plugin, but you only need its functionality only in a subset of your data, you can disable it elsewhere by defining the %DISABLEDPLUGINS% TWiki variable.

Define DISABLEDPLUGINS to be a comma-separated list of names of plugins to disable. Define it in Main.TWikiPreferences to disable those plugins everywhere, in the WebPreferences topic to disable them in an individual web, or in a topic to disable them in that topic. For example,

   * Set DISABLEDPLUGINS = SpreadSheetPlugin, EditTablePlugin

Managing Installed Plugins

Some plugins require additional settings or offer extra options that you have to select. Also, you may want to make a plugin available only in certain webs, or temporarily disable it. And may want to list all available plugins in certain topics. You can handle all of these management tasks with simple procedures:

Enabling/Disabling Plugins

Plugins can be enabled and disabled with the configure script in the Plugins section. An installed plugin needs to be enabled before it can be used.

Plugin Evaluation Order

By default, TWiki executes plugins in alphabetical order on plugin name. It is possible to change the order, for example to evaluate database variables before the spreadsheet CALCs. This can be done with {PluginsOrder} in the plugins section of configure.

Plugin-Specific Settings

Plugins can be configured with 1. preferences settings and/or 2. with configure settings. Older plugins use plugin preferences settings defined in the plugin topic, which is no longer recommended.

1. Use preferences settings:

Adinistrators can set plugin-specific settings in the local site preferences at Main.TWikiPreferences and users can overload them at the web level and page level. This approach is recommended if users should be able to overload settings. For security this is not recommended for system settings, such as a path to an executable. By convention, preferences setting names start with the plugin name in all caps, and an underscore. For example, to set the cache refresh period of the TWiki:Plugins.VarCachePlugin, add this bullet in Main.TWikiPreferences

• Set VARCACHEPLUGIN_REFRESH = 24

Preferences settings that have been defined in Main.TWikiPreferences can be retrieved anywhere in TWiki with %<pluginname>_<setting>%, such as %VARCACHEPLUGIN_REFRESH%.

To learn how this is done, use the TWiki:Plugins.VarCachePlugin documentation and Perl plugin code as a reference.

2. Use configure settings:

The administrator can set plugin settings in the configure interface. Recommended if only site administrators should be able to change settings. Chose this option to set sensitive or dangerous system settings, such as passwords or path to executables. To define plugin-specific configure settings,

• Create a Config.spec file in lib/TWiki/Plugins/YourPlugin/ with variables, such as
  $TWiki::cfg{Plugins}{RecentVisitorPlugin}{ShowIP} = 0;
• In the plugin, use those those variables, such as
  $showIP = $TWiki::cfg{Plugins}{RecentVisitorPlugin}{ShowIP} || 0;

To learn how this is done, use the TWiki:Plugins.RecentVisitorPlugin documentation and Perl plugin code as a reference.

In either case, define a SHORTDESCRIPTION setting in two places:

• As a setting in the plugin documentation, which is needed for the extension reports on twiki.org. Example:
  
  • Set SHORTDESCRIPTION = Show recent visitors to a TWiki site
• As a global Perl package variable in the plugin package, which is needed by TWiki to show info on installed plugins. Example:
  our $SHORTDESCRIPTION = 'Show recent visitors to a TWiki site';

For better performance, make sure you define this in the plugin package:
our $NO_PREFS_IN_TOPIC = 1;

Listing Active Plugins

Plugin status variables let you list all active plugins wherever needed.

This site is running TWiki version TWiki-6.0.2, Sun, 29 Nov 2015, build 29687, plugin API version 6.02

%ACTIVATEDPLUGINS%

%PLUGINDESCRIPTIONS%

• SpreadSheetPlugin (2015-06-07, $Rev: 29570 (2015-11-29) $): Add spreadsheet calculation like "$SUM( $ABOVE() )" to TWiki tables or anywhere in topic text
• BackupRestorePlugin (2015-01-09, $Rev: 28636 (2015-11-29) $): Administrator utility to backup, restore and upgrade a TWiki site
• ColorPickerPlugin (2015-01-10, $Rev: 29507 (2015-11-29) $): Color picker, packaged for use in TWiki forms and TWiki applications
• CommentPlugin (2015-01-10, $Rev: 28648 (2015-11-29) $): Quickly post comments to a page without an edit/preview/save cycle
• DatePickerPlugin (2015-01-10, $Rev: 29510 (2015-11-29) $): Pop-up calendar with date picker, for use in TWiki forms, HTML forms and TWiki plugins
• EditTablePlugin (2015-01-10, $Rev: 29516 (2015-11-29) $): Edit TWiki tables using edit fields, date pickers and drop down boxes
• HeadlinesPlugin (2015-11-06, $Rev: 29650 (2015-11-29) $): Show headline news in TWiki pages based on RSS and ATOM news feeds from external sites
• InterwikiPlugin (2015-06-18, $Rev: 29526 (2015-11-29) $): Write ExternalSite:Page to link to a page on an external site based on aliases defined in a rules topic
• JQueryPlugin (2015-01-10, $Rev: 29532 (2015-11-29) $): jQuery JavaScript library for TWiki
• PreferencesPlugin (2015-01-14, $Rev: 29550 (2015-11-29) $): Allows editing of preferences using fields predefined in a form
• SetGetPlugin (2015-07-09, $Rev: 29564 (2015-11-29) $): Set and get variables and JSON objects in topics, optionally persistently across topic views
• SlideShowPlugin (2015-01-14, $Rev: 29566 (2015-11-29) $): Create web based presentations based on topics with headings.
• SmiliesPlugin (2015-02-16, $Rev: 29568 (2015-11-29) $): Render smilies as icons, like  :-)  as or  :eek:  as
• TablePlugin (2015-02-16, $Rev: 29580 (2015-11-29) $): Control attributes of tables and sorting of table columns
• TagMePlugin (2015-02-16, $Rev: 29582 (2015-11-29) $): Tag wiki content collectively or authoritatively to find content by keywords
• TinyMCEPlugin (2015-02-16, $Rev: 29584 (2015-11-29) $): Integration of the Tiny MCE WYSIWYG Editor
• TwistyPlugin (2015-04-28, $Rev: 29600 (2015-11-29) $): Twisty section JavaScript library to open/close content dynamically
• WatchlistPlugin (2015-01-15, $Rev: 28820 (2015-11-29) $): Watch topics of interest and get notified of changes by e-mail
• WysiwygPlugin (2015-02-16, $Rev: 29604 (2015-11-29) $): Translator framework for WYSIWYG editors

%FAILEDPLUGINS%

The TWiki Plugin API

The Application Programming Interface (API) for TWiki plugins provides the specifications for hooking into the core TWiki code from your external Perl plugin module.

Available Core Functions

The TWikiFuncDotPm module (lib/TWiki/Func.pm) describes all the interfaces available to plugins. Plugins should only use the interfaces described in this module.

Note: If you use other core functions not described in Func.pm, you run the risk of creating security holes. Also, your plugin will likely break and require updating when you upgrade to a new version of TWiki.

Predefined Hooks

In addition to TWiki core functions, plugins can use predefined hooks, or callbacks, as described in the lib/TWiki/Plugins/EmptyPlugin.pm module.

• All but the initPlugin are commented out. To enable a callback, remove the leading # from all lines of the callback.

TWiki:Codev.StepByStepRenderingOrder helps you decide which rendering handler to use.

Hints on Writing Fast Plugins

• Delay initialization as late as possible. For example, if your plugin is a simple syntax processor, you might delay loading extra Perl modules until you actually see the syntax in the text.
  • For example, use an eval block like this:
    eval { require IPC::Run }
return "<font color=\"red\">SamplePlugin: Can't load required modules ($@)</font>" if $@;
• Keep the main plugin package as small as possible; create other packages that are loaded if and only if they are used. For example, create sub-packages of BathPlugin in lib/TWiki/Plugins/BathPlugin/.
• Avoid using preferences in the plugin topic; Define $NO_PREFS_IN_TOPIC in your plugin package as that will stop TWiki from reading the plugin topic for every page. Use Config.spec or preferences settings instead. (See details).
• Use registered tag handlers.
• Measure the performance to see the difference.

Version Detection

To eliminate the incompatibility problems that are bound to arise from active open plugin development, a plugin versioning system is provided for automatic compatibility checking.

• All plugin packages require a $VERSION variable. This should be an integer, or a subversion version id.

• The initPlugin handler should check all dependencies and return 1 if the initialization is OK or 0 if something went wrong.
  • The plugin initialization code does not register a plugin that returns 0 (or that has no initPlugin handler).

• $TWiki::Plugins::VERSION in the TWiki::Plugins module contains the TWiki plugin API version, currently 6.02.
  • You can also use the %PLUGINVERSION{}% variable to query the plugin API version or the version of installed plugins.

Security

• Badly written plugins can open huge security holes in TWiki. This is especially true if care isn't taken to prevent execution of arbitrary commands on the server.
• Don't allow sensitive configuration data to be edited by users. it is better to add sensitive configuration options to the %TWiki::cfg hash than adding it as preferences in the plugin topic.
  • Integrating with configure describes the steps
  • TWiki:Plugins.MailInContrib has an example
  • TWiki:Plugins.BuildContrib can help you with this
• Always use the TWiki::Sandbox to execute commands.
• Always audit the plugins you install, and make sure you are happy with the level of security provided. While every effort is made to monitor plugin authors activities, at the end of the day they are uncontrolled user contributions.

Creating Plugins

With a reasonable knowledge of the Perl scripting language, you can create new plugins or modify and extend existing ones. Basic plug-in architecture uses an Application Programming Interface (API), a set of software instructions that allow external code to interact with the main program. The TWiki Plugin API provides the programming interface for TWiki. Understanding how TWiki is working at high level is beneficial for plugin development.

Anatomy of a Plugin

A (very) basic TWiki plugin consists of two files:

• a Perl module, e.g. MyFirstPlugin.pm
• a documentation topic, e.g. MyFirstPlugin.txt

The Perl module can be a block of code that talks to with TWiki alone, or it can include other elements, like other Perl modules (including other plugins), graphics, TWiki templates, external applications (ex: a Java applet), or just about anything else it can call. In particular, files that should be web-accessible (graphics, Java applets ...) are best placed as attachments of the MyFirstPlugin topic. Other needed Perl code is best placed in a lib/TWiki/Plugins/MyFirstPlugin/ directory.

The plugin API handles the details of connecting your Perl module with main TWiki code. When you're familiar with the Plugin API, you're ready to develop plugins.

The TWiki:Plugins.BuildContrib module provides a lot of support for plugins development, including a plugin creator, automatic publishing support, and automatic installation script writer. If you plan on writing more than one plugin, you probably need it.

Creating the Perl Module

Copy file lib/TWiki/Plugins/EmptyPlugin.pm to <name>Plugin.pm. The EmptyPlugin.pm module contains mostly empty functions, so it does nothing, but it's ready to be used. Customize it. Refer to the Plugin API specs for more information.

If your plugin uses its own modules and objects, you must include the name of the plugin in the package name. For example, write Package MyFirstPlugin::Attrs; instead of just Package Attrs;. Then call it using:

use TWiki::Plugins::MyFirstPlugin::Attrs;
$var = MyFirstPlugin::Attrs->new();

Writing the Documentation Topic

The plugin documentation topic contains usage instructions and version details. It serves the plugin files as FileAttachments for downloading. (The doc topic is also included in the distribution package.) To create a documentation topic:

1. Copy the plugin topic template from TWiki.org. To copy the text, go to TWiki:Plugins/PluginPackage and:
   • enter the plugin name in the "How to Create a Plugin" section
   • click Create
   • select all in the Edit box & copy
   • Cancel the edit
   • go back to your site to the TWiki web
   • In the JumpBox enter your plugin name, for example MyFirstPlugin, press enter and create the new topic
   • paste & save new plugin topic on your site
2. Customize your plugin topic.
   • Important: In case you plan to publish your plugin on TWiki.org, use Interwiki names for author names and links to TWiki.org topics, such as TWiki:Main/TWikiGuest. This is important because links should work properly in a plugin topic installed on any TWiki, not just on TWiki.org.
3. Document the performance data you gathered while measuring the performance
4. Save your topic, for use in packaging and publishing your plugin.

OUTLINE: Doc Topic Contents
Check the plugins web on TWiki.org for the latest plugin doc topic template. Here's a quick overview of what's covered:

Syntax Rules: <Describe any special text formatting that will be rendered.>"

Example: <Include an example of the plugin in action. Possibly include a static HTML version of the example to compare if the installation was a success!>"

Plugin Settings: <Description and settings for custom plugin %VARIABLES%, and those required by TWiki.>"

Plugin Installation Instructions: <Step-by-step set-up guide, user help, whatever it takes to install and run, goes here.>"

Plugin Info: <Version, credits, history, requirements - entered in a form, displayed as a table. Both are automatically generated when you create or edit a page in the TWiki:Plugins web.>"

Packaging for Distribution

The TWiki:Plugins.BuildContrib is a powerful build environment that is used by the TWiki project to build TWiki itself, as well as many of the plugins. You don't have to use it, but it is highly recommended!

If you don't want (or can't) use the BuildContrib, then a minimum plugin release consists of a Perl module with a WikiName that ends in Plugin, ex: MyFirstPlugin.pm, and a documentation page with the same name(MyFirstPlugin.txt).

1. Distribute the plugin files in a directory structure that mirrors TWiki. If your plugin uses additional files, include them all:
   • lib/TWiki/Plugins/MyFirstPlugin.pm
   • data/TWiki/MyFirstPlugin.txt
   • pub/TWiki/MyFirstPlugin/uparrow.gif [a required graphic]
2. Create a zip archive with the plugin name (MyFirstPlugin.zip) and add the entire directory structure from Step 1. The archive should look like this:
   • lib/TWiki/Plugins/MyFirstPlugin.pm
   • data/TWiki/MyFirstPlugin.txt
   • pub/TWiki/MyFirstPlugin/uparrow.gif

Measuring and Improving the Plugin Performance

A high quality plugin performs well. You can use the TWiki:Plugins.PluginBenchmarkAddOn to measure your TWiki:Plugins.PluginBenchmarks. The data is needed as part of the Documentation Topic.

See also Hints on Writing Fast Plugins.

Publishing for Public Use

You can release your tested, packaged plugin to the TWiki community through the TWiki:Plugins web. All plugins submitted to TWiki.org are available for download and further development in TWiki:Plugins/PluginPackage.

Publish your plugin by following these steps:

1. Post the plugin documentation topic in the TWiki:Plugins/PluginPackage:
   • enter the plugin name in the "How to Create a Plugin" section, for example MyFirstPlugin
   • paste in the topic text from Writing the Documentation Topic and save
2. Attach the distribution zip file to the topic, ex: MyFirstPlugin.zip
3. Link from the doc page to a new, blank page named after the plugin, and ending in Dev, ex: MyFirstPluginDev. This is the discussion page for future development. (User support for plugins is handled in TWiki:Support.)
4. Put the plugin into the SVN repository, see TWiki:Plugins/ReadmeFirst (optional)

Once you have done the above steps once, you can use the BuildContrib to upload updates to your plugin.

Thank you very much for sharing your plugin with the TWiki community

Recommended Storage of Plugin Specific Data

Plugins sometimes need to store data. This can be plugin internal data such as cache data, or data generated for browser consumption such as images. Plugins should store data using TWikiFuncDotPm functions that support saving and loading of topics and attachments.

Plugin Internal Data

You can create a plugin "work area" using the TWiki::Func::getWorkArea() function, which gives you a persistent directory where you can store data files. By default they will not be web accessible. The directory is guaranteed to exist, and to be writable by the webserver user. For convenience, TWiki::Func::storeFile() and TWiki::Func::readFile() are provided to persistently store and retrieve simple data in this area.

Web Accessible Data

Topic-specific data such as generated images can be stored in the topic's attachment area, which is web accessible. Use the TWiki::Func::saveAttachment() function to store the data.

Recommendation for file name:

• Prefix the filename with an underscore (the leading underscore avoids a name clash with files attached to the same topic)
• Identify where the attachment originated from, typically by including the plugin name in the file name
• Use only alphanumeric characters, underscores, dashes and periods to avoid platform dependency issues and URL issues
• Example: _GaugePlugin_img123.gif

Web specific data can be stored in the plugin's attachment area, which is web accessible. Use the TWiki::Func::saveAttachment() function to store the data.

Recommendation for file names in plugin attachment area:

• Prefix the filename with an underscore
• Include the name of the web in the filename
• Use only alphanumeric characters, underscores, dashes and periods to avoid platform dependency issues and URL issues
• Example: _Main_roundedge-ul.gif

Integrating with configure

Config.spec files are read during TWiki configuration. Once a Config.spec has defined a configuration item, it is available for edit through the standard configure interface. Config.spec files are stored in the 'plugin directory' e.g. lib/TWiki/Plugins/BathPlugin/Config.spec.

Structure of a Config.spec file

# ---+ Extensions
# ---++ BathPlugin
# This plugin senses the level of water in your bath, and ensures the plug
# is not removed while the water is still warm.

# **SELECT Plastic,Rubber,Metal**
# Select the plug type
$TWiki::cfg{BathPlugin}{PlugType} = 'Plastic';

# **NUMBER**
# Enter the chain length in cm
$TWiki::cfg{BathPlugin}{ChainLength} = 30;

# **BOOLEAN EXPERT**
# Set this option to 0 to disable the water temperature alarm
$TWiki::cfg{BathPlugin}{TempSensorEnabled} = 1;

if( $TWiki::cfg{BathPlugin}{TempSensorEnabled} && $curTemperature > 50 ) {
    die "The bathwater is too hot for comfort";
}

The Config.spec file is read by configure, which then writes LocalSite.cfg with the values chosen by the local site admin.

A range of types are available for use in Config.spec files:

All types can be followed by a comma-separated list of attributes.

See lib/TWiki.spec for many more examples.

Config.spec files for non-plugin extensions are stored under the Contrib directory instead of the Plugins directory.

Note that from TWiki 5.0 onwards, CGI scripts (in the TWiki bin directory) provided by extensions must also have an entry in the Config.spec file. This entry looks like this (example taken from PublishContrib)

# **PERL H**
# Bin script registration - do not modify
$TWiki::cfg{SwitchBoard}{publish} = [ "TWiki::Contrib::Publish", "publish", { publishing => 1 } ];

TWiki:TWiki/SpecifyingConfigurationItemsForExtensions has supplemental documentation on configure settings.

Maintaining Plugins

Discussions and Feedback on Plugins

Each published plugin has a plugin development topic on TWiki.org. Plugin development topics are named after your plugin and end in Dev, such as MyFirstPluginDev. The plugin development topic is a great resource to discuss feature enhancements and to get feedback from the TWiki community.

Maintaining Compatibility with Earlier TWiki Versions

The plugin interface (TWikiFuncDotPm functions and plugin handlers) evolve over time. TWiki introduces new API functions to address the needs of plugin authors. Plugins using unofficial TWiki internal functions may no longer work on a TWiki upgrade.

Organizations typically do not upgrade to the latest TWiki for many months. However, many administrators still would like to install the latest versions of a plugin on their older TWiki installation. This need is fulfilled if plugins are maintained in a compatible manner.

Tip: Plugins can be written to be compatible with older and newer TWiki releases. This can be done also for plugins using unofficial TWiki internal functions of an earlier release that no longer work on the latest TWiki codebase. Here is an example; the TWiki:TWiki.TWikiPluginsSupplement#MaintainPlugins has more details.

    if( $TWiki::Plugins::VERSION >= 1.1 ) {
        @webs = TWiki::Func::getListOfWebs( 'user,public' );
    } else {
        @webs = TWiki::Func::getPublicWebList( );
    }

Handling deprecated functions

From time-to-time, the TWiki developers will add new functions to the interface (either to TWikiFuncDotPm, or new handlers). Sometimes these improvements mean that old functions have to be deprecated to keep the code manageable. When this happens, the deprecated functions will be supported in the interface for at least one more TWiki release, and probably longer, though this cannot be guaranteed.

When a plugin defines deprecated handlers, a warning will be shown in the list generated by %FAILEDPLUGINS%. Admins who see these warnings should check TWiki.org and if necessary, contact the plugin author, for an updated version of the plugin.

Updated plugins may still need to define deprecated handlers for compatibility with old TWiki versions. In this case, the plugin package that defines old handlers can suppress the warnings in %FAILEDPLUGINS%.

This is done by defining a map from the handler name to the TWiki::Plugins version in which the handler was first deprecated. For example, if we need to define the endRenderingHandler for compatibility with TWiki::Plugins versions before 1.1, we would add this to the plugin:

package TWiki::Plugins::SinkPlugin;
use vars qw( %TWikiCompatibility );
$TWikiCompatibility{endRenderingHandler} = 1.1;

Appendix A: TWiki Development Time-line

TWiki Release 6.0 (Jerusalem) released on 2013-10-14 — 2015-11-29

New Features and Enhancements of TWiki Release 6.0

• Usability Enhancements
  • Add dashboards to Web home topics
  • Categorize TWiki variables & add TWiki Variables wizard
  • Upgrade to TinyMCE WYSIWYG editor to version 3.5.8
  • New TOPICTITLE variable for non-WikiWord topic titles
  • Show topic title in square bracket links using [[+TopicName]] syntax
  • Icon bullet lists: Specify any TWiki doc graphics icon as a bullet
  • WebSearch and WebChanges has now search result pagination
  • WebChanges shows topic age instead of topic date
  • Auto-discover TWikiForms, e.g. no need to set in WEBFORMS preferences setting
  • Move change TWiki Form from edit screen to "more" screen
  • Show link to older versions of attachments in attachment table
  • Automatically link @Twitter handles
  • Add comment section to new topic template
  • Copy/clone topic function in more topic action screen
  • Configurable signatures with profile pictures
  • Open external links in new browser window or tab; show external link icon
  • Drag and drop file attachments - PatternSkin to integrate DropzoneJSSkin - added in TWiki-6.0.1
  • Add drag and drop to change profile picture screen - added in TWiki-6.0.1
  • Responsive multi-column page layout using CSS using TWOCOLUMNS...ENDCOLUMNS - added in TWiki-6.0.2
  • Search attachments in a web with new WebSearchAttachments topic to all webs - added in TWiki-6.0.2
  • Easier TWiki installation by adding Perl CGI module to TWiki core distribution - added in TWiki-6.0.2

• Scalability Enhancements
  • Read-only and mirror web support for distributed TWiki sites
  • MetadataRepository for site metadata and web metadata to speed up operations across many webs
  • Rename topic operation with option to not replace web internal references
  • Rename web operation can cope with a large site and read-only/mirror webs
  • Introducing web-level administrator for higher web autonomy; web specific WIKIWEBMASTER
  • Support for multiple disk drives for data and pub directories

• TWiki Application Platform Enhancements
  • New EDITFORMFIELD variable to easily create custom forms to create/change topics with TWiki Forms
  • Add rev parameter to FORMFIELD variable
  • New combobox TWiki Form field type
  • New ENTITY variable to entity encode content
  • New CHILDREN variable to show topic children added in TWiki-6.0.2
  • Add createdate, default, encode parameters to SEARCH variable
  • SEARCH variable with sort by parent feature
  • SEARCH variable extended to make results pagination possible
  • SEARCH: Search with sort by multiple fields - added in TWiki-6.0.1
  • SEARCH: Sort by parent breadcrumb - added in TWiki-6.0.1
  • SEARCH: Control over formfield rendering in a formatted SEARCH - added in TWiki-6.0.2
  • Add encode, newline, nofinalnewline, allowanytype to INCLUDE variable
  • Add subwebs and depth parameters to WEBLIST variable
  • Add section parameter to ADDTOHEAD variable
  • Add encode and decode functions to TWiki::Func
  • Add LWP parameters to TWiki::Func::getExternalResource
  • Conditional Skin based on group membership and other criteria
  • Finer-control variable expansion in topic creation
  • Add topic parameter to VAR variable to get settings defined in another topic
  • Add raw parameter to INCLUDE variable to include a topic in the raw mode
  • New csv encode type for ENCODE variable - added in TWiki-6.0.1
  • ENCODE variable with new type="json" parameter to escape a string for JSON use - added in TWiki-6.0.2

• Security Enhancements
  • Support for an implicit "all users" group
  • Empty DENY setting means undefined setting
  • Dynamic access control (experimental)
  • Upgrade support for secure email notification
  • Restrict HTTP variable to not reveal certain header fields
  • User masquerading to check if access restriction is working as expected for another user
  • Disable XSS Protection for JavaScript

• Extensions Enhancements
  • Add new WatchlistPlugin to core and deprecate MailerContrib
  • Add new TWikiDashboardAddOn to core distribution
  • Add new ScrollBoxAddOn to core distribution
  • Add new DatePickerPlugin to core and deprecate JSCalendarContrib
  • Add new MovedSkin to core distribution
  • SpreadSheetPlugin supports hash variables with new functions GETHASH(), HASH2LIST(), HASHCOPY(), HASHEACH(), HASHEXISTS(), HASHREVERSE(), LIST2HASH(), SETHASH(), SETMHASH()
  • SpreadSheetPlugin adds new functions BIN2DEC(), DEC2BIN(), DEC2HEX(), DEC2OCT(), HEX2DEC(), OCT2DEC()
  • SpreadSheetPlugin supports quoted parameters with '''triple quotes'''
  • SpreadSheetPlugin: New functions ADDLIST(), GETLIST(), SETLIST() - added in TWiki-6.0.1
  • SpreadSheetPlugin: FORMAT(CURRENY, ...) with support for currency symbol - added in TWiki-6.0.1
  • SpreadSheetPlugin: Allow newlines and indent around functions and function parameters; allow newlines in triple-quoted strings - added in TWiki-6.0.1
  • SpreadSheetPlugin: New functions EQUAL(), NOTE(), RANDSTRING() - added in TWiki-6.0.2
  • InterwikiPlugin to observe the links configuration parameter
  • TablePlugin: Possible to add TML (TWiki markup) with newlines in TWiki table cells
  • TagMePlugin with support for multiple tag namespaces
  • PatternSkin: New hideInPrint CSS class to hide specific content from printing - added in TWiki-6.0.1
  • PatternSkin: Show history and other topic actions in read-only skin mode - added in TWiki-6.0.1
  • SetGetPlugin: SET and GET with support for JSON objects and JSON path - added in TWiki-6.0.2
  • SetGetPlugin: Ability to specify store name to persistently store variables - added in TWiki-6.0.2
  • SetGetPlugin: SetGetPlugin: Use file locking on persistent store to prevent corrupting the store - added in TWiki-6.0.2
  • JQueryPlugin: JQTAB enhancements: Show blue link instead of red on hover over tab; make tab css overridable; remove dotted underline below tab; active tabs with gray gradient - added in TWiki-6.0.1
  • JQueryPlugin: Option to load tab content asynchronously; select specific tab in jQuery tab pane; allow tab panes in bullet lists & TWiki table cells; allow HTML in tab title - added in TWiki-6.0.2
  • WatchlistPlugin: Don't notify oneself when watching topics; set minor change when updating watchlist topic - added in TWiki-6.0.1
  • WatchlistPlugin: Watch all topics in web and watch new topics in web; fix for mod_perl - added in TWiki-6.0.1

• Miscellaneous Feature Enhancements
  • CGI Engine to be made Fast CGI compatible
  • Empty IF condition to be regarded valid and false
  • Add seconds to the timestamp in debug/log/warn
  • Viewing topic text with variables expanded
  • WEBLIST canmoveto and cancopyto
  • Add viewRedirectHandler callback to plugins API
  • No such topic, no such web, access denied are done right
    • Return "404 Not Found" status for topic not found instead of 200 OK status
    • Return "404 Not Found" status and show "No Such Web" page title for no such web without redirecting to an oops URL titled "Access Denied"
    • Return "403 Access Denied" status for access denied without redirecting to an oops URL whose status code is "200 OK"
  • Statistics enhancements to show most viewed webs, most updated webs, most popular webs, top viewers, # of unique users who viewed, saved, and uploaded on the web/site, affiliation breakdown
  • Specifying webs to be excluded from WebStatistics update
  • Statistics topics can be annualized to e.g. WebStatistics2013, WebStatistics2014. This prevents statistics topics from growing indefinitely
  • For paragraphs generate <p>...</p> instead of <p/>
  • 20 new TWikiDocGraphics icons
  • 16 new TWikiDocGraphics icons - added in TWiki-6.0.1
  • 5 new TWikiDocGraphics icons - added in TWiki-6.0.2
  • New COPY, REG, TM variables for copyright, registered trademark and trademark symbols, respectively - added in TWiki-6.0.1

• Bug Fixes
  • 99 bugs fixed in TWiki-6.0.0
  • 66 bugs fixed in TWiki-6.0.1
  • 53 bugs fixed in TWiki-6.0.2

See the full list of new features and bug fixes in TWikiReleaseNotes06x00.

Hall of Fame of TWiki Release 6.0

Many people have been involved in creating TWiki 6.0. Special thanks go to the most active contributors in the following areas:

• Sponsor and facilitator: TWiki:Main.PeterThoeny
• Spec and code: TWiki:Main.PeterThoeny, TWiki:Main.HideyoImazu, TWiki:Main.MahiroAndo, TWiki:Main.YaojunFei, TWiki:Main.GeorgeTrubisky, TWiki:Main.SopanShewale, TWiki:Main.DipuDeshmukh, TWiki:Main.AaronLWalker, TWiki:Main.TaitCyrus, TWiki:Main.MichaelGulitz, TWiki:Main.TimotheLitt, TWiki:Main.PeterJones, TWiki:Main.IanBerdei, TWiki:Main.MikeDoherty, TWiki:Main.IanKluft, TWiki:Main.ThomasWeigert, TWiki:Main.MateuszPles, TWiki:Main.MichaelBerger2012
• Testing and bug fixing: TWiki:Main.HideyoImazu, TWiki:Main.GeorgeTrubisky, TWiki:Main.HaraldJoerg, TWiki:Main.MahiroAndo, TWiki:Main.YaojunFei, TWiki:Main.DavidDAllen, TWiki:Main.VickyBrown, TWiki:Main.PeterThoeny, TWiki:Main.SopanShewaley, TWiki:Main.GeorgeClark, TWiki:Main.TomCrane, TWiki:Main.AaronLWalker, TWiki:Main.JosephZamzow, TWiki:Main.JulianCollins, TWiki:Main.RolandOldenburg, TWiki:Main.SteveKelem, TWiki:Main.TerjeAndersen, TWiki:Main.WillemEngen, TWiki:Main.StefanScherer, TWiki:Main.GertjanVanOosten, TWiki:Main.LisaTanguay, TWiki:Main.GuangyuShi, TWiki:Main.PhillipHuang, TWiki:Main.MauritzHansen, TWiki:Main.JohnWorsley, TWiki:Main.PaulMerchantJr
• Documentation: TWiki:Main.PeterThoeny, TWiki:Main.HideyoImazu, TWiki:Main.MahiroAndo, TWiki:Main.TerjeAndersen, TWiki:Main.JonForrest, TWiki:Main.VickyBrown, TWiki:Main.ThomasWeigert, TWiki:Main.TaitCyrus, TWiki:Main.EricRiebling, TWiki:Main.UweWahser, TWiki:Main.ScottFredericksen, TWiki:Main.StephenCarville, TWiki:Main.MarkBloore, TWiki:Main.WillemEngen, TWiki:Main.AlanDuan, TWiki:Main.TreyFore, TWiki:Main.GuyKroizman, TWiki:Main.RobRobason, TWiki:Main.LouisAh, TWiki:Main.StephanHennig, TWiki:Main.LonnieSandersIII, TWiki:Main.DavidTonhofer
• Release package builds: TWiki:Main.GeorgeTrubisky, TWiki:Main.PeterThoeny, TWiki:Main.HideyoImazu
• Usability: TWiki:Main.PeterThoeny
• Translations: Coordinated by TWiki:Main.PeterThoeny
  • Bulgarian: TWiki:Main.KrassimirBerov
  • Chinese (simplified and traditional): TWiki:Main.CheDong
  • Czech: TWiki:Main.VladimirMarek, TWiki:Main.JaromirHoudek
  • Danish: TWiki:Main.ChristianOtkjaer, TWiki:Main.PeterLorenzen, TWiki:Main.ErikJohansen
  • Dutch: TWiki:Main.WoutMertens, TWiki:Main.TomArnst
  • Finnish: TWiki:Main.HeikkiToivonen
  • French: TWiki:Main.JeanbDupont, TWiki:Main.JeanFruitet, TWiki:Main.RodolpheVidal
  • German: TWiki:Main.MartinRaabe
  • Italian: TWiki:Main.MassimoMancini
  • Japanese: TWiki:Main.HideyoImazu, TWiki:Main.KenYuminaga
  • Korean: TWiki:Main.JeremySuk, TWiki:Main.JustinKim
  • Polish: TWiki:Main.ZbigniewKulesza
  • Portuguese: TWiki:Main.CarlinhosCecconi
  • Russian: TWiki:Main.AndreyTkachenko, TWiki:Main.SergejZnamenskij, TWiki:Main.SergeyJSinx
  • Spanish: TWiki:Main.EnriqueMelendez, TWiki:Main.SebastianKlus, TWiki:Main.MiguelABayona
  • Swedish: TWiki:Main.TorstenEriksson, TWiki:Main.ErikAman
  • Ukrainian: TWiki:Main.SerhijDubyk
• Marketing: TWiki:Main.PeterThoeny, TWiki:Main.VickyBrown
• Meetups: TWiki:Main.PeterThoeny
• TWiki.org wiki champions: TWiki:Main.BrianMartinUK, TWiki:Main.DarrenLichty, TWiki:Main.DavidAllen, TWiki:Main.GeorgeTrubisky, TWiki:Main.HeatherStern, TWiki:Main.JitendraKavathekar, TWiki:Main.JohnRouillard, TWiki:Main.JonForrest, TWiki:Main.HideyoImazu, TWiki:Main.MadhuriYevale, TWiki:Main.MichaelGulitz, TWiki:Main.MichaelSprague, TWiki:Main.PeterThoeny, TWiki:Main.RichMorin, TWiki:Main.RuedigerPlantiko, TWiki:Main.SopanShewale, TWiki:Main.SteveKelem, TWiki:Main.TaitCyrus, TWiki:Main.TerjeAndersen, TWiki:Main.ThomasGutzmann, TWiki:Main.ThomasWeigert, TWiki:Main.TimotheLitt, TWiki:Main.VickyBrown

  <-- Blog, Codev, Plugins, TWiki webs -->

• Customer support: TWiki:Main.CarlaReitzenstein, TWiki:Main.ChengappaCB, TWiki:Main.EnriqueCadalso, TWiki:Main.JonForrest, TWiki:Main.JoshuaTharp, TWiki:Main.MichaelSevero, TWiki:Main.PeterThoeny, TWiki:Main.VickyBrown

  <-- Support web -->

• System administration: TWiki:Main.ChrisLahti, TWiki:Main.PeterThoeny, TWiki:Main.SopanShewale, TWiki:Main.TimotheLitt

If you find an omission please fix it at TWiki:TWiki.TWikiHistory. For the full list of contributors see TWikiContributor.

See more details on the TWiki 6.0 release at TWikiReleaseNotes06x00.

TWiki Release 5.1 (Istanbul) released on 2011-08-20 — 2013-02-16

New Features and Enhancements of TWiki Release 5.1

• Usability Enhancements
  • API and GUI for point and click user data management
  • Support disabled users in password manager
  • More visual user profile pages with in-place editing of form fields and picture selector
  • In-place editing of TWiki group settings using PreferencesPlugin
  • Point and click bookmarks for better usability
  • Improved statistics showing overall site usage over time, such as total number of webs, topics, users, etc
  • TopMenuSkin: Option for auto-hidden or fixed top menu-bar; in auto-hidden mode, menu is always accessible with stub - added in TWiki-5.1.2
• TWiki Application Platform Enhancements
  • Macro language with parameterized variables
  • Ability to auto-create page on view if it does not exist
  • Relative heading levels for INCLUDE
  • Relative heading levels for SEARCH
• Security Enhancements
  • Set a flag to force password change on next login
  • S/Mime support for notification e-mails
• Miscellaneous Feature Enhancements
  • TWikiDocGraphics: Added 2 new icons, and updated 1 icon - added in TWiki-5.1.1
  • TWikiDocGraphics: Added 25 new icons, and updated 2 icons - added in TWiki-5.1.2
  • TWikiDocGraphics: Added 5 new icons - added in TWiki-5.1.3
  • TWikiDocGraphics: Added 5 new icons - added in TWiki-5.1.4
  • User profile pages with CSS based box shadow and rounded corners - added in TWiki-5.1.3
  • TWiki logs: Log user agent for all users; log additional info via extralog URL parameter - added in TWiki-5.1.4
• Plugin Enhancements
  • New BackupRestorePlugin to easily backup, restore and upgrade TWiki installations
  • BackupRestorePlugin: Add restore from backup feature - added in TWiki-5.1.1
  • CommentPlugin: Send comment to multiple e-mail addresses; better layout & nicer look of default comment box - added in TWiki-5.1.3
  • New ColorPickerPlugin to pick a color in form fields
  • New SetGetPlugin that can store variables persistently
  • SetGetPlugin: Add REST interface - added in TWiki-5.1.2
  • SetGetPlugin: GET variable with format parameter - added in TWiki-5.1.3
  • SpreadSheetPlugin: New functions BITXOR(), HEXENCODE(), HEXDECODE(), XOR()
  • SpreadSheetPlugin: New functions FLOOR() and CEILING() - added in TWiki-5.1.1
  • SpreadSheetPlugin: New CALCULATE variable using the register tag handler for variable evaluation with proper inside-out, left-to-right eval order; new functions $ISDIGIT(), $ISLOWER(), $ISUPPER(), $ISWIKIWORD() and $FILTER() - added in TWiki-5.1.2
  • SpreadSheetPlugin: New function $STDEV(), $STDEVP(), $VAR(), $VARP() - added in TWiki-5.1.3
• Bug Fixes
  • 21 bugs fixed in TWiki-5.1.0
  • 17 bugs fixed in TWiki-5.1.1
  • 29 bugs fixed in TWiki-5.1.2
  • 19 bugs fixed in TWiki-5.1.3
  • 11 bugs fixed in TWiki-5.1.4

See the full list of new features and bug fixes in TWikiReleaseNotes05x01.

Hall of Fame of TWiki Release 5.1

Many people have been involved in creating TWiki 5.1. Special thanks go to the most active contributors in the following areas:

• Sponsor and facilitator: TWiki:Main.PeterThoeny
• Spec and code: TWiki:Main.PeterThoeny, TWiki:Main.SopanShewale, TWiki:Main.GeorgeTrubisky, TWiki:Main.PeterJones, TWiki:Main.ChrisLahti, TWiki:Main.TimotheLitt, TWiki:Main.ThomasWeigert, TWiki:Main.IanKluft, TWiki:Main.HideyoImazu
• Testing and bug fixing: TWiki:Main.GeorgeTrubisky, TWiki:Main.GertjanVanOosten, TWiki:Main.JohnWorsley, TWiki:Main.JosephZamzow, TWiki:Main.JulianCollins, Wiki:Main.PhillipHuang, TWiki:Main.SopanShewale, TWiki:Main.PaulMerchantJr, TWiki:Main.PeterThoeny, TWiki:Main.RolandOldenburg, TWiki:Main.StefanScherer, TWiki:Main.StefanWalter, TWiki:Main.SpirosDenaxas, TWiki:Main.ThomasWeigert, TWiki:Main.TimotheLitt, TWiki:Main.WillemEngen, TWiki:Main.MahiroAndo, TWiki:Main.YaojunFei
• Documentation: TWiki:Main.PeterThoeny, TWiki:Main.ThomasWeigert, TWiki:Main.ScottGutman, TWiki:Main.SebastianKlus, TWiki:Main.DavidWTucker, TWiki:Main.JonasThomsen, TWiki:Main.MichaelRoberts, TWiki:Main.TaitCyrus, TWiki:Main.TorstenEriksson
• Release package builds: TWiki:Main.GeorgeTrubisky
• Usability: TWiki:Main.PeterThoeny
• Translations: Coordinated by TWiki:Main.PeterThoeny
  • Bulgarian: TWiki:Main.KrassimirBerov
  • Chinese (simplified and traditional): TWiki:Main.CheDong
  • Czech: TWiki:Main.JaromirHoudek, TWiki:Main.VladimirMarek
  • Danish: TWiki:Main.ChristianOtkjaer, TWiki:Main.PeterLorenzen, TWiki:Main.ErikJohansen
  • Dutch: TWiki:Main.WoutMertens, TWiki:Main.TomArnst
  • Finnish: TWiki:Main.HeikkiToivonen
  • French: TWiki:Main.JeanbDupont, TWiki:Main.JeanFruitet, TWiki:Main.RodolpheVidal
  • German: TWiki:Main.MartinRaabe
  • Italian: TWiki:Main.MassimoMancini
  • Japanese: TWiki:Main.KenYuminaga
  • Korean: TWiki:Main.JeremySuk, TWiki:Main.JustinKim
  • Polish: TWiki:Main.ZbigniewKulesza
  • Portuguese: TWiki:Main.CarlinhosCecconi
  • Russian: TWiki:Main.AndreyTkachenko, TWiki:Main.SergejZnamenskij, TWiki:Main.SergeyJSinx
  • Spanish: TWiki:Main.EnriqueMelendez, TWiki:Main.SebastianKlus, TWiki:Main.MiguelABayona
  • Swedish: TWiki:Main.TorstenEriksson, TWiki:Main.ErikAman
  • Ukrainian: TWiki:Main.SerhijDubyk
• Marketing: TWiki:Main.PeterThoeny, TWiki:Main.BrianMellea
• Public relations: TWiki:Main.PeterThoeny, TWiki:Main.BrianMellea
• Meetups: TWiki:Main.PeterThoeny
• TWiki.org wiki champions: TWiki:Main.PeterThoeny, TWiki:Main.ThomasWeigert, TWiki:Main.TimotheLitt, TWiki:Main.TaitCyrus, TWiki:Main.GeorgeTrubisky, TWiki:Main.SopanShewale, TWiki:Main.DanielRohde, TWiki:Main.DipuDeshmukh, TWiki:Main.IanKluft

  <-- Blog, Codev, Plugins, TWiki webs -->

• Customer support: TWiki:Main.PeterThoeny, TWiki:Main.EnriqueCadalso, TWiki:Main.CarlaReitzenstein, TWiki:Main.ScottGutman, TWiki:Main.AaronLWalker, TWiki:Main.TimotheLitt

  <-- Support web -->

• System administration: TWiki:Main.ChrisLahti, TWiki:Main.PeterThoeny, TWiki:Main.SopanShewale