TWiki Reference Manual (Thu, 29 Sep 2005 build 6683)

This page contains all documentation topics as one long, complete reference sheet.
Doubleclick anywhere to return to the top of the page.

Note - if you are reading this at twiki.org, then you are reading about the code running on that site.
If you want to read about the features on your local TWiki, then you should read the documentation there!

Note: Read the most up to date version of this document at http://TWiki.org/cgi-bin/view/TWiki/TWikiDocumentation

Related Topics: TWikiSite, TWikiHistory, TWikiPlannedFeatures, TWikiEnhancementRequests, UserDocumentationCategory, AdminDocumentationCategory


TWiki System Requirements

Server and client requirements

Low client and server requirements are core features that keep TWiki widely deployable, particularly across a range of browser platforms and versions.

Server Requirements

TWiki is written in Perl 5, uses a number of shell commands, and requires RCS (Revision Control System), a GNU Free Software package. TWiki is developed in a basic Linux/Apache environment. It also works with Microsoft Windows, and should have no problem on any other platform that meets the requirements.

ResourceRequired Server Environment *
Perl 5.005_03 or higher (5.8.4 or higher is recommended)
RCS 5.7 or higher (including GNU diff)
Optional, TWiki includes a pure perl implementation of RCS that can be used instead (though it's slower)
GNU diff GNU diff 2.7 or higher is required when not using the all-Perl RcsLite.
Install on PATH if not included with RCS (check version with diff -v)
Must be the version used by RCS, to avoid problems with binary attachments - RCS may have hard-coded path to diff
Other external programs fgrep, egrep
Cron/scheduler • Unix: cron
• Windows: cron equivalents
Web server Apache is well supported; for other servers, see the TWiki:Codev.CategoryCookbook lists

The following Perl modules are used by TWiki:

ModulePreferred versionDescription
CGI::Carp >=1.26 Required. Available from the CPAN archive.
CGI::Cookie >=1.24 Optional. Available from the CPAN archive.
CGI::Session >=3.95 Optional. Available from the CPAN archive.
Config >=0 Required. Available from the CPAN archive.
Cwd >=3.05 Required. Available from the CPAN archive.
Data::Dumper >=2.121 Required. Available from the CPAN archive.
File::Copy >=2.06 Required. Available from the CPAN archive.
File::Find >=1.05 Required. Available from the CPAN archive.
File::Spec >=3.05 Required. Available from the CPAN archive.
FileHandle? >=2.01 Required. Available from the CPAN archive.
IO::File >=1.10 Required. Available from the CPAN archive.
Locale::Maketext::Lexicon >=0 Optional. Available from the CPAN archive.
Net::SMTP >=2.29 Optional. Used for sending mail.
Time::Local >=1.11 Required. Available from the CPAN archive.
Most of them will probably already be available in your installation. You can check if they are available from the command-line like this

Client Requirements

The TWiki standard installation has extremely low browser requirements:

CSS and Javascript are used in most skins, though there is a low-fat skin (Classic skin) available that minimises these requirements. Some skins will require more recent releases of browsers. The default skin (Pattern) is tested on IE 6, and Mozilla 5.0 based browsers (such as Firefox).

You can easily select a balance of browser capability versus look and feel.

Important note about TWikiPlugins

Related Topics: AdminDocumentationCategory


TWiki Installation Guide

Installation instructions for the TWiki Dakar production release

Please review the AdminSkillsAssumptions before you install TWiki.

TWiki should be fine with any web server and OS that meet the system requirements. See the cookbooks list at TWiki:Codev.CategoryCookbook for guidance for your particular platform.

If you need help, ask a question in the TWiki:Support web or on TWiki:Codev.TWikiIRC (irc.freenode.net, channel #twiki)

Basic Installation

  1. Download the TWiki distribution from http://TWiki.org/download.html.
  2. Make a directory for the installation and unpack the distribution in it.
  3. Make sure the user that runs CGI scripts on your system can read and write all files in the distribution.
    Detailed instructions on file permissions are beyond the scope of this guide, but in general:
  4. Make sure Perl 5 and the Perl CGI library are installed on your system.
    The default location of Perl is /usr/bin/perl. If it's somewhere else, change the path to Perl in the first line of each script in the twiki/bin directory.
    help Some systems require a special extension on perl scripts (e.g. .cgi or .pl). If necessary, rename all files in twiki/bin (i.e. rename view to view.pl etc). If you do this, make sure you set the ScriptSuffix option in configure (Step 6).
  5. Create the file /twiki/bin/LocalLib.cfg.
    There is a template for this file in /twiki/bin/LocalLib.cfg.txt.
    The file must contain a setting for $twikiLibPath, which must point to the absolute file path of your twiki/lib e.g. /home/httpd/twiki/lib.
    help If you need to install additional CPAN modules, but can't update the main Perl installation files on the server, you can set $CPANBASE to point to your personal CPAN install. Don't forget that the webserver user has to be able to read those files as well.
  6. Configure the webserver so you can execute the bin/configure script from your browser.
  7. Run the configure script from your browser, and resolve any errors or warnings it tells you about.
You now have a basic, unauthenticated installation running. At this point you can just point your Web browser at http://yourdomain.com/twiki/bin/view and start TWiki-ing away!

Next Steps (optional)

Once you have your TWiki running, you can move on to customise it for your users.

Troubleshooting

The first step is to re-run the configure script and make sure you have resolved all errors, and are happy that you understand any warnings.

Failing that, please check the topics listed below, they include some important tips for HP-UX, Solaris, OS/390, and many other platforms.

If you need help, ask a question in the TWiki:Support web or on IRC (irc.freenode.net, channel #twiki)


TWiki Upgrade Guide

Upgrade from the previous TWiki Sep-2004 "Cairo" production release to TWiki "Dakar"

Overview

Dakar is a major new release. You can chose between an automated upgrade using a script or a manual update.

Upgrade Requirements

Major Changes Compared to TWiki Cairo

SEE TWiki:Codev.DakarReleaseNotes FOR NOW

Automated Upgrade Procedure

If you would prefer to do things manually, skip to the manual upgrade procedure below.

The upgrade script is called "UpgradeTwiki", and is found in the root of the distribution. It can be run by any user, though you will need to make sure you correct permissions so the webserver user can write all files in the new installation when you have finished. The upgrade script does not write to your existing installation.

The upgrade script will upgrade the TWiki core only. Plugins will need to be upgraded separately.

It will:

To perform the upgrade, you need to:

Assuming all goes well, UpgradeTwiki will give you the final instructions.

There are a few points worth noting:

If you use it, and would be kind enough to add your experiences to TWiki:Codev.UpgradeTWiki, it would be much appreciated. The report of your experience will help to make UpgradeTwiki more robust.

Manual Upgrade Procedure

The following steps are a rough guide to upgrading only. It is impossible to give detailed instructions, as what you have to do may depend on whether you can configure the webserver or not, and how much you have changed distributed files in your current TWiki release.

  1. Follow the installation instructions, and install the new release in a new directory.
  2. Copy your local webs over to the data and pub directories of the new install
  3. Examine your old TWiki.cfg, and for each local setting, set the corresponding value in the configure interface for the new install.
  1. Transfer any local settings from TWikiPreferences to the topic pointed at by {LocalSitePreferences} (usually TWikiPreferences). This avoids having to write over files in the distribution.
  2. If you changed any of the topics in the original TWiki distribution, you will have to transfer your changes to the new install manually. There is no simple way to do this, though the following procedure may help:
    1. Install a copy of the original TWiki release you were using in a temporary directory
    2. Use 'diff' to find changed files, and transfer the changes into the new Dakar install.
    3. Install updated plugins into your new area.
  3. Point your webserver at the new install.

You are highly recommended not to change any distributed files if you can avoid it, to simplify future upgrades!


TWiki User Authentication

TWiki site access control and user activity tracking options

Authentication, or "login", is the process by which a user lets TWiki know who they are.

Authentication isn't just to do with access control. TWiki uses authentication to identify users, and uses those identities to keep track of who made changes, and manage a wide range of personal settings. With authentication enabled, users can personalise their environment and contribute as recognised individuals, instead of anonymous shadows.

TWiki authentication is extremely flexible, and can either stand alone or integrate with existing authentication schemes. You can set up TWiki to require authentication for every access, or set it up to require authentication only for changes. Authentication is also essential for effective access control.

Quick Authentication Test - Use the %WIKIUSERNAME% variable to return your current identity:

TWiki user authentication is split into three sections; password management, user registration, and login management. Password management deals with how users are recognised (authenticated). Registration deals with how new users are added to the wiki. Login management deals with how users log in.

Once a user is logged on, they are remembered using a cookie in the browser, known as a "session cookie". This avoids them having to log on again and again.

Password Management

As shipped, TWiki supports the Apache 'htpasswd' password manager. This manager supports the use of .htpasswd files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encoding schemes are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the configure interface for more details.

New User Registration

New user registration uses the password manager to set and change passwords. It is also responsible for the new user verification process. the registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegsitration? page (for admins only).

The registration process is responsible for creating user topics.

Login Management

Login management controls the way users have to log in. There are three basic options; no login, login via a TWiki login page, and login using the webserver authentication support.

You can select your chosen login through the Security Settings pane in the configure interface.

No Login

Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.

Template Login

Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out.

Enabling Template Login

  1. Use the configure interface to
    1. enable the TemplateLogin login manager (on the Security Settings pane).
    2. select the appropriate password manager for your system, or provide your own.
  2. Register yourself in the TWikiRegistration topic.
    help Check that the password manager recongises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
  3. Create a new topic to check if authentication works.
  4. Edit the TWikiAdminGroup topic in the TWiki:Main web to include users with system administrator status.
    warning This is a very important step, as users in this group can access all topics, independent of TWiki access controls.

TWikiAccessControl has more information on setting up access controls.

warning At this time TWikiAccessControls cannot control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up in the webserver to allow open access you may want to add .htaccess files in there to restrict access.

tip You can create a custom version of the TWikiRegistration form by deleting or adding input tags. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.

tip You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics

Apache Login

Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which is set when you enable authentication in the webserver.

The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules such as mod_auth_ldap or mod_auth_mysql you can just plug in directly to them.

The disadvantage is that because the user identity is cached in the browser, you can log in, but you can't log out again.

TWiki maps the REMOTE_USER that was used to log in to the webserver to a WikiName using the table in TWikiUsers. This table is updated whenever a user registers, so users can choose not to register (in which case their webserver login name is used for their signature) or register (in which case that login name is mapped to their WikiName).

The same private .htpasswd file used in TWiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support. This allows the TWiki registration support to maintain usernames and passwords.

Enabling Apache Login using mod_auth

You can use any other Apache authentication module that sets REMOTE_USER.
  1. Use configure to select the ApacheLogin login manager.
  2. Use configure to set up TWiki to create the right kind of .htpasswd entries.
  3. Create a .htaccess file in the twiki/bin directory.
    help There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what need to be done.
    help If you got it right, the browser should now ask for login name and password when you click on the Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, email web server support)
    warning At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
  4. You can create a custom version of TWikiRegistration by deleting or adding input tags. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.
    You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics
  5. Register yourself in the TWikiRegistration topic.
    help Check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you may have got a path wrong, or the permissions may not allow the webserver user to write to that file.
  6. Create a new topic to check if authentication works.
  7. Edit the TWikiAdminGroup topic in the TWiki:Main web to include users with system administrator status.
    warning This is a very important step, as users in this group can access all topics, independent of TWiki access controls.
TWikiAccessControl has more information on setting up access controls.

Logons via bin/logon

Any time a user enters a page that needs authentication, they will be forced to log on. It may be convenient to have a "logon" as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log on.

The bin/logon script accomplishes this. The bin/logon script must be setup in the bin/.htaccess file to be a script which requires a valid user. However, once authenticated, it will simply redirect the user to the view URL for the page from which the logon script was linked.

Sessions

TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions using cookies. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using IP matching. However this is inherently insecure and you are strongly advised against it.

There are a number of TWikiVariables available that you can use to interrogate your current session. You can even add your own session variables to the TWiki cookie. Session variables are referred to as "sticky" variables.

Getting, Setting, and Clearing Session Variables

You can get, set, and clear session variables from within TWiki web pages or by using script parameters. This allows you to use the session as a personal "persistent memory space" that is not lost until the web browser is closed. Also note that if a session variable has the same name as a TWiki preference, the session variables value takes precedence over the TWiki preference. This allows for per-session preferences.

To make use of these features, use the tags:

Cookies and Transparent Session IDs

TWiki normally uses cookies to store session information on a client computer. Cookies are a common way to pass session information from client to server. TWiki cookies simply hold a unique session identifier that is used to look up a database of session information on the TWiki server.

For a number of reasons, it may not be possible to use cookies. In this case, TWiki has a fallback mechanism; it will automatically rewrite every internal URL it sees on pages being generated to one that also passes session information.

TWiki Username vs. Login Username

This section applies only if you are using authentication with existing login names (i.e. mapping from login names to WikiNames).

TWiki internally manages two usernames: Login Username and TWiki Username.

TWiki can automatically map an Intranet (Login) Username to a TWiki Username if the {AllowLoginName} is enabled in configure. The default is to use your WikiName as a login name.

NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:
Main.WikiUsername or %MAINWEB%.WikiUsername
This points WikiUser to the Main web, where user registration pages are stored, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic? everywhere but in the Main web.

Changing Passwords

If your {PasswordManager} supports password changing, you can change and reset passwords using forms on regular pages.


TWiki Access Control

Restricting read and write access to topics and webs, by Users and groups

TWikiAccessControl allows you restrict access to single topics and entire webs, by individual user and by user Groups, in three areas: view; edit & attach; and rename/move/delete. Access control, combined with TWikiUserAuthentication, lets you easily create and manage an extremely flexible, fine-grained privilege system.

An Important Control Consideration

Open, freeform editing is the essence of WikiCulture - what makes TWiki different and often more effective than other collaboration tools. For that reason, it is strongly recommended that decisions to restrict read or write access to a web or a topic are made with care - the more restrictions, the less Wiki in the mix. Experience shows that unrestricted write access works very well because:

As a collaboration guideline:

Authentication vs. Access Control

Authentication: Identifies who a user is based on a login procedure. See TWikiUserAuthentication.

Access control: Restrict access to content based on users and groups once a user is identified.

Users and Groups

Access control is based on the familiar concept of Users and Groups. Users are defined by their WikiNames. They can then be organized in unlimited combinations by inclusion in one or more user Groups. For convenience, Groups can also be included in other Groups.

Managing Users

A user can create an account in TWikiRegistration. The following actions are performed:

Users can be authenticated using Basic Authentication (htaccess) or SSL (secure server). In either case, TWikiUserAuthentication is required in order to track user identities, and use User and Group access control.

The default visitor name is TWikiGuest. This is the non-authenticated user.

Managing Groups

Groups are defined by group topics created in the Main web, like the TWikiAdminGroup. To create a new group:

  1. Edit TWikiGroups by entering a new topic with a name that ends in Group. Example:
  2. Set Preferences for two Variables in the new group topic:
  3. These are summarised on SitePermissions

The SuperAdminGroup

By mistyping a user or group name in the ALLOWTOPICCHANGE setting, it's possible to lock a topic so that no-one can edit it from a browser. To avoid this, you can create superusers:

Restricting Access

You can define who is allowed to read or write to a web or a topic. Note that some plugins may not respect access permissions.

Controlling access to a Web

You can define restrictions of who is allowed to view a TWiki web. You can restrict access to certain webs to selected Users and Groups, by:

Controlling access to a Topic

Remember when opening up access to specific topics within a restricted web that other topics in the web - for example, the WebLeftBar - may also be accessed when viewing the topics. The message you get when you are denied access should tell you what topic you were not permitted to access.

Controlling access to Attachments

Attachments are referred to directly, and are not normally indirected via TWiki scripts. This means that the above instructions for access control will not apply to attachments. It is possible that someone may inadvertently publicise a URL that they expected to be access-controlled.

The easiest way to apply the same access control rules for attachments as apply to topics is to use the Apache mod_rewrite module, and configure your webserver to redirect accesses to attachments to the TWiki viewfile script. For example,

That way all the controls that apply to the topic also apply to attachments to the topic.

How TWiki evaluates ALLOW/DENY settings

When deciding whether to grant access, TWiki evaluates the following rules in order (read from the top of the list; if the logic arrives at PERMITTED or DENIED that applies immediately and no more rules are applied). You need to read the rules bearing in mind that VIEW, CHANGE and RENAME access may be granted/denied separately.

  1. If the user is a super-user
  2. If DENYTOPIC is set to a list of wikinames
  3. If DENYTOPIC is set to empty ( i.e. Set DENYTOPIC = )
  4. If ALLOWTOPIC is set
    1. people in the list are PERMITTED
    2. everyone else is DENIED
      • Note that this means that setting ALLOWTOPIC to empty denies access to everyone except admins (unless DENYTOPIC is also set to empty, as described above)
  5. If DENYWEB is set to a list of wikiname
  6. If ALLOWWEB is set to a list of wikinames
  7. If you got this far, access is PERMITTED

Access Control quick recipes

Obfusticating Webs

Another way of hiding webs is to keep them hidden by not publishing the URL and by preventing the all webs search option from accessing obfuscated webs. Do so by enabling the NOSEARCHALL variable in WebPreferences:

This setup can be useful to hide a new web until content its ready for deployment.

warning Obfuscating webs is insecure, as anyone who knows the URL can access the web.

Authenticate all Webs and Restrict Selected Webs

Use the following setup to authenticate users for topic viewing in all webs and to restrict access to selected webs:

  1. Restrict view access to selected Users and Groups. Set one or both of these variables in its WebPreferences topic:
  2. Hide the web from an "all webs" search. Enable this restriction with the NOSEARCHALL variable in its WebPreferences topic:
  3. Add view to the list of authenticated scripts in the .htaccess file.

help This method only works if the view script is authenticated, which means that all Users have to login, even for read-only access. (An open guest account, like TWikiGuest, can get around this, allowing anyone to login to a common account with, for example, view-only access for public webs.) TWikiInstallationGuide has more on Basic Authentication, using the .htaccess file.

Authenticate and Restrict Selected Webs Only

Use the following setup to provide unrestricted viewing access to open webs, with authentication only on selected webs:

  1. Restrict view access to selected Users and Groups. Set one or both of these variables in its WebPreferences topic:
  2. Hide the web from an "all webs" search. Enable this restriction with the NOSEARCHALL variable in its WebPreferences topic:
  3. Enable {RememberUserIPAddress} in http://localhost/CLEAN/bin/configure as described in TWikiUserAuthentication. TWiki will now remember the IP address of an authenticated user.
  4. Copy the view script to viewauth (or better, create a symbolic link)
  5. Add viewauth to the list of authenticated scripts in the .htaccess file. The view script should not be listed in the .htaccess file.

When a user accesses a web where you enabled view restriction, TWiki will redirect from the view script to the viewauth script once (this happens only if the user has never edited a topic). Doing so will ask for authentication. The viewauth script shows the requested topic if the user could log on and if the user is authorized to see that web.

warning Authenticating webs is not very secure, as there is a way to circumvent the read access restriction. It can be useful in certain situations - for example, to simplify site organization and clutter, by hiding low traffic webs - but is not recommended for securing sensitive content.

Hide Control Settings

tip To hide access control settings from normal browser viewing, place them in comment markers.

<!--
   * Set DENYTOPICCHANGE = Main.SomeGroup
-->


TWiki Text Formatting

Working in TWiki is as easy as typing in text. You don't need to know HTML, though you can use it if you prefer. Links to topics are created automatically when you enter WikiWords. And TWiki shorthand gives you all the power of HTML with a simple coding system that takes no time to learn. It's all laid out below.

TWiki Editing Shorthand

Formatting Command: You write: You get:
Paragraphs:
Blank lines will create new paragraphs.
1st paragraph

2nd paragraph

Headings:
Three or more dashes at the beginning of a line, followed by plus signs and the heading text. One plus creates a top level heading, two pluses a second level heading, etc. The maximum heading depth is 6.

You can create a table of contents with the %TOC% variable. If you want to exclude a heading from the TOC, put !! after the ---+.

warning Empty headings are allowed, but won't appear in the table of contents.

Sushi

Maguro

Exclude from TOC
Bold Text:
Words get shown in bold by enclosing them in * asterisks.
Bold
Italic Text:
Words get shown in italic by enclosing them in _ underscores.
Italic
Bold Italic:
Words get shown in bold italic by enclosing them in __ double-underscores.
Bold italic
Fixed Font:
Words get shown in fixed font by enclosing them in = equal signs.
Fixed font

Bold Fixed Font:
Words get shown in bold fixed font by enclosing them in double equal signs.
Bold fixed
tip You can follow the closing bold, italic, or other (* _ __ = ==) indicator with normal punctuation, such as commas and full stops.

warning Make sure there is no space between the text and the indicators.

This works,
_this does not _
Separator (horizontal rule):
Three or more three dashes at the beginning of a line..

Bulleted list:
Multiple of three spaces, an asterisk, and another space.
  • bullet item level 1
    • bullet item level 2
      • bulleted item level 3
  • back to level 1
Numbered List:
Multiple of three spaces, a type character, a dot, and another space. Several types are available besides a number:
TypeGenerated StyleSample Sequence
1. Arabic numerals 1, 2, 3, 4...
A. Uppercase letters A, B, C, D...
a. Lowercase letters a, b, c, d...
I. Uppercase Roman Numerals I, II, III, IV...
i. Lowercase Roman Numerals i, ii, iii, iv...

  1. Mammals
    1. Rodents
      1. Rats
      2. Mice
      3. Capybaras
    2. Bats
      1. Pipistrelle
      2. Horseshoe
Definition List:
Three spaces, a dollar sign, the term, a colon, a space, followed by the definition.
Sushi
Japan
Dim Sum
S.F.
Table:
Each row of the table is a line containing of one or more cells. Each cell starts and ends with a vertical bar '|'. Any spaces at the beginning of a line are ignored.
  • to make a cell a header, put the text in asterisks | *bold* |
  • to center the contents of a cell, put an equal number of spaces on either side of the text (you need more than one space on each side)
  • to right-align, put more spaces on the left | right-spaced |=
  • to span multiple columns, put the |='s right next to each other =| 2 colspan ||
  • You can split rows over multiple lines by putting a backslash '\' at the end of each line
  • Contents of table cells wrap automatically as determined by the browser.
tip The TablePlugin? increases the number of things you can do with tables - for example, you can control formatting, and create multi-row spans.
LCR
A2 2 2
A3 3 3
multi span
A4-6 four four
WikiWord Links:
CapitalizedWordsStuckTogether (or WikiWords) will produce a link automatically.
If you want to link to a topic in a different TWiki web write Otherweb.TopicName. (The link label is the the name of the web if it is WebHome, otherwise it is the topic name)
WebNotify

TWikiUsers

Verbatim (Literal) text:
Surround code excerpts and other formatted text with <verbatim> and </verbatim> tags. Each tag must be on a line by itself.

tip verbatim tags disable HTML code. Use <pre> and </pre> tags instead if you want the HTML code within the tags to be interpreted.

Anchors:
You can define a reference inside a TWiki topic (called an anchor name) and link to that. To define an anchor write #AnchorName at the beginning of a line. The anchor name must be a WikiWord. To link to an anchor name use the [[MyTopic#MyAnchor]] syntax. You can omit the topic name if you want to link within the same topic.
WikiWord#NotThere

Jump

To here

Forced Links:
You can create a forced internal link by enclosing words in double square brackets.
Text within the brackets may contain optional spaces; the topic name is formed by capitalizing the initial letter and by removing the spaces; for example, [[text formatting FAQ]] links to topic TextFormattingFAQ. You can also refer to a different web and use anchors.
tip To "escape" double square brackets that would otherwise make a link, prefix the leading left square bracket with an exclamation mark !
wiki syntax

Main.TWiki users

escaped: [[wiki syntax]]

Specific Links:
You can create a link where you specify the link text and the URL separately using nested square brackets [[reference][text]]. Internal link references (e.g. WikiSyntax) and URLs (e.g. http://TWiki.org/) are both supported. The rules described under Forced Links apply for internal link references.
tip Anchor names can be added as well, to create a link to a specific place in a topic.
wiki syntax

GNU

write to the Barretts

here

Prevent a Link:
Prevent a WikiWord from being linked by prepending it with an exclamation mark.
SunOS
Disable Links:
You can disable automatic linking of WikiWords by surrounding text with <noautolink> and </noautolink> tags. Each tag must be on a line by itself.
RedHat & SuSE

Using HTML

You can use just about any HTML tag without a problem - however, there are a few usability and technical considerations to keep in mind.

tip TWiki converts shorthand notation to HTML for display. To copy a fully marked-up page, simply view source in your browser and save the contents. If you need to save HTML frequently, you may want to check out TWiki:Plugins/PublishAddOn.

warning NOTE: TWiki requires that the opening and closing angle brackets - <...> - of an HTML tag must be on the same line, or the tag will be broken.

Script tags

You can use HTML <script> tags in for your TWiki applications. However note that your TWiki administrator can disable <script> in topics, and may have chosen to do so for security considerations. TWiki markup and TWikiVariables are not expanded inside script tags.

Hyperlinks

Being able to create links without any special formatting is a core TWiki feature, made possible with WikiWords and inline URLs.

Internal Links

External Links

TWiki Variables

TWiki Variables are names that are enclosed in percent signs % that are expanded on the fly.

TWikiPlugin Formatting Extensions

Plugins can extend the functionality of TWiki into many other areas. There are a huge number of TWiki plugins available from the Plugins web on TWiki.org.

Currently enabled plugins on this TWiki installation, as listed by %PLUGINDESCRIPTIONS%:

Check on current Plugin status and settings for this site in TWikiPreferences.

Common Editing Errors

TWiki formatting rules are fairly simple to use and quick to type. However, there are some things to watch out for, taken from the TextFormattingFAQ:


TWiki Variables

Special text strings expand on the fly to display user data or system info

TWikiVariables are text strings - %VARIABLE% - that expand into content whenever a page is rendered for viewing. VARIABLES are replaced by data, either user-entered or automatically generated by TWiki (like the date, or the current username). There are predefined variables, and Preference variables that you can configure. You can also define custom variables, with new names and values.

Notes:

Predefined Variables

Most predefined variables return values that were either set in the configuration when TWiki was installed, or taken from server info (like current username, or date and time). Many of the variables let you format the appearance of the display results.

This version of TWiki - Thu, 29 Sep 2005 build 6683 - expands the following variables (enclosed in % percent signs):

ACTIVATEDPLUGINS -- list of currently activated plugins

ATTACHURL -- full URL for attachments in the current topic

ATTACHURLPATH -- path of the attachment URL of the current topic

AUTHREALM -- authentication realm

BASETOPIC -- base topic where an INCLUDE started

BASEWEB -- base web where an INCLUDE started

DATE - signature format date

warning When used in a template topic, this variable will be expanded when the template is used to create a new topic. See TWikiTemplates for details.

DISPLAYTIME -- display time

DISPLAYTIME{"format"} -- formatted display time

ENCODE{"string"} -- encodes a string

ENDSECTION{"name"} -- Marks the end of a named section

FAILEDPLUGINS -- debugging for plugins that failed to load, and handler list