TWiki Reference Manual (04 Sep 2004 $Rev: 1742 $)

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

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

TWiki System Requirements

Server and client requirements for TWiki 01-Feb-2003

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.

* Current documentation mainly covers Linux and Apache installations. See WindowsInstallCookbook for a Windows installation guide. See TWiki:Codev.TWikiOn for help with installation on various platforms including Unix, MacOS X, Apache mod_perl, web hosts, etc.

Client Requirements

The TWiki standard installation has extremely low browser requirements:

• HTML 3.2 compliant
• generates XHTML 1.0 pages that are compatible with HTML 3.2
• minimal use of JavaScript in the user interface (degrades gracefully)
• no cookies
• no CSS

You can easily add functionality, by customizing TWikiTemplates, for one, while tailoring the browser requirements to your situation.

Known Issues

• The TWikiPlugins feature currently does not have compatibility guidelines for developers. Plugins can require just about anything - browser-specific functions, stylesheets (CSS), Java applets, cookies, specific Perl modules,... - check the individual Plugin specs.
  • Plugins included in the TWiki distribution do not add requirements.

-- MikeMannix - 12 Jan 2002

TWiki Installation Guide

Installation instructions for the TWiki 01-Feb-2003 production release. Update notes for the new RCS configuration are marked Dataframework.

These installation steps are based on the Apache web server on Linux. TWiki runs on other web servers and Unix systems, and should be fine with any web server and OS that meet the system requirements. Documentation for other platforms is somewhat limited:

• For Unix or Linux, check TWiki:Codev/TWikiOnUnix and TWiki:Codev/TWikiOnLinux.
• For Windows, check the WindowsInstallCookbook.
• For MacOS X, check TWiki:Codev/TWikiOnMacOSX.
• To install TWiki on SourceForge, for use on a software development project, read TWiki:Codev/TWikiOnSourceForge
• For other platforms, see TWiki:Codev/TWikiOn, and search the TWiki:Codev and TWiki:Support webs for other installation notes.

Standard Installation

Request and download the TWiki 01-Feb-2003 distribution in Unix ZIP format from http://TWiki.org/download.html. Please review the AdminSkillsAssumptions before you install TWiki.

Step 1: Create & Configure the Directories

NOTE: If you don't have access to your Web server configuration files - for example, if you're installing on an ISP-hosted account, or you don't have administrator privileges on your intranet server - use the alternative Step 1 instead.

• Create directory /home/httpd/twiki and unzip the TWiki distribution into this directory.
• The twiki/bin directory of TWiki must be set as a cgi-bin directory. Add /home/httpd/twiki/bin to file /etc/httpd/httpd.conf with only ExecCGI option.
• The twiki/pub directory of TWiki must be set so that it is visible as a URL. Add /home/httpd/twiki to file httpd.conf with normal access options (copy from /home/httpd/html ).
• Now add ScriptAlias for /twiki/bin and Alias for /twiki to file httpd.conf .
  NOTE: The ScriptAlias must come before the Alias, otherwise, Apache will fail to correctly set up /twiki/bin/, by treating it as just another subdirectory of the /twiki/ alias.
• The twiki/data and twiki/templates directories should be set so that they are not visible as URLs. Add them to httpd.conf with deny from all.

Example httpd.conf entries:

 ScriptAlias /twiki/bin/ "/home/httpd/twiki/bin/"
 Alias /twiki/ "/home/httpd/twiki/"
 <Directory "/home/httpd/twiki/bin">
    Options +ExecCGI
    SetHandler cgi-script
    Allow from all
 </Directory>
 <Directory "/home/httpd/twiki/pub">
    Options FollowSymLinks +Includes
    AllowOverride None
    Allow from all
 </Directory>
 <Directory "/home/httpd/twiki/data">
    deny from all
 </Directory>
 <Directory "/home/httpd/twiki/templates">
    deny from all
 </Directory>

• Restart Apache by /etc/rc.d/rc5.d/S85httpd restart .
• Test that the twiki/bin directory is CGI-enabled by trying visiting it in your browser:
  • Enter the URL for the bin directory, http://yourdomain.com/twiki/bin/.
  • Your settings are OK if you get a message like "Forbidden. You don't have permission to access /twiki/bin/ on this server".
  • Settings are NOT correct if you get something like "Index of /twiki/bin" - recheck your httpd.conf file.

• Go directly to Step 2...

Step 1 for Non-Root Accounts

To install TWiki on a system where you don't have Unix/Linux root (administrator) privileges, for example, on a hosted Web account or an intranet server administered by someone else:

• Download and unzip TWiki on your local PC
• Using the table below, create a directory structure on your host server
• Upload the TWiki files by FTP (transfer as text except for the image files in pub)

TWiki dir:	What it is:	Where to copy:	Example:
twiki	start-up pages	root TWiki dir	/home/smith/twiki/
twiki/bin	CGI bin	CGI-enabled dir	/home/smith/twiki/bin
twiki/lib	library files	same level as twiki/bin	/home/smith/twiki/lib
twiki/pub	public files	htdoc enabled dir	/home/smith/twiki/pub
twiki/data	topic data	dir secure from public access	/home/smith/twiki/data
twiki/templates	web templates	dir secure from public access	/home/smith/twiki/templates

If you are not able to create the twiki/lib directory at the same level as the twiki/bin directory (e.g. because CGI bin directories can't be under your home directory and you don't have root access), you can create this directory elsewhere and edit the setlib.cfg file in the bin directory:

    # -------------- Change these settings if required

    $twikiLibPath = '/some/other/path/lib';   # Path to lib directory containing TWiki.pm

You can also edit $localPerlLibPath in the setlib.cfg file if you are not root and need to install additional CPAN modules, but can't update the main Perl installation files on the server. Just set this variable to the full pathname to your local lib directory, typically under your home directory.

Step 2: Set File Permissions

• 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 elsewhere, change the path to Perl in the first line of each script in the twiki/bin directory, or create a symbolic link from /usr/bin/perl.
  • IMPORTANT: On ISP-hosted accounts, Perl CGI scripts usually require a .cgi extension to run. Some systems need .pl, the regular Perl extension. Modify all twiki/bin script filenames if necessary.
• Set the file permission of all Perl scripts in the twiki/bin directory as executable to -rwxr-xr-x (755).
• To be able to edit the Perl scripts and .tmpl files it is necessary to chown and chgrp -R twiki so all the files have the owner you want.
• This Guide assumes user nobody ownership for all files manipulated by the CGI scripts (executed by the Web server), and user twiki for all other files. You can:
  • replace nobody with another user if your server executes scripts under a different name (ex: default for Debian is www-data).
    • HINT: Run the testenv script from your browser: http://yourdomain.com/twiki/bin/testenv. It will show you the user name of the CGI scripts, a table listing all CGI environment variables, and a test of your twiki/lib/TWiki.cfg configuration file (you'll configure that in a minute).
  • replace user twiki with your own username
• Set the permission of all files below twiki/data so that they are writable by user nobody. A simple way is to chmod them to -rw-rw-r-- (664) and to chown them to nobody.
• Set the permission of the twiki/data directory and its subdirectories so that files in there are writable by user nobody. A simple way is to chmod them to drwxrwxr-x (775) and to chown them to nobody.
• Set the permission of the twiki/pub directory and all its subdirectories so that files in there are writable by user nobody. A simple way is to chmod them to drwxrwxr-x (775) and to chown them to nobody.
• The twiki/data/*/*.txt,v RCS repository files in the installation package are locked by user nobody. If your CGI scripts are not running as user nobody, it's not possible to check in files (you'll see that the revision number won't increase after saving a topic). In this case, you need to unlock all repository files (check the RCS man pages) and lock them with a different user, ex www-data, or delete them all - new files will be automatically created the first time each topic is edited. A simple way to change ownership is with a search-and-replace in all files; for example, using perl:

cd twiki/data
perl -pi~ -e 's/nobody:/www-data:/' */*,v

Step 3: Set the Main Configuration File

• Edit the file twiki/lib/TWiki.cfg, setting the variables to your needs.
  • Set the file extension in the $scriptSuffix variable to cgi or pl if required.
  • RCS - revision control system to store revision of topics and attachments. You can use RCS executables or a version of RCS written in Perl, note that as the time of writing (Apr 2002) the Perl version has not been widely tested, so if you want to put up a live site the RCS executables are recommended.
    • Set $storeTopicImpl = "RcsWrap"; for the RCS executables and make sure RCS is installed. Set $rcsDir in twiki/lib/TWiki.cfg to match the location of your RCS binaries. You can check this by issuing the command rcs at the prompt, it should result in something like "rcs: no input file".
      • Check that you have GNU diff, by typing diff -v - an error indicates you have a non-GNU diff, so install the GNU diffutils package and make sure that diff is on the PATH used by TWiki (see $safeEnvPath in the TWiki.cfg file).
    • Set $storeTopicImpl = "RcsLite"; for the Perl based RCS
• Security issue: Directories twiki/data , twiki/templates and all their subdirectories should be set so that they are not visible through URLs. (Alternatively, move the directories to a place where they are not visible, and change the variables in twiki/lib/TWiki.cfg accordingly)
• Test your settings by running the testenv script from your browser: http://yourdomain.com/twiki/bin/testenv. Check if your twiki/lib/TWiki.cfg configuration file settings are correct.

Step 4: Configure Site-Wide Email Preferences

• From your web browser, edit the TWikiPreferences topic in the TWiki:TWiki web to set the WIKIWEBMASTER email address, and other email settings required for registration and WebChangesAlert to work:
  • WIKIWEBMASTER should be set to the email address of the TWiki administrator
  • SMTPMAILHOST is typically set on Windows or other non-Unix/Linux systems, where sendmail or similar is not available. When this is set and the Perl module Net::SMTP is installed, TWiki will connect to this SMTP server (e.g. mail.yourdomain.com) to send email for user registration and WebChangesAlerts. If you do have a sendmail-type program, leave SMTPMAILHOST unset so that the external sendmail program is used instead (defined by $mailProgram in TWiki.cfg).
  • SMTPSENDERHOST is optional, and set to the domain name sending the email (e.g. twiki.yourdomain.com). For use where the SMTP server requires that you identify the TWiki server sending mail. If not set, Net::SMTP will guess it for you.
• You may want to set up other TWikiPreferences later on.

Step 5: Finish Up from Your Browser

• Point your Web browser at http://yourdomain.com/twiki/bin/view and start TWiki-ing away!
  • Or, point to http://yourdomain.com/twiki/ to get the pre-TWiki index.html page, with a link to the view script. Customize this page if you want a public intro screen with a login link, instead of immediately calling up the .htaccess login dialog by going directly to view.
• Edit the WebPreferences topic in each web, if necessary: set individual WEBCOPYRIGHT messages, and other preferences.
• Enable email notification of topic changes, TWikiSiteTools has more.
• Edit the WebNotify topic in all webs and add the users you want to notify.
• Add the TWiki:Main/PoweredByTWikiLogo to your Main topic.
• You can add new %VARIABLES%. Define site-level variables in the TWikiPreferences topic. See also: TWikiVariables.

That's it for the standard virgin installation of TWiki. Read on for server-level customization options.

Additional Server-Level Options

With your new TWiki installation up and running, you can manage most aspects of your site from the browser interface. Only a few functions require access to the server file system, via Telnet or FTP. You can make these server-level changes during installation, and at any time afterwards.

Enabling Authentication of Users

• If TWiki is installed on a non-authenticated server - not using SSL - and you'd like to authenticate users:
  1. Rename file .htaccess.txt in the twiki/bin directory to .htaccess and change it to your needs. For details, consult the HTTP server documentation (for Apache server: [1], [2]). In particular, the following red part needs to be configured correctly:
     Redirect /urlpathto/twiki/index.html http://yourdomain.com/urlpathto/twiki/bin/view
AuthUserFile /filepathto/twiki/data/.htpasswd
ErrorDocument 401 /urlpathto/twiki/bin/oops/TWiki/TwikiRegistration?template=oopsauth
     • NOTE: If you had to add a .cgi or .pl file extension to the bin scripts, make sure to do the same for edit, view, preview, and all the other script names in .htaccess.
     • The browser should ask for login name and password when you click on the Edit link. In case .htaccess does not have the desired effect, you need to enable it: Add "AllowOverride All" to the Directory [3] section of access.conf for your twiki/bin directory.
       • This applies only if you have root access: on hosted accounts, you shouldn't have this problem - otherwise, email tech support.
     • NOTE: In the TWiki distribution package, the twiki/data/.htpasswd.txt file contains several TWiki core team user accounts and a guest user account. You probably want to remove those accounts by deleting the entries in .htpasswd. Do not remove the guest user if you want to allow guest logins.
  2. Copy the TwikiRegistrationPub^? topic to TwikiRegistration, overwriting old version of TwikiRegistration. Do that by either editing the topics in theTWiki web, or by renaming the .txt and .txt,v files in the twiki/data/TWiki directory.
• Customization:
  • You can customize the registration 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.
  • You can customize the default user home page in NewUserTemplate.
• Register yourself in the TwikiRegistration topic.
  • NOTE: When a user registers, a new line with the username and encrypted password is added to the data/.htpasswd file. The .htpasswd file that comes with the TWiki installation includes user accounts for TWiki core team members that are used for testing on TWiki.org. You can edit the file and delete those lines.
• Create a new topic to check if authentication works.
• Edit the TWikiAdminGroup topic in the TWiki:Main web to include users with system administrator status.
• Edit the TWikiPreferences topic in the TWiki:TWiki web to set access privileges.
• Edit the WebPreferences topic in each web, if necessary: set access priviliges.

That's it for a basic new web set-up!

Optionally, you can also:

• Create custom web-specific templates in a new twiki/templates/Someweb directory (otherwise, templates are inherited from twiki/templates).
• Add TWikiForms for form-based page input that's stored separately from the main free-form topic text.

NOTE: User home topics are located in the TWiki.Main web - don't try to move them or create them in other webs. From any other web, user signatures have to point to TWiki.Main web, using a Main.UserName or %MAINWEB%.UserName format. (The %MAINWEB% variable is an advantage if you ever change the Main web name, but the standard Main.UserName is easier for users to enter, which is the bottom line!

TWiki File System Info

See Appendix A: TWiki File System for an installed system snapshot and descriptions of all files in the TWiki 01-Sep-2001 distribution.

-- PeterThoeny - 28 Dec 2002
-- MikeMannix - 16 May 2002

TWiki Upgrade Guide

Upgrade from the previous TWiki 01-Dec-2001 production release to TWiki 01-Feb-2003

Overview

This guide describes how to upgrade from TWiki 01-Dec-2001 to TWiki 01-Feb-2003. The new version involves several new features and numerous enhancements to the previous version.

Upgrade Requirements

• To upgrade from a 01-Dec-2001 standard installation to the latest 01-Feb-2003 TWiki Production Release, follow the instructions below.

• NOTE: To upgrade from a pre-01-Dec-2001 TWiki, start with TWikiUpgradeTo01Dec2001.

• To upgrade from a Beta of the new release, or if you made custom modifications to the application, read through all new reference documentation, then use the procedure below as a guideline.

Major Changes from TWiki 01-Dec-2001

• Form and script to create new webs
• Enhanced Plugin API to manipulate topic data with new functions in TWikiFuncModule: readTopicText, saveTopicText, setTopicEditLock, checkTopicEditLock
• New Plugin hooks registrationHandler, beforeEditHandler, afterEditHandler, beforeSaveHandler, writeHeaderHandler, redirectCgiQueryHandler, getSessionValueHandler, setSessionValueHandler
• Internationalization ('I18N') support 8-bit character sets in WikiWords, such as ISO-8859-15, KOI8-R
• Possible to omit e-mail address in WebNotify, in which case the e-mail is taken from the user's home page; if the WikiName is a group name, a notification is sent to all members of the group
• New data storage framework that lets you use external RCS commands for revision control, or a new native Perl implementation that does not depend on the external RCS commands (not recommended yet for production use, see TWiki:Codev/RcsLite)
• New AND search; with regular expression enabled, use the semicolon ";" as the AND operator in %SEARCH{}% variable, FormattedSearch and WebSearch
• Many more enhancements, see the complete change log at TWikiHistory

Upgrade Procedure from 01-Dec-2001 to 01-Feb-2003 Release

The following steps describe the upgrade assuming that $TWIKIROOT is the root of your current 01-Dec-2001 release. As written this will require some downtime. A process for switching over without downtime is described at the end of this section.

1. Back up and prepare:
   • Back up all existing TWiki directories $TWIKIROOT/bin, $TWIKIROOT/pub, $TWIKIROOT/data, $TWIKIROOT/templates, $TWIKIROOT/lib.
   • Create a temporary directory and unpack the ZIP file there.
2. Update files in TWiki root:
   • Overwrite all *.html and *.txt files in $TWIKIROOT with the new ones.
3. Update template files:
   • Overwrite all template files in $TWIKIROOT/templates with the new ones.
     • If you have customized your templates, make sure to merge those changes to the new files.
   • If you have customized skins or loaded new skins, make sure to merge or apply those changes to the new files.
   • Specific changes to templates and skins:
     • Replace %WIKIHOMEURL% with %WIKILOGOURL%
     • Replace img tag's src=%PUBURLPATH%/wikiHome.gif with src=%WIKILOGOIMG%
     • Replace img tag's alt="TWiki Home" with alt="%WIKILOGOALT%"
     • Replace meta tag's charset=iso-8859-1" with charset=ISO-8859-1"
     • Add %TOPIC% to form action of GoBox
     • For internationalized sites, URL encode webs and topics in all form actions, e.g. replace .../view%SCRIPTSUFFIX%/%WEB%/%TOPIC%" with .../view%SCRIPTSUFFIX%/%INTURLENCODE{"%WEB%/%TOPIC%"}%
4. Update script files:
   • Overwrite all script files in $TWIKIROOT/bin with the new ones.
     • If necessary, change the script names to include the required extension, e.g. .cgi
   • Edit $TWIKIROOT/bin/setlib.cfg and point $twikiLibPath to the absolute file path of $TWIKIROOT/lib
   • Edit $TWIKIROOT/bin/.htaccess to include a directive for the new manage script:
     <Files "manage">
    require valid-user
</Files>
   • Pay attention to the file and directory permissions, the scripts need to be executable, e.g. chmod 775 $TWIKIROOT/bin/*
   • If on Non-Unix host, make sure the correct path to the perl interpreter is changed in the first line of every script file. See also WindowsInstallCookbook.
5. Update library files:
   • Overwrite the TWiki.cfg configuration file in $TWIKIROOT/lib with the new one.
   • Restore the configuration values from the backup. You typically need to configure just the ones in the section "variables that need to be changed when installing on a new server".
   • Overwrite the TWiki.pm library in $TWIKIROOT/lib with the new one.
   • Copy and overwrite all subdirectories below $TWIKIROOT/lib with the new ones. Make sure to preserve any extra Plugins you might have in $TWIKIROOT/lib/TWiki/Plugins
   • Pay attention to the file and directory permissions, the library files should not be executable, e.g. chmod -R 664 $TWIKIROOT/lib/*
6. Update data files:
   • Run the bin/testenv script from the browser (e.g. http://localhost/bin/testenv) to verify if the cgi-scripts are running as user nobody.
     • In case not: The *,v RCS repository files delivered with the installation package are locked by user nobody and need to be changed to the user of your cgi-scripts, e.g. www-data:
     • Change the lock user in the temporary twiki/data/* directories where you unzipped the installation package: A simple way to switch the locker of the RCS files is to use sed in the :
       for f in *,v; do sed 's/nobody\:/www-data\:/' $f > x; mv x $f; done
   • In the temporary twiki/data/TWiki directory where you unzipped the installation package:
     • Remove the files you do not want to upgrade: InterWikis.*, TwikiRegistration.*, TwikiRegistrationPub.*, WebNotify.*, WebPreferences.*, WebStatistics.* and all WebTopic* files.
   • Rename in the temporary directory the file $TWIKIROOT/data/TWiki/TWikiPreferences.* to TWikiPreferencesSave.*.
   • Move all remaining *.txt and *.txt,v files from the temporary data/TWiki directory to your $TWIKIROOT/data/TWiki directory, overwriting the existing ones.
   • Merge your original TWikiPreferencesSave.txt settings into $TWIKIROOT/data/TWiki/TWikiPreferences.txt.
   • Move the data/_default directory from the temporary location to your $TWIKIROOT/data directory.
   • Move the data/Sandbox directory from the temporary location to your $TWIKIROOT/data directory
     (The Test web has been renamed to Sandbox in this release.)
     • There are now two webs in parallel (Test and Sandbox) for the purpose of testing (experimenting) TWiki.
       Move all relevant topics from Test web to Sandbox web, or motivate the users to do.
   • Make sure that the directories and files below $TWIKIROOT/data are writable by your cgi-script user.
7. Adapt the other webs (all other than TWiki and _default):
   • Merge the new files WebHome.txt and WebPreferences.txt of your other webs to make sure, you have the improvements applied also in your other webs.
8. Update pub files:
   • Move all subdirectories below pub/TWiki from your temporary directory into your $TWIKIROOT/pub/TWiki directory.
   • Make sure that the directories and files below $TWIKIROOT/pub/TWiki are writable by your cgi-script user.
   • Move all files in pub/icn directory from the temporary location to your $TWIKIROOT/pub/icn directory.
9. Update TWikiPreferences to authorize users to create webs:
   • Add ALLOWWEBMANAGE to the FINALPREFERENCES list so that nobody can overwrite the setting:
     • Set FINALPREFERENCES = WIKIWEBMASTER, PREVIEWBGIMAGE, SMTPMAILHOST, SMTPSENDERHOST, ALLOWWEBMANAGE
   • Set users or groups allowed to create new webs:
     • Set ALLOWWEBMANAGE = TWikiAdminGroup
10. Verify installation:
    • Execute the $TWIKIROOT/bin/testenv script from your browser (e.g. http://localhost/bin/testenv) to see if it reports any issues; fix any potential problems.
    • Test your updated TWiki installation to see if you can view, create, edit and rename topics; upload and move attachments; register users.
    • Test if the installed Plugins work as expected. You should see the list of installed Plugins in TextFormattingRules.

Note: These steps assume a downtime during the time of upgrade. You could install the new version in parallel to the existing one and switch over in an instant without affecting the users. As a guideline, install the new version into $TWIKIROOT/bin1, $TWIKIROOT/lib1, $TWIKIROOT/templates1, $TWIKIROOT/data/TWiki1 (from data/TWiki), $TWIKIROOT/pub/TWiki1 (from pub/TWiki), and configure TWiki.cfg to point to the same data and pub directory like the existing installation. Once tested and ready to go, reconfigure $TWIKIROOT/bin1/setlib.cfg and $TWIKIROOT/lib1/TWiki.cfg, then rename $TWIKIROOT/bin to $TWIKIROOT/bin2, $TWIKIROOT/bin1 to $TWIKIROOT/bin. Do the same with the lib, templates and data/TWiki directories.

Known Issues

• Check TWiki:Codev/KnownIssuesOfTWiki01Feb2003 for known issues of TWiki 01-Feb-2003 production release

-- PeterThoeny - 01 Feb 2002
-- MartinRaabe^? - 15 Jan 2003

TWiki User Authentication

TWiki site access control and user activity tracking options

TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable Basic Authentication (.htaccess) or SSL "secure server" authentication (https protocol).

TWiki uses visitor identification to keep track of who made changes to topics at what time and to manage a wide range of personal site settings. This gives a complete audit trail of changes and activity.

Authentication Options

No special installation steps are required if the server is already authenticated. If it isn't, you have three standard options for controlling user access:

1. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
   
2. Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server.
   
3. Use Basic Authentication (.htaccess) to control access by protecting key scripts: attach, edit=, installpasswd, preview, rename, save, upload using the .htaccess file. The TWikiInstallationGuide has step-by-step instructions.

Partial Authentication

Tracking by IP address is an experimental feature, enabled in lib/TWiki.cfg. It lets you combine open access to some functions, with authentication on others, with full user activity tracking:

• Normally, the REMOTE_USER environment variable is set for the scripts that are under authentication. If, for example, the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.

• TWiki can be configured to remember the IP address/username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non-authenticated scripts, like view, will show the correct username instead of TWikiGuest.

• Enable this feature by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki then persistently stores the IP address/username pairs in the file, $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default.

• This approach can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.

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

• You are Main.guest

TWiki Username vs. Login Username

This section applies only if your TWiki site is installed on a server that is both authenticated and on an intranet.

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

• Login Username: When you login to the intranet, you use your existing login username, ex: pthoeny. This name is normally passed to TWiki by the REMOTE_USER environment variable, and used internally. Login Usernames are maintained by your system administrator.

• TWiki Username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TwikiRegistration; doing so also generates a personal home page in the Main web.

TWiki can automatically map an Intranet (Login) Username to a TWiki Username, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.

• In the original TWiki distribution, in twiki/data, there are two registration form topics, TwikiRegistration and TwikiRegistrationPub^?. The original form includes an intranet Login Username field. For Basic Authentication, the original form is replaced by the Pub version. If you started using TWiki on Basic Authentication and want to change, you have to switch back forms for future use, and manually correct the existing entries, by editing TWikiUsers, adding the Login Username for each member - PeterThoeny - pthoeny - 01 Jan 1999 - and also in the .htpasswd file, where you can either replace the WikiNames or duplicate the entries and have both, so both usernames will work. verification and clearer rewrite to follow in a bit. also link to original installation mention.

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 TWiki.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

Change and reset passwords using forms on regular pages. Use TWikiAccessControl to restrict use as required.

• The ChangePassword form ( TWiki/ChangePassword ):

Change password

Forgot your old password? Then use ResetPassword instead. Please only use ResetPassword in case you really forgot your password. Thank you.

Your WikiName:	**
Old password:	**
New password:	**
Retype new password:	**
	(Fields marked ** are required)

After submitting this form your password will be changed.

• The ResetPassword form ( TWiki/ResetPassword ):

Request for reset of password

Please only use this ResetPassword form in case you really forgot your password. Otherwise just change it using ChangePassword. Thank you.

Your WikiName:	**
New password:	**
Retype new password:	**
	(Fields marked ** are required)

After submitting this form you will see a page with your new password appearing encrypted.

-- MikeMannix - 19 May 2002

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:

• Peer influence is enough to ensure that only relevant content is posted.

• Peer editing - the ability for anyone to rearrange all content on a page - keeps topics focussed.

• In TWiki, content is transparently preserved under revision control:
  • Edits can be undone by the TWikiAdminGroup (the default administrators group; see #ManagingGroups).
  • Users are encouraged to edit and refactor (condense a long topic), since there's a safety net.

As a collaboration guideline:

• Create broad-based Groups (for more and varied input), and...
• Avoid creating view-only Users (if you can read it, you should be able to contribute to it).

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:

• WikiName and encrypted password are recorded in .htpasswd if authentication is enabled.
• A confirmation e-mail is sent to the user.
• A user home page with the WikiName of the user is created in the Main web.
• The user is added to the TWikiUsers topic.

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:
   • SomeGroup
2. Set Preferences for two Variables in the new group topic:
   • Set GROUP = < list of Users and/or Groups >
   • Set ALLOWTOPICCHANGE = < list of Users and/or Groups >
   • The GROUP variable is a comma-separated list of Users and/or other Groups. Example:
     • Set GROUP = Main.SomeUser, Main.OtherUser, Main.SomeGroup
   • ALLOWTOPICCHANGE defines who is allowed to change the group topic; it is a comma delimited list of Users and Groups. You typically want to restrict that to the members of the group itself, so it should contain the name of the topic. (This prevents Users not in the Group from editing the topic to give themselves or others access. For example, for the TWikiAdminGroup topic write:
   • Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup

Restricting Write Access

You can define who is allowed to make changes to a web or a topic.

Deny Editing by Topic

Denying editing of a topic also restricts file attachment; both privileges are assigned together.

• Define one or both of these variables in a topic, preferably at the end of the page:
  • Set DENYTOPICCHANGE = < list of Users and Groups >
  • Set ALLOWTOPICCHANGE = < list of Users and Groups >

• DENYTOPICCHANGE defines Users or Groups that are not allowed to make changes to the topic, with a comma-delimited list. Example:
  • Set DENYTOPICCHANGE = Main.SomeBadBoy, Main.SomeBadGirl, Main.SomeHackerGroup

• ALLOWTOPICCHANGE defines Users or Groups that are allowed to make changes to the topic. It is a comma delimited list of Users and Groups. Example:
  • Set ALLOWTOPICCHANGE = Main.SomeGoodGuy, Main.SomeGoodGirl, Main.TWikiAdminGroup

• DENYTOPICCHANGE is evaluated before ALLOWTOPICCHANGE. Access is denied if the authenticated person is in the DENYTOPICCHANGE list, or not in the ALLOWTOPICCHANGE list. Access is granted in case DENYTOPICCHANGE and ALLOWTOPICCHANGE is not defined.

Deny Editing by Web

Restricting web-level editing blocks creating new topics, changing topics or attaching files.

• Define one or both of these variable in the WebPreferences topic:
  • Set DENYWEBCHANGE = < list of Users and Groups >
  • Set ALLOWWEBCHANGE = < list of Users and Groups >

The same rules apply as for restricting topics, with these additions:

• DENYTOPICCHANGE (in topic) overrides DENYWEBCHANGE (in WebPreferences)
• ALLOWTOPICCHANGE (in topic) overrides ALLOWWEBCHANGE (in WebPreferences)

Restricting Rename Access

You can define who is allowed to rename, move or delete a topic, or rename a web.

Deny Renaming by Topic

To allow a user to rename, move or delete a topic, they also need write (editing) permission. They also need write access to change references in referring topics.

• Define one or both of these variables in a topic, preferably at the end of the topic:
  • Set DENYTOPICRENAME = < list of Users and Groups >
  • Set ALLOWTOPICRENAME = < list of Users and Groups >

• DENYTOPICCRENAME defines Users or Groups that are not allowed to rename the topic. It is a comma delimited list of Users and Groups. Example:
  • Set DENYTOPICRENAME = Main.SomeBadBoy, Main.SomeBadGirl, Main.SomeHackerGroup

• ALLOWTOPICRENAME defines Users or Groups that are allowed to rename the topic. It is a comma delimited list of Users and Groups. Example:
  • Set ALLOWTOPICRENAME = Main.SomeGoodGuy, Main.SomeGoodGirl, Main.TWikiAdminGroup

• DENYTOPICRENAME is evaluated before ALLOWTOPICRENAME. Access is denied if the authenticated person is in the DENYTOPICRENAME list, or not in the ALLOWTOPICRENAME list. Access is granted in case DENYTOPICRENAME and ALLOWTOPICRENAME is not defined.

Deny Renaming by Web

You can define restrictions of who is allowed to rename a TWiki web.

• Define one or both of these variable in the WebPreferences topic:
  • Set DENYWEBRENAME = < list of Users and Groups >
  • Set ALLOWWEBRENAME = < list of Users and Groups >

The same rules apply as for topics, with these additions:

• DENYTOPICRENAME (in topic) overrides DENYWEBRENAME (in WebPreferences)
• ALLOWTOPICRENAME (in topic) overrides ALLOWWEBRENAME (in WebPreferences)

Restricting Read Access

You can define who is allowed to see a web.

Deny Viewing by Topic

Technically it is possible to restrict read access to an individual topic based on DENYTOPICVIEW / ALLOWTOPICVIEW preferences variables, provided that the view script is authenticated. However this setup is not recommended since all content is searchable within a web - a search will turn up view restricted topics.

Deny Viewing by 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:

• obfuscating webs: Insecure but handy method to hide new webs until content is ready for deployment.
• authenticating all webs and restricting selected webs: Topic access in all webs is authenticated, and selected webs have restricted access.
• authenticating and restricting selected webs only: Provide unrestricted viewing access to open webs, with authentication and restriction only on selected webs.

Obfuscate Webs

The idea is to keep a web hidden by not publishing its URL and by preventing the all webs search option from accessing obfuscated webs. Do so by enabling the NOSEARCHALL variable in WebPreferences:

• Set NOSEARCHALL = on

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

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:
   • Set DENYWEBVIEW = < list of Users and Groups >
   • Set ALLOWWEBVIEW = < list of Users and Groups >
   • Note: DENYWEBVIEW is evaluated before ALLOWWEBVIEW. Access is denied if the authenticated person is in the DENYWEBVIEW list, or not in the ALLOWWEBVIEW list. Access is granted in case DENYWEBVIEW and ALLOWWEBVIEW is not defined.
2. Hide the web from an "all webs" search. Enable this restriction with the NOSEARCHALL variable in its WebPreferences topic:
   • Set NOSEARCHALL = on
3. Add view to the list of authenticated scripts in the .htaccess file.

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 Restricting 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:
   • Set DENYWEBVIEW = < list of Users and Groups >
   • Set ALLOWWEBVIEW = < list of Users and Groups >
   • Note: DENYWEBVIEW is evaluated before ALLOWWEBVIEW. Access is denied if the authenticated person is in the DENYWEBVIEW list, or not in the ALLOWWEBVIEW list. Access is granted in case DENYWEBVIEW and ALLOWWEBVIEW is not defined.
2. Hide the web from an "all webs" search. Enable this restriction with the NOSEARCHALL variable in its WebPreferences topic:
   • Set NOSEARCHALL = on
3. Enable the $doRememberRemoteUser flag in lib/TWiki.cfg 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.

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.

Hiding Control Settings

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

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

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 Web-based superusers:

• Set the $superAdminGroup variable in lib/TWiki.cfg to the name of a group of Users who are always allowed to edit/view topics.

$superAdminGroup = "TWikiAdminGroup";

• The default setting is not to have superusers.

-- PeterThoeny - 04 May 2002
-- MikeMannix - 12 May 2002

TWiki Text Formatting

Working in TWiki is as easy as typing in text - exactly like email. 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 layed out below - refer back to this page in a pop-up window from the Edit screen.

TWiki Editing Shorthand

1st paragraph

2nd paragraph

---++ Sushi

---+++ Maguro

*Bold*

_Italic_

__Bold italic__

=Fixed font=

==Bold fixed==

_This works_,
_this not _

<verbatim>
class CatAnimal {
  void purr() {
    <code here>
  }
}
</verbatim>

class CatAnimal {
  void purr() {
    <code here>
  }
}

-------

   * bullet item

      * nested stuff

   1 Sushi
   1 Dim Sum

   Sushi: Japan
   Dim Sum: S.F.

| *L* | *C* | *R* |
| A2 |  2  |  2 |
| A3 |  3  |  3 |
| multi span |||
| A4 | next | next |

WebNotify

Know.ReadmeFirst

[[wiki syntax]]

[[Main.TWiki users]]

[[WikiSyntax][syntax]]

[[http://gnu.org][GNU]]

[[http://xml.org XML]]

[[WebHome#NotThere]]

[[#MyAnchor][Jump]]

#MyAnchor To here

<nop>SunOS

 <noautolink>
 RedHat &
 SuSE
 </noautolink>

[[mailto:a@z.com Mail]]

[[mailto:?subject=Hi Hi]]

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.

HTML and TWiki Usability

• On collaboration pages, it's preferable NOT to use HTML, and to use TWiki shorthand instead - this keeps the text uncluttered and easy to edit.
• NOTE: TWiki is designed to work with a wide range of browsers and computer platforms, holding to HTML 3.2 compatibility in the standard installation - adding raw HTML, particularly browser-specific tags (or any other mark-up that doesn't degrade well) will reduce compatibility.

TWiki HTML Rendering

• TWiki converts shorthand notation to XHTML 1.0 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/GenHTMLAddon - it will "generate a directory containing rendered versions of a set of TWiki pages together with any attached files."
• NOTE: The opening and closing angle brackets - <...> - of an HTML tag must be on the same line, or the tag will be broken.
  • This feature allows you to enter an unclosed angle bracket - as a greater than or less than symbol - and have it automatically rendered as if you had entered its HTML character, <, ex: a > b
  • If you're pasting in preformatted HTML text and notice problems, check the file in a text processor with no text wrap. Also, save without hard line breaks on text wrap, in your HTML editing program.

Hyperlinks

Being able to create links without any formatting required is a core TWiki feature, made possible with WikiWords. New TWiki linking rules are a simple extension of the syntax that provide a new set of flexible options.

Internal Links

• GoodStyle is a WikiWord that links to the GoodStyle topic located in the current TWiki web.

• NotExistingYet^? is a topic waiting to be written. Create the topic by clicking on the ?. (Try clicking, but then, Cancel - creating the topic would wreck this example!)

External Links

• http://..., https://..., ftp://..., gopher://..., news://..., file://..., telnet://... and mailto:...@... are linked automatically.

• Email addresses like name@domain.com are linked automatically.

• [[Square bracket rules]] let you easily create non-WikiWord links.
  • You can also write [[http://yahoo.com Yahoo home page]] as an easier way of doing external links with descriptive text for the link, such as Yahoo home page.

TWiki Variables

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

• %TOC% : Automatically generates a table of contents based on headings in a topic - see the top of this page for an example.

• %WEB% : The current web, is TWiki.

• %TOPIC% : The current topic name, is TextFormattingRules.

• %ATTACHURL% : The attachment URL of the current topic. Example usage: If you attach a file to a topic you can refer to it as %ATTACHURL%/image.gif to show the URL of the file or the image in your text.

• %INCLUDE{"SomeTopic"}% : Server side include, includes another topic. The current TWiki web is the default web. Example: %INCLUDE{"TWiki.SiteMap"}%

• %SEARCH{"sushi"}% : Inline search showing the search result embedded in a topic. FormattedSearch gives you control over formatting, used to create web-based applications.

• TWikiPreferences defines site-wide variables. Among others:
  • Line break: Write %BR% to start a new line.
  • Colored text: Write: %RED% Red %ENDCOLOR% and %BLUE% blue %ENDCOLOR% colors to get: Red and blue colors.
  • Documentation Graphics: Write: %H% Help, %T% Tip, %X% Alert to get: Help, Tip, Alert. For more info see TWikiDocGraphics.

• There are many more variables, see TWikiVariables.

TWikiPlugin Formatting Extensions

Plugins provide additional text formatting capabilities and can extend the functionality of TWiki into many other areas. For example, the optional SpreadSheetPlugin lets you create a spreadsheet with the same basic notation used in TWiki tables.

Available Plugins are located in the Plugins web on TWiki.org. Currently enabled plugins on this TWiki installation, as listed by %PLUGINDESCRIPTIONS%:

• DefaultPlugin: This plugin can be used to specify some simple custom rendering rules. It also renders deprecated *_text_* as bold italic text.
• CommentPlugin: Allows users to quickly post comments to a page without an edit/preview/save cycle.
• BatchUploadPlugin: Plugin implementing TWiki:Codev.MultipleAttachmentsAtOnce
• EditTablePlugin: Edit TWiki tables using edit fields, date pickers and drop down boxes
• InterwikiPlugin: Link ExternalSite:Page text to external sites based on aliases defined in the InterWikis topic.
• RenderListPlugin: Render bullet lists in a variety of formats

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:

• Q: Text enclosed in angle brackets like <filename> is not displayed. How can I show it as it is?
  • A: The '<' and '>' characters have a special meaning in HTML, they define HTML tags. You need to escape them, so write '<' instead of '<', and '>' instead of '>'.
    Example: Type 'prog <filename>' to get 'prog <filename>'.

• Q: Why is the '&' character sometimes not displayed?
  • A: The '&' character has a special meaning in HTML, it starts a so called character entity, i.e. '©' is the © copyright character. You need to escape '&' to see it as it is, so write '&' instead of '&'.
    Example: Type 'This & that' to get 'This & that'.

-- MikeMannix - 02 Dec 2001
-- PeterThoeny - 01 Feb 2003

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 opened. When a topic is rendered for viewing, VARIABLES are replaced by data, either user-entered, or info automatically generated by TWiki (like the date, or the current username). There are predefined variables, and Preference variables that you configure. You can also define custom variables, with new names and values.

Predefined Variables

Most predefined variables return values that were either set in the lib/twiki.cfg file, 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.

• 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%.

This version of TWiki - 04 Sep 2004 $Rev: 1742 $ - expands the following variables (enclosed in % percent signs):

Variable:	Expanded to:
%WIKIHOMEURL%	The base script URL of TWiki, is the link of the Home icon in the upper left corner, is http://your.domain.com/twiki
%SCRIPTURL%	The script URL of TWiki, is http://wiki.arch.ethz.ch/twiki/bin
%SCRIPTURLPATH%	The path of the script URL of TWiki, is /twiki/bin
%SCRIPTSUFFIX%	The script suffix, ex: .pl, .cgi is
%PUBURL%	The public URL of TWiki, is http://wiki.arch.ethz.ch/twiki/pub Example: You can refer to a file attached to another topic as %PUBURL%/%WEB%/OtherTopic/image.gif
%PUBURLPATH%	The path of the public URL of TWiki, is /twiki/pub
%ATTACHURL%	The attachment URL of the current topic, is http://wiki.arch.ethz.ch/twiki/pub/TWiki/TWikiVariables Example: If you attach a file you can refer to it as %ATTACHURL%/image.gif
%ATTACHURLPATH%	The path of the attachment URL of the current topic, is /twiki/pub/TWiki/TWikiVariables
%URLPARAM{"name"}%	Returns the value of a URL parameter. Note that there is a low risk that this variable could be misused for cross-scripting. Ex: %URLPARAM{"skin"}% returns print for a .../view/TWiki/TWikiVariables?skin=print URL. Is print
%URLENCODE{"string"}%	Encodes a string for use as a URL parameter. Ex: %URLENCODE{"spaced name"}% returns spaced%20name
%WIKITOOLNAME%	The name of your TWiki site - TWiki
%WIKIVERSION%	Your current TWiki version - 04 Sep 2004 $Rev: 1742 $
%USERNAME%	Your login username - guest
%WIKINAME%	Your Wiki username. Same as %USERNAME% if not defined in the TWikiUsers topic. Is guest
%WIKIUSERNAME%	Your %WIKINAME% including the Main web name - always use full signatures - Main.guest
%MAINWEB%	The web containing TWikiUsers, OfficeLocations and TWikiGroups is Main
%TWIKIWEB%	The web containing all documentation and site-wide preference settings for TWiki - TWiki
%WEB%	The current web is TWiki
%BASEWEB%	The web name where the includes started, e.g. the web of the first topic of nested includes. Same as %WEB% in case there is no include.
%INCLUDINGWEB%	The web name of the topic that includes the current topic - same as %WEB% if there is no INCLUDE.
%HOMETOPIC%	The home topic in each web - WebHome
%NOTIFYTOPIC%	The notify topic in each web - WebNotify
%WIKIUSERSTOPIC%	The index topic of all registered users - TWikiUsers
%WIKIPREFSTOPIC%	The site-wide preferences topic - TWikiPreferences
%WEBPREFSTOPIC%	The local web preferences topic in each web - WebPreferences
%STATISTICSTOPIC%	The web statistics topic WebStatistics
%TOPIC%	The current topic name - TWikiVariables
%BASETOPIC%	The name of the topic where a single or nested INCLUDE started - same as %TOPIC% if there is no INCLUDE.
%INCLUDINGTOPIC%	The name of the topic that includes the current topic. Same as %TOPIC% in case there is no include.
%SPACEDTOPIC%	The current topic name with added spaces, for regular expression search of Ref-By, is TWiki%20*Variables
%TOPICLIST{"format"}%	Topic index of a web. The "format" defines the format of one topic item. It may include variables: The $name variable gets expanded to the topic name; the $web variable gets expanded to the name of the web. Parameters are format, separator and web: Parameter: Description: Default: "format" Format of one line, may include $name and $web variables "$name" format="format" (Alternative to above) "$name" separator=", " line separator "\n" (new line) web="Name" Name of web Current web Examples: %TOPICLIST{"   * $web.$name"}% creates a bullet list of all topics. %TOPICLIST{separator=", "}% creates a comma separated list of all topics. %TOPICLIST{" <option>$name</option>"}% creates an option list (for drop down menus).
%WEBLIST{"format"}%	Web index, ex: list of all webs. Hidden webs are excluded, e.g. webs with a NOSEARCHALL=on preference variable. The "format" defines the format of one web item. The $name variable gets expanded to the name of the web, $qname gets expanded to double quoted name, $marker to marker where web matches selection. Parameters are format, separator and web: Parameter: Description: Default: "format" Format of one line, may include $name variable "$name" format="format" (Alternative to above) "$name" separator=", " line separator "\n" (new line) webs="public" comma sep list of Web, public expands to all non-hidden "public" marker="selected" Text for $marker where item matches selection, otherwise equals "" "selected" selection="%WEB%" Current value to be selected in list section="%WEB%" Examples: %WEBLIST{"   * [[$name.WebHome]]"}% creates a bullet list of all webs. %WEBLIST{"<option $marker value=$qname>$name</option>" webs="Trash,public" selection="TWiki" separator=" "}% Dropdown of all public Webs + Trash Web, current Web highlighted.
%GMTIME%	GM time, is 06 May 2009 - 12:13
%GMTIME{"format"}%	Formatted GM time based on time variables. Variable: Unit: Example $seconds seconds 59 $minutes minutes 59 $hours hours 23 $day day of month 31 $month month in ISO format Dec $mo 2 digit month 12 $year 4 digit year 1999 $ye 2 digit year 99 Variables can be shortened to 3 characters. Example: %GMTIME{"$day $month, $year - $hour:$min:$sec"}% is 06 May, 2009 - 12:13:07
%SERVERTIME%	Server time, is 06 May 2009 - 14:13
%SERVERTIME{"format"}%	Formatted server time. Example: %SERVERTIME{"$hou:$min"}% is 14:13
%HTTP_HOST%	HTTP_HOST environment variable, is wiki.arch.ethz.ch
%REMOTE_ADDR%	REMOTE_ADDR environment variable, is 129.132.212.2
%REMOTE_PORT%	REMOTE_PORT environment variable, is 61301
%REMOTE_USER%	REMOTE_USER environment variable, is
%INCLUDE{"page" ...}%	Server side include to IncludeTopicsAndWebPages: Parameter: Description: Default: "SomeTopic" The name of a topic located in the current web, i.e. %INCLUDE{"WebNotify"}%   "Web.Topic" A topic in another web, i.e. %INCLUDE{"TWiki.SiteMap"}%   "http://..." A full qualified URL, i.e. %INCLUDE{"http://twiki.org/"}%   pattern="..." A RegularExpression pattern to include a subset of a topic or page none rev="1.2" Include a previous topic revision; N/A for URLs top revision
%STARTINCLUDE%	If present in included topic, start to include text from this location up to the end, or up to the location of the %STOPINCLUDE% variable. A normal view of the topic shows everyting exept the %STARTINCLUDE% variable itself.
%STOPINCLUDE%	If present in included topic, stop to include text at this location and ignore the remaining text. A normal view of the topic shows everyting exept the %STOPINCLUDE% variable itself.
%TOC%	Table of Contents of current topic.
%TOC{"SomeTopic" ...}%	Table of Contents. Shows a TOC that is generated automatically based on headings of a topic. Headings in WikiSyntax ("---++ text") and HTML ("<h2>text</h2>") are taken into account. Any heading text after "!!" is excluded from the TOC; for example, write "---+!! text" if you do not want to list a header in the TOC. Parameters are topic name, web and depth: Parameter: Description: Default: "TopicName" topic name Current topic web="Name" Name of web Current web depth="2" Limit depth of headings shown in TOC 6 Examples: %TOC{depth="2"}%, %TOC{"TWikiDocumentation" web="TWiki"}%
%SEARCH{"text" ...}%	Inline search, shows a search result embedded in a topic. Parameters are the search term, web, scope, order and many more: [1] Parameter: Description: Default: "text" Search term. Is a regular expression or literal, depending on the regex parameter. For regular expressions ";" is used to mean and e.g. "search;agrep" will find all topic containing search and agrep. required search="text" (Alternative to above) N/A web="Name" web="Main Know" web="all" Wiki web to search: A web, a list of webs separated by whitespace, or all webs. [2] Current web scope="topic" scope="text" Search topic name (title) or in the text (body) of the topic Topic text (body) order="topic" order="modified" order="editby" order=  "formfield(name)" Sort the results of search by the topic names, last modified time, last editor, or named field of TWikiForms Sort by topic name limit="all" limit="16" Limit the number of results returned All results regex="on" RegularExpression search; also enables ";" as and Literal search reverse="on" Reverse the direction of the search Ascending search casesensitive="on" Case sensitive search Ignore case nosummary="on" Show topic title only Show topic summary bookview="on" BookView search, e.g. show complete topic text Show topic summary nosearch="on" Suppress search string Show search string noheader="on" Suppress search header Topics: Changed: By: Show search header nototal="on" Do not show number of topics found Show number header="..." format="..." Custom format results: see FormattedSearch for usage, variables & examples Results in table Regular example: %SEARCH{"wiki" web="Main" scope="topic"}% Formatted example: %SEARCH{"FAQ" scope="topic" nosearch="on" nototal="on" header="| *Topic: * | *Summary: * |" format="| $topic | $summary |"% (displays results in a table with header - details) If the TWiki:Plugins.TablePlugin is installed, you may set a %TABLE{}% variable just before the %SEARCH{}% to alter the output of a search. Example: %TABLE{ tablewidth="90%" }%
%METASEARCH{...}%	Special search of meta data Parameter: Description: Default: type="topicmoved" What sort of search is required? "topicmoved" if search for a topic that may have been moved "parent" if searching for topics that have a specific parent i.e. its children required web="%WEB%" Wiki web to search: A web, a list of webs separated by whitespace, or all webs. required topic="%TOPIC%" The topic the search relates to required title="Title" Text that is prepended to any search results required Example: %METASEARCH{type="topicmoved" web="%WEB%" topic="%TOPIC%" title="This topic used to exist and was moved to: "}%, you may want to use this in WebTopicViewTemplate and WebTopicNonWikiTemplate %METASEARCH{type="parent" web="%WEB%" topic="%TOPIC%" title="Children: "}%
%VAR{"NAME" web="Web"}%	Get a preference value from a web other then the current one. Example: To get %WEBBGCOLOR% of the Main web write %VAR{"WEBBGCOLOR" web="Main"}%, is #FFFFFF

[1] Note: The search form uses identical names for input fields.

[2] Note: A web can be excluded from a web="all" search if you define a NOSEARCHALL=on variable in its WebPreferences.

Preferences Variables

Additional variables are defined in the preferences ( site-level ( SL ) in TWikiPreferences, web-level ( WL ) in WebPreferences of each web, and user level ( UL ) preferences in individual user topics):

Note: There are some more useful variables defined in the TWikiPreferences like %BR% for line break, colors like %RED% for colored text and small icons like %H% for a Help icon.

Setting Preferences

• The syntax for Preferences 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] = [value]
  Examples:
• Set VARIABLENAME = value
  • Set VARIABLENAME = value

Creating Custom Variables

• You can add your own Preference Variables for us across an entire site or a single web, using the standard Preferences syntax. Whatever you include in your Variable will be expanded on display, exactly as if it had been entered directly. You can place formatted text, page links, image paths.

Example: Create a custom logo variable the TWiki web

• To place a logo anywhere in a web by typing %MYLOGO%, define the Variable on the web's WebPreferences page, 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, ex: LogoTopic:
  • Set MYLOGO = %PUBURL%/TWiki/LogoTopic/mylogo.gif

-- PeterThoeny - 19 Jan 2003
-- MikeMannix - 12 May 2002

File Attachments

Each topic can have one or more files of any type attached to it by using the Attach screen to upload (or download) files from your local PC. Attachments are stored under revision control: uploads are automatically backed up; all previous versions of a modified file can be retrieved.

What Are Attachments Good For?

File Attachments can be used to create powerful customized groupware solutions, like file sharing and document management systems, and quick Web page authoring.

Document Management System

• You can use Attachments to store and retrieve documents (in any format, with associated graphics, and other media files); attach documents to specific TWiki topics; collaborate on documents with full revision control; distribute documents on a need-to-know basis using web and topic-level access control; create a central reference library that's easy to share with an user group spread around the world.

File Sharing

• For file sharing, FileAttachments on a series of topics can be used to quickly create a well-documented, categorized digital download center for all types of files: documents; graphics and other media; drivers and patches; applications; anything you can safely upload!

Web Authoring

• Through your Web browser, you can easily upload graphics (or sound files, or anything else you want to link to on a page) and place them on a single page, or use them across a web, or site-wide.
  • NOTE: You can also add graphics - any files - directly, typically by FTP upload. This requires FTP access, and may be more convenient if you have a large number of files to load. FTP-ed files can't be managed using browser-based Attachment controls. You can use your browser to create TWikiVariables shortcuts, like this %H% = .

Uploading Files

• Click on the Attach link at the bottom of the page. The Attach screen lets you browse for a file, add a comment, and upload it. The uploaded file will show up in the File Attachment table.
  • Any type of file can be uploaded. Some files that might pose a security risk are renamed, ex: *.php files are renamed to *.php.txt so that no one can place code that would be read in a .php file.
  • The previous upload path is retained for convenience. In case you make some changes to the local file and want to upload it, again you can copy the previous upload path into the Local file field.
  • Currently there is no file size limit other than the disk space on the server. * It's not recommended to upload files greater than a few hundred K through a browser. Large files can be extremely slow-loading, and often time out. Use FTP for large file uploads.

Downloading Files

• Click on the file in the File Attachment table.

• NOTE: There is no access control on individual attachments. If you need control over single files, create a separate topic per file and set topic-level access restrictions for each.

Moving Attachment Files

An attachment can be moved between topics.

• Click Action on the Attachment to be moved.
• On the control screen, select the new web and/or topic.
• Click Move. The attachment and its version history are moved. The original location is stored as topic Meta Data.

Deleting Attachments

It is not possible to delete attached files directly. You can delete a topic, and its attachments with it.

• One easy workaround is to create a Trash.TrashAttachments - then, simply move unwanted Attachments to that topic.

Linking to Attached Files

• Once a file is attached it can be referenced in the topic. Example:
  1. Attach file: Sample.txt
  2. Edit topic and enter: %ATTACHURL%/Sample.txt
  3. Preview: %ATTACHURL%/Sample.txt text appears as: http://wiki.arch.ethz.ch/twiki/pub/TWiki/FileAttachment/Sample.txt, a link to the text file.

• To reference an attachment located in another topic, enter:
  • %PUBURL%/%WEB%/OtherTopic/Sample.txt (if it's within the same web)
  • %PUBURL%/Otherweb/OtherTopic/Sample.txt (if it's in a different web)

• Attached HTML files and text files can be inlined in a topic. Example:
  1. Attach file: Sample.txt
  2. Edit topic and write text: %INCLUDE{"%ATTACHURL%/Sample.txt"}%
     • Content of attached file is shown inlined.
     • Read more in IncludeTopicsAndWebPages.

• GIF, JPG and PNG images can be attached and shown embedded in a topic. Example:
  1. Attach file: Smile.gif
  2. Edit topic and write text: %ATTACHURL%/Smile.gif
  3. Preview: text appears as , an image.

File Attachment Contents Table

Files attached to a topic are displayed in a directory table, displayed at the bottom of the page, or optionally, hidden and accessed when you click Attach.

Attachment: Action: Size: Date: Who: Comment: Sample.txt action 30 22 Jul 2000 - 19:37 PeterThoeny Just a sample Smile.gif action 94 22 Jul 2000 - 19:38 PeterThoeny Smiley face

File Attachment Controls

Clicking on an Action link takes you to a new page that looks like this:

Attachment: Action: Size: Date: Who: Comment: Attribute: Sample.txt action 30 22 Jul 2000 - 19:37 PeterThoeny Just a sample   Smile.gif action 94 22 Jul 2000 - 19:38 PeterThoeny Smiley face   Update attachment Sample.txt Version: Action: Date: Who: Comment: 1.1 view 2001.08.30.09.28.56 PeterThoeny   Previous upload: C:\DATA\Sample.txt (PeterThoeny) Local file: Comment: Link: Create a link to the attached file at the end of the topic. Hide file: Hide attachment in normal topic view. Help text ... Topic FileAttachment . { | | Move attachment | Cancel }

• The first table is a list of all attachments, including their attributes. An h means the attachment is hidden, it isn't listed when viewing a topic.

• The second table is all the versions of the attachment. Click on View to see that version. If it's the most recent version, you'll be taken to an URL that always displays the latest version, which is usually what you want.
  • To change the comment on an attachment, enter a new comment and then click Change properties. Note that the comment listed against the specific version will not change, however the comment displayed when viewing the topic does change.
  • To hide/unhide an attachment, enable the Hide file checkbox, then click Change properties.

Known Issues

• Unlike topics, attachments are not locked during editing. As a workaround, you can change the comment to indicate an attachment file is being worked on - the comment on the specific version isn't lost, it's there when you list all versions of the attachment.

TWiki Forms

Form-based input in topics, with name/value pairs stored as Meta Data variables; choose one of multiple forms per web & topic

Overview

By adding form-based input to freeform content, you can structure topics with unlimited, easily searchable categories. When forms are enabled for a web and selected in a topic, a single form appears in edit mode, and the contents are rendered as a table when viewed on the display page. You can define unlimited forms per web. For each topic, you can select a template if more than one is defined, or remove forms entirely. Form input values are stored as TWikiMetaData; all data is saved.

Form Templates replace TWikiCategoryTables from the 01-Dec-2000 version of TWiki.

Main Changes from Category Tables

The Form Template system is a more powerful, flexible replacement for the original TWikiCategoryTable. Data from existing category tables can be imported directly.

Importing Category Table Data

On upgrading from the previous TWiki, a Form Template topic has to be built for each web that used a Category Table, recreating the fields and values from the old twikicatitems.tmpl. The replacement Form Template must be set as the first item in the WebPreferences variable WEBFORMS. If missing, pages will display, but attempting to edit results in an error message.

The new Form Template system should work with old Category Table data with no special conversion. Data is assigned to Meta variables the first time an imported topic is edited and saved in the new system.

NOTE: If things aren't working correctly, there may be useful entries in data/warning.txt.

Defining a Form Template

A Form Template is simply a page containing your form, defined as a table where each row is one form field.

Form Template Elements

• form template - a set of fields defining a form (replaces category table definition)
  • A web can use one or more form templates
• form - a topic containing additional meta data (besides the freeform TEXTAREA) that categorizes the content (replaces category table)
  • Within a form-enabled web, individual topics can have a form or no form
• form field - a named item in a form (replaces category item name)
• field type - selects the INPUT type:
  • select - drop-down menu or scrollable box
  • checkbox - one or more checkboxes
  • checkbox+buttons - one or more checkboxes, plus Set and Clear buttons
  • radio - one or more radio buttons
  • text - a one-line text field
  • textarea - a text box; size is 40x10 (columns x rows)
• field value - one or more values from a fixed set (select, checkbox, radio type) or free-form (text). (replaces category item value)

Defining a Form in One Topic

1. Create a new topic with your form name: YourForm, ExpenseReport, InfoCategory, RecordReview, whatever you need.
2. Create a TWiki table, with each column head representing one element of an entry field: Name, Type, Size, Values, and Tooltip message (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 (you can later choose to enable/disable individual forms).

Example: WebForm

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

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

Defining a Form with Multiple Topics

Forms can also be defined by using form templates that retrieve field values from one or more separate topics:

• A FormTemplate topic defines the Form, ex: YourFormTemplate.
• For each field that has a value list - select, radio, checkbox - can use separate topic to define the available values.

Example: WebFormTemplate

• Know.WebFormTemplate main definition:
   

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

  
  Leave the Values field blank.

• Know.TopicClassification field value definition:
   

  Name	Type	Tooltip message
  NoDisclosure	option	blah blah...
  PublicSupported	option	blah blah...
  PublicFAQ	option	blah blah...

• Implementation Notes: This format allows you to define field items with or without WikiNames, depending on your needs.
  • Topics can be protected in the usual manner, using TWikiAccessControl, to limit who can change the form template and/or individual value lists.
  • [[...]] links can be used to force a link (at present, the [[...][...]] format is not supported).
  • The Tooltip message column is used as a tooltip for the field name (only if field name is a WikiName) - you only see the tooltip In edit.
  • The first item in the list is the default item. Alternative initial values can be set in a topic template, like WebTopicEditTemplate, with field=value, or, for checkboxes, field=1.
  • The topic definition is not read when a topic is viewed.

Enabling Forms by Web

Forms are enabled on a per web basis. The WEBFORMS variable in WebPreferences is optional and defines a list of possible form templates. Example:

• Set WEBFORMS = BugForm, FeatureForm, BookLoanForm

• With WEBFORMS enabled, an extra button is added to the edit view. If the topic doesn't have a Form, an Add Form button appears at the end of the topic. If a Form is present, a Change button appears in the top row of the Form. The buttons open a screen that enables selection of a form specified in WEBFORMS, or the No form option.

Including Forms in New Topics

• A default Form Template (new topics get this default form) can be provided by creating the WebTopicEditTemplate topic in a web and adding a form to it. Initial Form values can be set there.

• Additionally a new topic can be given a Form using the formtemplate parameter in the 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: ?ColourRed=1.
    Boxes with a tick must be specified.

Setting Up Multiple Form Options

• The optional WEBFORMS variable defines alternative forms that can be selected by pressing Change in edit mode.

• A topic template can use any form.

• 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.

Form Data Storage

The form topic name, fields and values are stored as TWikiMetaData - the order of the field/value pairs is the same as in the template.

Using Form Data

-- JohnTalintyre - 16 Aug 2001
-- MikeMannix - 05 Jan 2002

TWiki Templates

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

Overview

The new modular template system offers flexible, easy control over the layout of all TWiki pages. The master template approach groups parts that are shared by several templates - like headers and footers - in a common file. Special variables allow individual layouts to include parts from a master template - variables are mixed with regular HTML markup for template-specific content. Templates are used to define page layout, and also to supply default content for new pages.

Major changes from the previous template system

Where the old templates were each complete HTML documents, the new templates are defined using variables to include template parts from a master file. You can now change one instance of a common element to update all occurrences; previously, every affected template had to be updated. This simplifies the conversion of templates into XHTML format, and provides a more versatile solution for templates and for TWikiSkins. The new system:

• separates a set of common template parts into a base template that is included by all of the related templates;
• defines common variables, like a standard separator (ex: "|"), in the base template;
• defines variable text in the individual templates and passes it back to the base template.

How Template Variables Work

• Special template directives (or preprocessor commands) are embedded in normal templates.
• All template preprocessing is done in &TWiki::Store::readTemplate() so that the caller simply gets an expanded template file (the same as before).
• Directives are of the form %TMPL:<key>% and %TMPL:<key>{"attr"}%.
• Directives:
  • %TMPL:INCLUDE{"file"}%: Includes a template file. The template directory of the current web is searched first, then the templates root (twiki/templates).
  • %TMPL:DEF{"var"}%: Define a variable. Text between this and the END directive is not returned, but put into a hash for later use.
  • %TMPL:END%: Ends variable definition.
  • %TMPL:P{"var"}%: Prints a previously defined variable.
• Variables live in a global name space: there is no parameter passing.
• 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 topic text.

Types of Template

There are three types of template:

• Master Template: Stores common parts; included by other templates
• HTML Page Templates: Defines the layout of TWiki pages
• Template Topics: Defines default text when you create a new topic

Master Templates

Common parts, appearing in two or more templates, can be defined in a master template and then shared by others: twiki.tmpl is the default master template.

Template variable:	Defines:
%TMPL:DEF{"sep"}%	"|" separator
%TMPL:DEF{"htmldoctype"}%	Start of all HTML pages
%TMPL:DEF{"standardheader"}%	Standard header (ex: view, index, search)
%TMPL:DEF{"simpleheader"}%	Simple header with reduced links (ex: edit, attach, oops)
%TMPL:DEF{"standardfooter"}%	Footer, excluding revision and copyright parts
%TMPL:DEF{"oops"}%	Skeleton of oops dialog

HTML Page Templates

TWiki uses HTML template files for all actions, like topic view, edit, and preview. This allows you to change the look and feel of all pages by editing just a few template files.

Templates are in the twiki/templates directory. As an example, twiki/templates/view.tmpl is the template file for the twiki/bin/view script. Templates can be overloaded by individual webs. The following search order applies:

1. twiki/templates/$webName/$scriptName.tmpl
2. twiki/templates/$scriptName.tmpl
   • $webName is the name of the web (ex: Main)
   • $scriptName is the script (ex: view).

NOTE: TWikiSkins can be defined to overload the standard templates.

Special variables are used in templates, especially in view, to display meta data.

Template Topics

Template topics define the default text for new topics. There are three types of template topic:

Topic Name:	What it is:
WebTopicViewTemplate	Error page shown when you try to view a nonexistent topic
WebTopicNonWikiTemplate	Alert page shown when you try to view a nonexistent topic with a non-WikiName
WebTopicEditTemplate	Default text shown when you create a new topic.

1. A topic name specified by the templatetopic CGI parameter.
2. WebTopicEditTemplate in the current web
3. WebTopicEditTemplate in the TWiki web

Edit Template Topics and Variable Expansion

The following variables get expanded when a user creates a new topic based on a template topic:

Variable:	Description:
%DATE%	Current date, e.g. 06 May 2009
%WIKIUSERNAME%	User name, e.g. Main.guest
%URLPARAM{"name"}%	Value of a named URL parameter
%NOP%	A no-operation variable that gets removed. Useful to prevent a SEARCH from hitting an edit template topic; also useful to escape a variable like %URLPARAM%NOP%{...}%
%NOP{ ... }%	A no-operation text that gets removed. Useful to write-protect an edit template topic, but not the topics based this template topic. See notes below. Example: %NOP{    * Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup }%

Notes:

• Unlike other variables, %NOP{ ... }% can span multiple lines.
• The scan for the closing }% pattern is "non-greedy", that is, it stops at the first occurance. That means, you need to escape variables with parameters located inside %NOP{ ... }%: Insert a %NOP% between } and %. Silly example: %NOP{ %GMTIME{"$year"}%NOP%% }%.

All other variables are unchanged, e.g. are carried over "as is" into the new topic.

Template Topics in Action

Here is an example for creating new topics based on a specific template topic:

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 HTML source of the form:

<form name="new" action="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%INTURLENCODE{"%WEB%"}%/">
   * New example topic: 
     <input type="text" name="topic" value="ExampleTopic%SERVERTIME{$yearx$mox$day}%" size="23" />
     <input type="hidden" name="templatetopic" value="ExampleTopicTemplate" />
     <input type="hidden" name="onlywikiname" value="on" />
     <input type="submit" value="Create" />
     (date format is <nop>YYYYxMMxDD)
</form>

The onlywikiname parameter enforces WikiWords for topic names.

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%

Templates by Example

Attached is an example of an oops based template oopsbase.tmpl and an example oops dialog oopstest.tmpl based on the base template. %A% NOTE: This isn't the release version, just a quick, simple demo.

Base template oopsbase.tmpl

The first line declares a delimiter variable called "sep", used to separate multiple link items. The variable can be called anywhere by writing %TMPL:P{"sep"}%

%TMPL:DEF{"sep"}% | %TMPL:END% <html> <head> <title> %WIKITOOLNAME% . %WEB% . %TOPIC% %.TMPL:P{"titleaction"}%</title> <base href="%SCRIPTURL%/view%SCRIPTSUFFIX%/%WEB%/%TOPIC%"> <meta name="robots" content="noindex"> </head> <body bgcolor="#FFFFFF"> <table width="100%" border="0" cellpadding="3" cellspacing="0"> <tr> <td bgcolor="%WEBBGCOLOR%" rowspan="2" valign="top" width="1%"> <a href="%WIKIHOMEURL%"> <img src="%PUBURLPATH%/wikiHome.gif" border="0"></a> </td> <td> <b>%WIKITOOLNAME% . %WEB% . </b><font size="+2"> <B>%TOPIC%</b> %TMPL:P{"titleaction"}%</font> </td> </tr> <tr bgcolor="%WEBBGCOLOR%"> <td colspan="2"> %TMPL:P{"webaction"}% </td> </tr> </table> --- ++ %TMPL:P{"heading"}% %TMPL:P{"message"}% <table width="100%" border="0" cellpadding="3" cellspacing="0"> <tr bgcolor="%WEBBGCOLOR%"> <td valign="top"> Topic <b>%TOPIC%</b> . { %TMPL:P{"topicaction"}% } </td> </tr> </table> </body>

Test template oopstest.tmpl

Each oops template basically just defines some variables and includes the base template that does the layout work.

%TMPL:DEF{"titleaction"}% (test =titleaction=) %TMPL:END% %TMPL:DEF{"webaction"}% test =webaction= %TMPL:END% %TMPL:DEF{"heading"}% Test heading %TMPL:END% %TMPL:DEF{"message"}% Test =message=. Blah blah blah blah blah blah blah blah blah blah blah... * Some more blah blah blah blah blah blah blah blah blah blah... * Param1: %PARAM1% * Param2: %PARAM2% * Param3: %PARAM3% * Param4: %PARAM4% %TMPL:END% %TMPL:DEF{"topicaction"}% Test =topicaction=: [[%WEB%.%TOPIC%][OK]] %TMPL:P{"sep"}% [[%TWIKIWEB%.TWikiRegistration][Register]] %TMPL:END% %TMPL:INCLUDE{"oopsbase"}%

Sample screen shot of oopstest.tmpl

With URL: .../bin/oops/Sandbox/TestTopic2?template=oopstest&param1=WebHome&param2=WebNotify

Known Issues

• A drawback of referring to a master template is that you can only test a template from within TWiki, where the include variables are resolved. In the previous system, each template was a structurally complete HTML document with a .tmpl filename extension - it contained unresolved %VARIABLES%, but could still be previewed directly in a browser.

-- PeterThoeny - 01 Feb 2003
-- MikeMannix - 14 Sep 2001
-- TWiki:Main/DavidLeBlanc - 11 Mar 2002

TWiki Skins

Skins overlay regular templates with alternate header/footer layouts; topic text is not affected

Overview

Skins are customized TWikiTemplates files. You can use skins to change the look of a TWiki topic, for example, the layout of the header and footer. Rendered text between header and footer does not change. You can also use skins to define an alternate view, like a view optimized for printing.

Defining Skins

Skin files are located in the twiki/templates directory and are named with the syntax: <scriptname>.<skin>.tmpl. For example, the Printable skin for the view template is view.print.tmpl.

Use the existing TWikiTemplates (like view.tmpl) or skin files as a base for your own skin, name it for example view.myskin.tmpl.

Variables in Skins

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

The "Go" Box and Navigation Box

The %WEBTOPICLIST% includes a "Go" box to jump to a topic. The box also understand 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 onSelect method of the select tag to fill the selected URL into the "Go" box field, then submits the form.

Here is an example form that has a select box and the "Go" box for illustration purposes. You need to have JavaScript enabled for this to work:

Packaging and Publishing Skins

See TWiki:Plugins/SkinPackagingHowTo

Activating Skins

A skin can be activated in two ways:

• Define the SKIN Preference variable in TWikiPreferences, one of the WebPreferences, or in a user - Main.guest - topic.
  • Set SKIN = print

• Add ?skin=name to the URL, for this example:
  • http://wiki.arch.ethz.ch/twiki/bin/view/TWiki/TWikiSkins?skin=print (for the print view skin)
  • http://wiki.arch.ethz.ch/twiki/bin/view/TWiki/TWikiSkins?skin=plain (for the plain view skin that has no header and footer)

The ?skin=name URL parameter overrides the SKIN Preference value.

-- PeterThoeny - 05 Jan 2003

TWiki Formatted Search Results

Inline search feature allows flexible formatting of search result

The %SEARCH{...}% variable documented in TWikiVariables has a fixed format for the search result, that is, a table consisting of topic names and topic summaries. Use the format="..." parameter to specify a customized format of the search result. The string of the format parameter is typically a bullet list or table row containing variables (such as %SEARCH{ "food" format="| $topic | $summary |" }%).

Syntax

Two parameters can be used to specify a customized search result:

1. header="..." parameter

Use the header parameter to specify the header of a search result. It should correspond to the format of the format parameter. This parameter is optional.
Example: header="| *Topic:* | *Summary:* |"

2. format="..." parameter

Use the format parameter to specify the format of one search hit.
Example: format="| $topic | $summary |"

Variables that can be used in the format string:

Note: For $pattern(reg-exp), specify a RegularExpression that scans from start to end and contains the text you want to keep in parenthesis, like $pattern(.*?(from here.*?to here).*). You need to make sure that the integrity of a web page is not compromised; for example, if you include a table make sure to include everything including the table end tag.

Examples

Bullet list showing topic name and summary

Write this:

%SEARCH{ "FAQ" scope="topic" nosearch="on" nototal="on" header="   * *Topic: Summary:*" format="   * [[$topic]]: $summary" }%

To get this:

• Topic: Summary:
• TWikiFAQ: Frequently Asked Questions About TWiki This is a real FAQ, and also a demo of one easily implemented knowledge base solution. See how it's done, click Edit . SEARCH ...
• TWikiFaqTemplate: FAQ: Answer: Back to: NOP TWikiFAQ WIKIUSERNAME DATE
• TextFormattingFAQ: Text Formatting FAQ The most frequently asked questions about text formatting are answered. Also, TextFormattingRules contains the complete TWiki shorthand system ...

Table showing form field values of topics with a form

Write this in the Know web:

| *Topic:* | *OperatingSystem:* | *OsVersion:* |
%SEARCH{ "[T]opicClassification.*?value=\"[P]ublicFAQ\"" scope="text" regex="on" nosearch="on" nototal="on" format="| [[$topic]] | $formfield(OperatingSystem) | $formfield(OsVersion) |" }%

To get this:

Extract some text from a topic using regular expression

Write this:

%SEARCH{ "__Back to\:__ TWikiFAQ" scope="text" regex="on" nosearch="on" nototal="on" header="TWiki FAQs:" format="   * $pattern(.*?FAQ\:[\n\r]*([^\n\r]+).*) [[$topic][Answer...]]" }%

To get this:

TWiki FAQs:

• How do I delete or rename a topic? Answer...
• Why does the topic revision not increase when I edit a topic? Answer...
• TWiki has a GPL (GNU General Public License). What is GPL? Answer...
• I've problems with the WebSearch. There is no Search Result on any inquiry. By clicking the Index topic it's the same problem. Answer...
• What happens if two of us try to edit the same topic simultaneously? Answer...
• I would like to install TWiki on my server. Can I get the source? Answer...
• So what is this WikiWiki thing exactly? Answer...
• Everybody can edit any page, this is scary. Doesn't that lead to chaos? Answer...

Nested Search

Search can be nested. For example, search for some topics, then form a new search for each topic found in the first search. The idea is to build the nested search string using a formatted search in the first search.

Here is an example. Let's search for all topics that contain the word "culture" (first search), and let's find out where each topic found is linked from (second search).

• First search:
  • %SEARCH{ "culture" format="   * $topic is referenced by: (list all references)" nosearch="on" nototal="on" }%
• Second search. For each hit we want this search:
  • %SEARCH{ "(topic found in first search)" format="   $topic" nosearch="on" nototal="on" }%
• Now let's nest the two. We need to escape the second search, e.g. the first search will build a valid second search string. Note that we escape the second search so that it does not get evaluated prematurely by the first search:
  • Use $percnt to escape the leading percent of the second search
  • Use \" to escape the double quotes
  • Use $dollar to escape the $ of $topic
  • Use $nop to escape the }% sequence

Write this:

%SEARCH{ "culture" format="   * $topic is referenced by:$n      * $percntSEARCH{ \"$topic\" format=\"   $dollartopic\" nosearch=\"on\" nototal=\"on\" }$nop%" nosearch="on" nototal="on" }%

To get this:

• FormattedSearch is referenced by:
  • BatchUploadPlugin EditTablePlugin ManagingWebs RenderListPlugin TWikiDocumentation TWikiForms TWikiFuncModule TWikiHistory TWikiUpgradeGuide TWikiUpgradeTo01Dec2001 TWikiVariables TextFormattingRules WelcomeGuest
• TWikiAccessControl is referenced by:
  • CommentPlugin EditTablePlugin FileAttachment MainFeatures ManagingTopics TWikiAccessControl TWikiDocumentation TWikiForms TWikiFuncModule TWikiHistory TWikiPreferences TWikiTopics TWikiTutorial TWikiUpgradeTo01Dec2000 TWikiUpgradeTo01Dec2001 TWikiUserAuthentication TWikiVariables WebPreferences WebStatistics WelcomeGuest WikiCulture WikiWord
• TWikiSite is referenced by:
  • InstantEnhancements InterwikiPlugin ManagingWebs StartingPoints TWikiDocumentation TWikiGlossary TWikiInstallationGuide TWikiPreferences TWikiSite TWikiSiteTools TWikiTopics TWikiTutorial TWikiUpgradeTo01Dec2000 WabiSabi WebHome WebSiteTools WebStatistics WelcomeGuest WhatIsWikiWiki WikiCulture WikiReferences
• WabiSabi is referenced by:
  • AppendixFileSystem TWikiSite WabiSabi WikiCulture
• WelcomeGuest is referenced by:
  • StartingPoints TWikiSite TWikiUpgradeTo01Dec2000 WebHome WebPreferences WebStatistics WhatIsWikiWiki WikiCulture YouAreHere
• WikiCulture is referenced by:
  • TWikiAccessControl TWikiSite WabiSabi WelcomeGuest

-- PeterThoeny - 16 May 2002

TWiki Meta Data

Additional topic data, program-generated or from TWikiForms, is stored in META variable name/value pairs

Overview

TWikiMetaData uses META variables to store topic data that's separate from the main free-form content. This includes program-generated info like FileAttachment and topic movement data, and user-defined TWikiForms info. Use META variables to format and display Meta Data.

Meta Data Syntax

• Format is the same as in TWikiVariables, except all fields have a key.
  • %META:<type>{key1="value1" key2="value2" ...}%

• Order of fields within the meta variables is not defined, except that if there is a field with key name, this appears first for easier searching (note the order of the variables themselves is defined).

• Each meta variable is on one line.

• \n (new line) is represented in values by %_N_ and " (double-quotes) by %_Q_%.

Example of Format

%META:TOPICINFO{version="1.6" date="976762663" author="PeterThoeny" format="1.0"}%
   text of the topic
%META:TOPICMOVED{from="Codev.OldName" to="Codev.NewName"
   by="JohnTalintyre" date="976762680"}%
%META:TOPICPARENT{name="NavigationByTopicContext"}%
%META:FILEATTACHMENT{name="Sample.txt" version="1.3" ... }%
%META:FILEATTACHMENT{name="Smile.gif" version="1.1" ... }%
%META:FORM{name="WebFormTemplate"}%
%META:FIELD{name="OperatingSystem" value="OsWin"}%
%META:FIELD{name="TopicClassification" value="PublicFAQ"}%

Meta Data Specifications

The current version of Meta Data is 1.0, with support for the following variables.

META:TOPICINFO

META:TOPICMOVED

This is optional, exists if topic has ever been moved. If a topic is moved more than once, only the most recent META:TOPICMOVED meta variable exists in the topic, older ones are to be found in the rcs history.

%META:TOPICMOVED{from="Codev.OldName" to="Codev.NewName" by="talintj" date="976762680"}%

Notes:

• at present version number is not supported directly, it can be inferred from the RCS history.
• there is only one META:TOPICMOVED in a topic, older move information can be found in the RCS history.

META:TOPICPARENT

META:FILEATTACHMENT

Extra fields that are added if an attachment is moved:

META:FORM

META:FIELD

Should only be present if there is a META:FORM entry. Note that this data is used when viewing a topic, the form template definition is not read.

Recommended Sequence

There is no absolute need for Meta Data variables to be listed in a specific order within a topic, but it makes sense to do so a couple of good reasons:

• form fields remain in the order they are defined
• the diff function output appears in a logical order

The recommended sequence is:

• META:TOPICINFO
• text of topic
• META:TOPICMOVED (optional)
• META:TOPICPARENT (optional)
• META:FILEATTACHMENT (0 or more entries)
• META:FORM (optional)
• META:FIELD (0 or more entries; FORM required)

Viewing Meta Data in Page Source

When viewing a topic the Raw Text link can be clicked to show the text of a topic (i.e., as seen when editing). This is done by adding raw=on to URL. raw=debug shows the meta data as well as the topic data, ex: debug view for this topic

Rendering Meta Data

Meta Data is rendered with the %META% variable. This is mostly used in the view, preview and edit scripts.

Current support covers:

Known Issues

At present, there is no Meta Data support for Plugins. However, the format is readily extendable and the Meta.pm code that supports the format needs only minor alteration.

-- JohnTalintyre - 29 Aug 2001
-- MikeMannix - 03 Dec 2001
-- PeterThoeny - 10 Jan 2002

TWiki Plugins

Plug-in enhanced feature add-ons, with a Plugin API for developers

Overview

You can add Plugins to extend TWiki's functionality, without altering the core program 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.

Preinstalled Plugins

TWiki comes with three Plugins as part of the standard installation.

• DefaultPlugin optionally handles some legacy variables from older versions of TWiki. You can control this option from TWikiPreferences. (Perl programmers can also add rules for simple custom processing.)

• EmptyPlugin is a fully functional module, minus active code; it does nothing and serves as a template for new Plugin development.

• InterwikiPlugin is preinstalled but can be disabled or removed. Use it for shorthand linking to remote sites, ex: TWiki:Plugins expands to TWiki:Plugins on TWiki.org. You can edit the predefined set of of Wiki-related sites, and add your own.

Installing Plugins

Each TWikiPlugin comes with full documentation: step-by-step installation instructions, a detailed description of any special requirements, version details, and a working example for testing.

Most Plugins can be installed in three easy steps, with no programming skills required:

1. Download the zip file containing the Plugin, documentation, and any other required files, from TWiki:Plugins.
2. Distribute the files to their proper locations - unzip the zip archive in your TWiki installation directory - if have a standard TWiki installation, this will distribute automatically. Otherwise, place the files according to the directory paths listed on the Plugin top in TWiki:Plugins.
3. Check the demo example on the Plugin topic: if it's working, the installation was fine!

Special Requests: Some Plugins need certain Perl modules to be preinstalled on the host system. Plugins may also use other resources, like graphics, other modules, applications, templates. In these cases, detailed instructions are in the Plugin documentation.

Each Plugin has a standard release page, located in the TWiki:Plugins web at TWiki.org. In addition to the documentation topic (SomePlugin), there's a separate development page.

• Doc page: Read all available info about the Plugin; download the attached distribution files.
• Dev page: Post feature requests, bug reports and general dev comments; topic title ends in Dev (SomePluginDev).
• User support: Post installation, how to use type questions (and answers, if you have them) in the TWiki:Support web.

On-Site Pretesting

To test new Plugins on your installation before making them public, you may want to use one of these two approaches:

• Method 1: Safely test on-the-fly by creating separate Production and Test branches in your live TWiki installation.
  • Duplicate the twiki/bin and twiki/lib directories for the Test version, adjusting the paths in the new lib/TWiki.cfg, the twiki/data; the twiki/templates and twiki/pub directories are shared.
  • Test Plugins and other new features in the Test installation until you're satisfied.
    • If you modify topics using the new features, live users will likely see unfamiliar new META tags showing up on their pages - to avoid this, create and edit test-only topics to try out new features.
  • Copy the modified files to the Production installation. You can update a TWiki installation live and users won't even notice.

• Method 2: List the Plugin being tested in the DISABLEDPLUGINS variable in TWikiPreferences. Redefine the DISABLEDPLUGINS variable in the Sandbox web and do the testing there.

Managing Plugins

When you finish installing a Plugin, you should be able to read the user instructions and go. In fact, 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.

Setting Preferences

Installed Plugins can be toggled on or off, site-wide or by web, through TWikiPreferences and individual WebPreferences:

• All Plugin modules present in the lib/TWiki/Plugins directory are activated automatically unless disabled by the DISABLEDPLUGINS Preferences variable in TWikiPreferences. You can optionally list the installed Plugins in the INSTALLEDPLUGINS Preferences variable. This is useful to define the sequence of Plugin execution, or to specify other webs than the TWiki web for the Plugin topics. Settings in TWikiPreferences are:
  • Set INSTALLEDPLUGINS = DefaultPlugin, ...
  • Set DISABLEDPLUGINS = EmptyPlugin, ...

Plugin execution order in TWiki is determined by searching Plugin topics in a specific sequence: First, full web.topicname name, if specified in INSTALLEDPLUGINS; next, the TWiki web is searched; and finally, the current web.

Plugin-specific settings are done in individual Plugin topics. Two settings are standard for each Plugin:

1. One line description, used to form the bullets describing the Plugins in the TextFormattingRules topic:
   • Set SHORTDESCRIPTION = Blah blah woof woof.
2. Debug Plugin, output can be seen in data/debug.txt. Set to 0=off or 1=on:
   • Set DEBUG = 0

• The settings can be retrieved as Preferences variables like %<pluginname>_<var>%, ex: %DEFAULTPLUGIN_SHORTDESCRIPTION% shows the description of the DefaultPlugin.

Listing Active Plugins

Plugin status variables let you list all active Plugins wherever needed. There are two list formats:

• The %ACTIVATEDPLUGINS% variable lists activated Plugins by name. (This variable is displayed in TWikiPreferences for debugging use.)
• The %PLUGINDESCRIPTIONS% variable displays a bullet list with a one-line description of each active Plugins. This variable is based on the %<plugin>_SHORTDESCRIPTION% Preferences variables of individual topics and is shown in TextFormattingRules.

DEMO: Automatically List Active Plugins Using Variables

Using %ACTIVATEDPLUGINS%:
On this TWiki site, the active Plugins are: DefaultPlugin, CommentPlugin, BatchUploadPlugin, EditTablePlugin, InterwikiPlugin, RenderListPlugin, TablePlugin.

Using %PLUGINDESCRIPTIONS%:
You can use any of these active TWiki Plugins:

• DefaultPlugin: This plugin can be used to specify some simple custom rendering rules. It also renders deprecated *_text_* as bold italic text.
• CommentPlugin: Allows users to quickly post comments to a page without an edit/preview/save cycle.
• BatchUploadPlugin: Plugin implementing TWiki:Codev.MultipleAttachmentsAtOnce
• EditTablePlugin: Edit TWiki tables using edit fields, date pickers and drop down boxes
• InterwikiPlugin: Link ExternalSite:Page text to external sites based on aliases defined in the InterWikis topic.
• RenderListPlugin: Render bullet lists in a variety of formats

The TWiki Plugin API

The Application Programming Interface (API) for TWikiPlugins provides the specifications for hooking into the core TWiki code from your external Perl Plugin module. The Plugin API is new to the Production version of TWiki with the 01-Sep-2001 release.

Available Core Functions

The TWikiFuncModule (lib/TWiki/Func.pm) implements ALL official Plugin functions. Plugins should ONLY use functions published in this module.

If you use functions not 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 call backs, listed in the lib/TWiki/Plugins/EmptyPlugin.pm module.

• All but the initPlugin are disabled. To enable a call back, remove DISABLE_ from the function name.
• For best performance, enable only the functions you really need. NOTE: outsidePREHandler and insidePREHandler are particularly expensive.

Plugin Version Detection

To eliminate the incompatibility problems bound to arise from active open Plugin development, a Plugin versioning system and an API GetVersion detection routine are provided for automatic compatibility checking.

• All modules require a $VERSION='0.000' variable, beginning at 1.000.

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

• $VERSION='1.000' is the current setting in TWiki::Plugins.pm and in the preinstalled system Plugins (DefaultPlugin, EmptyPlugin, InterwikiPlugin).

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 Plugins by providing a programming interface for TWiki.

The DefaultPlugin Alternative

• DefaultPlugin can handle some outdated TWiki variables, found, for example, in sites recently updated from an old version. Settings are in DefaultPlugin topic. You can also add your own simple custom processing rules here, though in all but very simple cases, writing a new Plugin is preferable.

Anatomy of a Plugin

A basic TWiki Plugin consists of two elements:

• a Perl module, ex: MyFirstPlugin.pm
• a documentation topic, ex: MyFirstPlugin.txt

The Perl module can be a block of code that connects 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.

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 GoBox 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.
   • In case you plan to publish your Plugin at TWiki.org, use Interwiki names for author names, like TWiki:Main/guest.
3. 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 Global Settings: <Description and settings for custom Plugin %VARIABLES%, and those required by TWiki.>"

• Plugins Preferences <If user settings are needed, explain... Entering values works exactly like TWikiPreferences and WebPreferences: six (6) spaces and then:>"
  • Set <EXAMPLE = value added>

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

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

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. Publish your Plugin in three steps:

1. Post the Plugin documentation topic in the TWiki:Plugins web:
   • create a new topic using the Plugin name, ex: MyFirstPlugin.txt
   • paste in the topic text from Creating Plugin Documentation 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.)

-- AndreaSterbini - 29 May 2001
-- PeterThoeny - 29 Jan 2003
-- MikeMannix - 03 Dec 2001

TWiki::Func Module Documentation

Official list of stable TWiki functions for Plugin developers

Description

This module defines official funtions that Plugins and add-on scripts can use to interact with the TWiki engine and content.

Plugins should only use functions published in this module. If you use functions in other TWiki libraries you might impose a security hole and you will likely need to change your Plugin when you upgrade TWiki.

Functions: CGI Environment

getSessionValue( $key ) ==> $value

setSessionValue( $key, $value ) ==> $result

getSkin( ) ==> $skin

getUrlHost( ) ==> $host

getScriptUrl( $web, $topic, $script ) ==> $url

getScriptUrlPath( ) ==> $path

getViewUrl( $web, $topic ) ==> $url

getOopsUrl( $web, $topic, $template, $param1, $param2, $param3, $param4 ) ==> $url

getPubUrlPath( ) ==> $path

getCgiQuery( ) ==> $query

writeHeader( $query )

redirectCgiQuery( $query, $url )

Functions: Preferences

extractNameValuePair( $attr, $name ) ==> $value

• Example:
  • Variable: %TEST{ "nameless" name1="val1" name2="val2" }%
  • First extract text between {...} to get: "nameless" name1="val1" name2="val2"
  • Then call this on the text:
    my $noname = TWiki::Func::extractNameValuePair( $text );
my $name1  = TWiki::Func::extractNameValuePair( $text, "name1" );
my $name2  = TWiki::Func::extractNameValuePair( $text, "name2" );

getPreferencesValue( $key, $web ) ==> $value

• Example for Plugin setting:
  • MyPlugin topic has: * Set COLOR = red
  • Use "MYPLUGIN_COLOR" for $key
  • my $color = TWiki::Func::getPreferencesValue( "MYPLUGIN_COLOR" );

• Example for preferences setting:
  • WebPreferences topic has: * Set WEBBGCOLOR = #FFFFC0
  • my $webColor = TWiki::Func::getPreferencesValue( "WEBBGCOLOR", "Sandbox" );

getPreferencesFlag( $key, $web ) ==> $value

• Example for Plugin setting:
  • MyPlugin topic has: * Set SHOWHELP = off
  • Use "MYPLUGIN_SHOWHELP" for $key
  • my $showHelp = TWiki::Func::getPreferencesFlag( "MYPLUGIN_SHOWHELP" );

getWikiToolName( ) ==> $name

getMainWebname( ) ==> $name

getTwikiWebname( ) ==> $name

Functions: User Handling and Access Control

getDefaultUserName( ) ==> $loginName

getWikiName( ) ==> $wikiName

getWikiUserName( $text ) ==> $wikiName

wikiToUserName( $wikiName ) ==> $loginName

userToWikiName( $loginName, $dontAddWeb ) ==> $wikiName

isGuest( ) ==> $flag

permissionsSet( $web ) ==> $flag

checkAccessPermission( $type, $wikiName, $text, $topic, $web ) ==> $flag

Functions: Content Handling

webExists( $web ) ==> $flag

topicExists( $web, $topic ) ==> $flag

getRevisionInfo( $web, $topic ) ==> ( $date, $loginName, $rev )

checkTopicEditLock( $web, $topic ) ==> ( $oopsUrl, $loginName, $unlockTime )

setTopicEditLock( $web, $topic, $lock ) ==> $oopsUrl

readTopicText( $web, $topic, $rev, $ignorePermissions ) ==> $text

saveTopicText( $web, $topic, $text, $ignorePermissions, $dontNotify ) ==> $oopsUrl

• Example:
  my $oopsUrl = TWiki::Func::setTopicEditLock( $web, $topic, 1 );
if( $oopsUrl ) {
    TWiki::Func::redirectCgiQuery( $query, $oopsUrl );   # assuming valid query
    return;
}
my $text = TWiki::Func::readTopicText( $web, $topic );        # read topic text
# check for oops URL in case of error:
if( $text =~ /^http.*?\/oops/ ) {
    TWiki::Func::redirectCgiQuery( $query, $text );
    return;
}
# do topic text manipulation like:
$text =~ s/old/new/g;
# do meta data manipulation like:
$text =~ s/(META\:FIELD.*?name\=\"TopicClassification\".*?value\=\")[^\"]*/$1BugResolved/;
$oopsUrl = TWiki::Func::saveTopicText( $web, $topic, $text ); # save topic text
TWiki::Func::setTopicEditLock( $web, $topic, 0 );             # unlock topic
if( $oopsUrl ) {
    TWiki::Func::redirectCgiQuery( $query, $oopsUrl );
    return;
}

getPublicWebList( ) ==> @webs

getTopicList( $web ) ==> @topics

Functions: Rendering

expandCommonVariables( $text, $topic, $web ) ==> $text

renderText( $text, $web ) ==> $text

internalLink( $pre, $web, $topic, $label, $anchor, $createLink ) ==> $text

search text( $text ) ==> $text

formatGmTime( $time, $format ) ==> $text

Functions: File I/O

getDataDir( ) ==> $dir

getPubDir( ) ==> $dir

readTemplate( $name, $skin ) ==> $text

readFile( $filename ) ==> $text

saveFile( $filename, $text )

writeWarning( $text )

writeDebug( $text )

Copyright and License

Copyright (C) 2000-2003 Peter Thoeny, Peter@Thoeny.com

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details, published at http://www.gnu.org/copyleft/gpl.html

NOTE: Above text is copied from the TWiki::Plugins/PerlDocPlugin output of TWiki::Func in twiki format. In case you want to get dynamically updated documentation based on the actual Perl module, install the PerlDocPlugin and replace above text with %PERLDOC{"TWiki::Func"}%.

-- PeterThoeny - 31 Dec 2002

TWiki Site Tools

Utilities for searching, navigation, and monitoring site activity

TWikiSiteTools include utilities for navigating, searching and keeping up with site activity. Preferences can be configured by web or site-wide. You are currently in the TWiki web. In particular, TWiki provides two highly configurable, automated site monitoring tools, WebNotify, to email alerts when topics are edited, and WebStats, to generate detailed activity reports.

WebNotify Recent Changes Alert

Each TWiki web has an automatic email alert service that sends a list of recent changes on a preset schedule, like once a day. Users can subscribe and unsubscribe using WebNotify in each web. The Perl script mailnotify is called by a background process at regular intervals. The script sends an automated email to subscribed users if topics were changed in a web since the script was last run.

• You can create a WebNotify link using TWikiVariables with %NOTIFYTOPIC%

TWiki handles WebNotify entries that include the WikiName of a user or a TWikiGroup and an optional e-mail address. Example entries in WebNotify:

    * Main.FredBloggs
    * Main.FredBloggs - secondary@home.com
    * Main.EngineeringGroup

The first entry is the default form, the notification gets sent to the e-mail address specified in the user's home page. The second entry lists an alternative e-mail address. The third entry specifies a group, the notification gets sent to each member of the group.

You can also use %MAINWEB% instead of Main, but this is not necessary even if you have renamed the main web by configuring $mainWebname in TWiki.cfg.

Configuring Outgoing Mail

TWiki will use the Net::SMTP module if it is installed on your system. Set this with the SMTPMAILHOST variable in TWikiPreferences.

The notify e-mail uses the default changes.tmpl template, or a skin if activated in the TWikiPreferences.

mailnotify also relies on two hidden files in each TWiki/data/[web] directory: .changes and .mailnotify. Make sure both are writable by your web server process. .changes contains a list of changes; go ahead and make this empty. .mailnotify contains a timestamp of the last time notification was done.

You can use an external mail program, like sendmail, if the Net::SMTP module is not installed. Set the program path in $mailProgram in TWiki.cfg.

• Net::SMTP can be easily disabled (ex: if there is an installation error) by setting SMTPMAILHOST in TWikiPreferences to an empty value.

• You can set a separate SMTPSENDERHOST variable to define the mail sender host (some SMTP installations require this).

Setting the Automatic Email Schedule

For Unix platforms: Edit the cron table so that mailnotify is called in an interval of your choice. Please consult man crontab of how to modify the table that schedules program execution at certain intervals. Example:

% crontab -e
15,45 * * * * (cd ~twiki/public_html/bin; ./mailnotify -q)

For ISP installations: Many ISPs don't allow hosted accounts direct cron access, as it's often used for things that can heavily load the server. Workaround scripts are available.

On Windows NT/2000: You can use a scheduled task if you have administrative privileges. Note: AT on an NT machine is pretty limited. Microsoft lists several third-party replacements (as of 2001-11-20, none of them free).

WebStatistics Site Usage Log

You can generate a listing manually, or on an automated schedule, of visits to individual pages, on a per web basis. Compiled as a running total on a monthly basis. Includes totals for Topic Views, Topic Saves, Attachment Uploads, Most Popular Topics with number of views, and Top Contributors showing total of saves and attachment uploads. Previous months are saved.

• You can create a WebStatistics link using TWikiVariables with %STATISTICSTOPIC%

Configuring for Automatic Operation

• You can automatically generate usage statistics for all webs. To enable this:
  • Make sure variable $doLogTopicView, $doLogTopicSave and $doLogTopicUpload in TWiki.cfg are set. This will generate log entries in file twiki/data/log<date>.txt .
  • The WebStatistics topic must be present in all webs where you want to have statistics. You can use the topic in the Main web as a template.
  • Call the twiki/bin/statistics script from a cron job, once a day is recommended. This will update the WebStatistics topics in all webs.
  • Attention: The script must run as the same user as the CGI scripts are running, which is user nobody on most systems. Example crontab entry:
    0 0 * * * (cd /path/to/TWiki/bin; ./statistics >/dev/null 2>&1)
  • There is a workaround in case you can't run the script as user nobody : Run the utility twiki/bin/geturl in your cron job and specify the URL of the twiki/bin/statistics script as a parameter. Example:
    0 0 * * * (cd /path/to/TWiki/bin; ./geturl mydomain.com /urlpath/to/TWiki/bin/statistics >/dev/null 2>&1)

Generating Statistics Manually by URL

• The twiki/bin/statistics script can also be executed as a CGI script, just enter the URL in your browser. Examples:
  • Update current month for all webs:
    http://mydomain.com/twiki/bin/statistics
  • Update current month for Main web only:
    http://mydomain.com/twiki/bin/statistics/Main
  • Update January 2000 for Main web:
    http://mydomain.com/twiki/bin/statistics/Main?logdate=200001

WebSearch

WebSearch is an extremely fast and flexible search facility, part of the core TWiki feature set. Options include:

• topic title or full-text search
• regular expressions
• search within web or site-wide
• index-style A-Z alphabetical listing sorted topic title
• many more

See also: TWikiVariables for including hard-coded searches in text.

WebChanges

To check for the most recently edited topics while on-site, use the WebChanges link, usually located on the upper toolbar. It lists the most recently modified topics, newest first, along with the first couple of lines of the page content.

This is simply a preset SEARCH. The number of topics listed by the limit parameter.:

%SEARCH{".*" web="TWiki" regex="on" nosearch="on" order="modified" 
reverse="on" limit="50"}%

WebIndex

WebIndex lists all web topics in alphabetical order, with the first couple of lines of text. This is simply a preset SEARCH:

%SEARCH{"\.*" scope="topic" regex="on" nosearch="on"}%

-- MikeMannix - 01 Dec 2001
-- PeterThoeny - 30 Jan 2003

Managing Topics

Browser-based rename, move, and delete for individual topics

Overview

You can use browser-based controls to change a topic's name, move it to another TWiki web, or delete it to a hidden Trash web.

How to Rename/Move/Delete a Topic

1. Click on [More] (bottom right of page) on the topic to be changed, then, in the new screen, on [Rename/move]. You can now rename and/or move/delete in one operation:
2. Move/Delete: Select the target web if other than the current web - choose Trash to delete a topic.
3. Rename: Enter the new topic name - default is current name
   NOTE: You'll be warned if any of the topics to be affected are locked (being edited), or if there is a name conflict.
4. Prevent updates by unchecking individual items on the list of referring links - these topics will NOT to be updated with the new name (by default, all referring links will be updated).
5. Click on [Rename/Move]: the topic will be renamed and links to the topic updated as requested.
   • If any of the referring pages are locked then they will be listed: you can correct these later by again pressing [Rename/Move].
   • There is a Put back feature that allows you to undo a Rename/Move/Delete - an instruction line and undo link will appear at the bottom of the modified topic. This allows you to revert from the last modification only.

Deleted Topics: How to Clear the Trash

Deleted topics are moved to a special Trash web - they are NOT physically erased from the server. All webs share Trash - in case of a name conflict with a topic already Trash, the user is alerted and asked to choose a new name.

The Trash web should be be cleared periodically, by archiving (saving) the text and RCS files if required (recommended), then deleting them from the Trash directory.

• This can only be done from on the server, not through the browser.
  • Since simple FTP access to the Trash directory is all that's required for maintenance, it's possible to grant Trash admin privileges to multiple users, while strictly limiting server access.

Redirecting from an Old Topic

You can use TWikiMetaData to place a command in the WebTopicViewTemplate and WebTopicNonWikiTemplate that will indicate that a topic has been moved by searching for the tag %META:TOPICMOVED{...}%. Customize something like this:

%<nop>METASEARCH{type="topicmoved" web="%WEB%" topic="%TOPIC%" 
title="This topic used to exist and was moved to: "}%

How Rename/Move Works

1. %SEARCH%, with a special template, finds and displays all occurrences of the topic name in other topics, site-wide. These referring links are by default automatically changed to the new topic and/or web name. This includes relevant TWikiMetaData definitions.
   • User can omit one or more topics from the update list by unchecking them.
   • <pre> and <verbatim> are honoured - no changes are made to text within these areas.
2. The topic is moved (if locks allow).
3. References are changed (locks and permissions permitting).
4. Any referring topics that can't be changed due to locks are listed - user can take note and change them at another time.

How Referring Topics Are Found

Referring topics are found using the %SEARCH% variable - see the template searchrenameview.tmpl. First, matching topics in the current web are listed - matches are to topic. Next, all webs (including the current one) are listed that match web.topic. Because %SEARCH% is used, webs marked in WebPreferences as NOSEARCHALL will not show up in the search for references to the topic being changed.

Changed references are kept are as short as possible, ex: topic is used in preference to web.topic.

Effect of User Access Settings

User permissions affect the Rename function in various ways. To rename a topic, you need both ALLOWTOPICCHANGE and ALLOWTOPICRENAME permission for that topic. To alter referring topics, you need change permission. See TWikiAccessControl for information on setting up access permissions.

Special Considerations

Consider carefully whether to make browser-based Rename/Move/Delete widely available, or to restrict it to an administrator/moderator group. Allowing all users to easily manipulate topics can be extremely useful in refactoring a busy web or site. However, there are at least two significant potential drawbacks to take into account:

• When referring links are updated, the modified topics appear in WebChanges, creating the impression that editorial changes were made. This can undermine the usefulness of WebChanges.
• Due to current limitations, fairly heavy use of Rename/Move/Delete functions can lead to an accumulation of minor technical problems (ex: broken links) and usability issues (ex: user confusion). If Rename... is used heavily, these negatives will obviously increase, in number and effect.

Ultimately, the size, objectives, and policies of your TWiki site, the real-world behavior of your user group, and most importantly, the initial TWiki site management leadership, will determine the most effective implementation of this feature, and the success of the site overall.

Known Issues

Rename/Move is fairly complicated due to the dynamic generation of links. Ideally, it would be possible to run the required part of rendering in a way that would allow identification of the text to be changed. Unfortunately, these hooks don't exist in TWiki at present. Instead, %SEARCH% is used with a special template to show the text to be changed, and the selected topics are then altered. One drawback is that search can show matches that will not be updated due to case differences. Other mismatches with actual rendered output are also possible as the approaches are so different.

The following shows some limitations of square bracket processing.

[[Old Topic]]  => [[NewTopic][Old Topic]]
[[old topic]]  => [[NewTopic][old topic]]
[[old t opic]] => not changed
[[OldTopic]]   => [[NewTopic]]

-- MikeMannix - 27 Dec 2001

Managing Webs

Adding webs is a web based operation; renaming and deleting webs are manual operations done directly on the server

Overview

A TWikiSite is divided into webs; each one represents one subject, one area of collaboration. Administrators can add/rename/delete webs.

Choose Web Template

There are two methods used to create a new web. First you can use a specially designed TemplateWeb. This is an invisible web that begins with an underscore "_" character. All topics in the _default template web will be copied into your new web.

The second method is to use an existing web as a template web. This may be useful if you already have a web that you like to use as a starting point. Only topics that have names beginning with Web... (like "WebHome", "WebNotify", etc.) are copied.

In either case you will want to be sure to verify that your new web has all the custom modifications that you desire.

Adding a New Web

Note: Attachments will NOT get copied over along with their topics. This will be a feature added for the TWiki:Codev/CairoRelease.

Note: This script does not yet edit the TWiki.TWikiPreferences file to update the WIKIWEBLIST. This must be done by hand.

The manage script while creating the new web will update the following variables in the WebPreferences: WEBBGCOLOR, SITEMAPLIST, SITEMAPWHAT, SITEMAPUSETO and NOSEARCHALL. These variables are now used to dynamically generate the SiteMap.

Renaming or Deleting a Web

Renaming or deleting a web requires direct access to the installation files on the host server. There are currently no browser-based equivalents of the Rename/move/delete topic tools for working with webs.

NOTE: If you plan to rename the TWiki.Main web, remember that TWiki stores user and group topics in %MAINWEB%, default named Main. That means, every WikiName signature - Main.SomeUserName - points to it and would need updating (unless the variable, %MAINWEB%.SomeUserName, is used throughout).

1. Prepare your site: Search each web for links to the target web, searching topic text for Oldwebname., including the dot so you'll find references like Oldwebname.SomeTopic.
   • Make changes as required, to Newwebname.SomeTopic or better yet, to %MAINWEB%.SomeTopic.
2. Edit the TWikiPreferences topic: Rename or delete the web from the WIKIWEBLIST variable.
3. Login to the TWiki server, via Telnet or FTP.
4. Go to twiki/data and rename or remove the web directory.
5. Go to twiki/templates and rename or remove the web directory if present.
6. Go to twiki/pub and rename or remove the web directory if present.

-- MikeMannix - 14 Sep 2001
-- PeterThoeny - 07 Apr 2002
-- GrantBow - 16 Jan 2003

Appendix A: TWiki Filesystem

Annotated directory and file listings, for the 01-Feb-2003 TWiki production release.

Who and What is This Good For?

Interested Users and Site Administrators can find out in simple terms what each part of TWiki actually does. Adventurous Adminstrators with server access to files (via telnet, ssh or ftp) can also figure out where to look to make minor modifications, like changing hardcode text or color. Software Developers can get an at-a-glance overview of TWiki code architecture.

Directory Structure

You can rename the root TWiki directory - twiki - to whatever you like by changing it in the TWiki.cfg configuration file. However, to keep the current installation and future upgrades simple, you should leave the five main subdirectories intact:

File Descriptions

A rundown of the individual files included in the current distribution, organized by TWiki root directories.

Files in twiki

Application info and the current reference documentation. Full file list:

Files in twiki/bin

Perl CGI scripts. Full file list:

Files under twiki/lib

The new lib/TWiki/Plugins directories contain configuration, library and function files, and TWikiPlugins. Full file list: