This page contains all documentation topics as one long, complete reference sheet.
Doubleclick anywhere to return to the top of the page.
Note - if you are reading this at twiki.org, then you are reading about the most recent code under development.
If you want to read about the features on your local TWiki, then you should read the documentation there!
Note: Read the most up to date version of this document at http://TWiki.org/cgi-bin/view/TWiki/TWikiDocumentation
Related Topics: TWikiSite, TWikiHistory, TWikiPlannedFeatures, TWikiEnhancementRequests
Server and client requirements
Low client and server base requirements are core features that keep TWiki widely deployable, particularly across a range of browser platforms and versions. Many Plugins and contrib modules exist which enhance and expand TWiki's capabilities; they may have additional 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.
Resource | Required Server Environment * |
---|---|
Perl | 5.005_03 or higher (5.8.4 or higher is recommended) |
RCS | 5.7 or higher (including GNU diff ) Optional, TWiki includes a pure perl implementation of RCS that can be used instead (although it's slower) |
GNU diff | GNU diff 2.7 or higher is required when not using the all-Perl RcsLite. Install on PATH if not included with RCS (check version with diff -v ) Must be the version used by RCS, to avoid problems with binary attachments - RCS may have hard-coded path to diff |
GNU patch | For upgrades only: GNU patch is required when using the TWiki:Codev.UpgradeTWiki script |
GNU fgrep , egrep | Modify command line parameters in configure if you use non-GNU grep programs |
Cron/scheduler | • Unix: cron • Windows: cron equivalents |
Web server | Apache is well supported; see TWiki:TWiki.InstallingTWiki#OtherWebServers for other servers |
Module | Preferred version |
---|---|
Algorithm::Diff (included) | |
CGI::Carp | >=1.26 |
Config | >=0 |
Cwd | >=3.05 |
Data::Dumper | >=2.121 |
Error (included) | |
File::Copy | >=2.06 |
File::Find | >=1.05 |
File::Spec | >=3.05 |
File::Temp | (included with perl 5.6 and later) |
FileHandle | >=2.01 |
IO::File | >=1.10 |
Text::Diff (included) | |
Time::Local | >=1.11 |
Module | Preferred version | Description |
---|---|---|
CGI::Cookie | >=1.24 | Used for session support |
CGI::Session | >=3.95 | Used for session support |
Digest::base | ||
Digest::SHA1 | ||
Jcode | Used for I18N support with perl 5.6 | |
Locale::Maketext::Lexicon | >=0 | Used for I18N support |
Net::SMTP | >=2.29 | Used for sending mail |
Unicode::Map | Used for I18N support with perl 5.6 | |
Unicode::Map8 | Used for I18N support with perl 5.6 | |
Unicode::MapUTF8 | Used for I18N support with perl 5.6 | |
Unicode::String | Used for I18N support with perl 5.6 | |
URI | Used for configure |
Most of them will probably already be available in your installation. You can check version numbers with the configure
script, or if you're still trying to get to that point, check from the command line like this:
perl -e 'use FileHandle; print $FileHandle::VERSION."\n"'
The TWiki standard installation has relatively low browser requirements:
CSS and Javascript are used in most skins, although there is a low-fat skin (Classic skin) available that minimises these requirements. Some skins will require more recent releases of browsers. The default skin (Pattern) is tested on IE 6, Safari, and Mozilla 5.0 based browsers (such as Firefox).
You can easily select a balance of browser capability versus look and feel. Try the installed skins at TWikiSkinBrowser and more at TWiki:Plugins.SkinPackage.
Related Topics: AdminDocumentationCategory
Installation instructions for the TWiki 4.1 production release.
If you are upgrading from a previous version of TWiki, you probably want to read TWikiUpgradeGuide instead.
TWiki should be fine with any web server and OS that meet the system requirements. The following installation instructions are written for experienced system administrators; please review the AdminSkillsAssumptions before you install TWiki. If you need help, ask a question in the TWiki:Support web or on TWiki:Codev.TWikiIRC (irc.freenode.net, channel #twiki)
Hint: TWiki:TWiki.InstallingTWiki on TWiki.org has supplemental documentation that help you install TWiki on different platforms, environments and web hosting sites.
data
and pub
directories and to lib/LocalSite.cfg
. Everything else should be read-only.
/usr/bin/perl
. If it's somewhere else, change the path to Perl in the first line of each script in the twiki/bin
directory. .cgi
or .pl
). If necessary, rename all files in twiki/bin
(i.e. rename view
to view.pl
etc). If you do this, make sure you set the ScriptSuffix
option in configure (Step 6).
/twiki/bin/LocalLib.cfg
. /twiki/bin/LocalLib.cfg.txt
. $twikiLibPath
, which must point to the absolute file path of your twiki/lib
e.g. /home/httpd/twiki/lib
. $CPANBASE
to point to your personal CPAN install. Don't forget that the webserver user has to be able to read those files as well.
bin/configure
script from your browser. httpd.conf
file in twiki_httpd_conf.txt
at the root of the package. This file also contains advice on securing your installation. Additionally, see TWiki:TWiki.ApacheConfigGenerator. There's also a script called tools/rewriteshebang.pl
to help you in fixing up the shebang lines in your CGI scripts.
configure
script from your browser, and resolve any errors or warnings it tells you about.
http://yourdomain.com/twiki/bin/view
and start TWiki-ing away!
configure
script and make sure you have resolved all errors, and are happy that you understand any warnings.
Warning: Can't find topic TWiki.WindowsInstallCookbook
Upgrade from the previous TWiki 01-Sep-2004 Production Release to TWiki-4.X
TWiki-4.0.0 was a major new release. TWiki-4.1.0 is a minor release without dramatic changes since 4.0.0
See TWikiReleaseNotes04x00 and TWikiReleaseNotes04x01
The following steps are a rough guide to upgrading only. It is impossible to give detailed instructions, as what you have to do may depend on whether you can configure the webserver or not, and how much you have changed distributed files in your current TWiki release.
The main steps are:
lib/TWiki.cfg
from the old TWiki installation is a good resource for some of the settings you will need but you cannot reuse the old TWiki.cfg.
DEFAULT_TYPE
setting of the CommentPlugin, create a COMMENTPLUGIN_DEFAULT_TYPE
setting in Main.TWikiPreferences.
find data -name '*,v' -exec rcs -u -M '{}' \;
find pub -name '*,v' -exec rcs -u -M '{}' \;
TWiki.TWikiUsers
topic to the new TWiki. If you upgrade from Cairo you can simply use the old file and add the missing new system users to the list of users. If you upgrade from TWiki-4.0.X simply use the old topic.
data/.htpasswd
for authentication copy this file from the old TWiki to the new. tools/upgrade_emails.pl
.
Main.TWikiPreferences
. This avoids having to write over files in the distribution on a later upgrade.
data/TWiki
of the old and new TWiki installation, and transfer the changes into the new TWiki install.
WebPreferences
topics in the old TWiki Installation with the default from the new TWiki installation and add any new Preferences that may be relevant.
WebLeftBar
topics in the old TWiki Installation with the default from the new TWiki installation and add any new feature that you desire.
TWiki4's PatternSkin introduces the use of the favicon feature which most browsers use to show a small icon in front of the URL and for bookmarks.
In TWiki4 it is assumed that each web has a favicon.ico file attached to the WebPreferences topic. When you upgrade from Cairo to TWiki4 you do not have this file and you will get flooded with errors the error log of your web server. There are two solutions to this.
To change the location of favicon.ico in TWikiPreferences to the TWiki web add this line to TWikiPreferences
* Set FAVICON = %PUBURLPATH%/%TWIKIWEB%/%WEBPREFSTOPIC%/favicon.ico
Your Cairo Main.TWikiUsers topic will work in TWiki4 but you will need to ensure that these 4 users from the default TWiki4 version of TWikiUsers are copied to the existing TWikiUsers topic. TWikiGuest is probably already there but the others are new
You additionally need to ensure that TWikiUsers has the Set ALLOWTOPICCHANGE = TWikiAdminGroup, TWikiRegistrationAgent
. Otherwise people will not be able to register.
TWiki 4.0.5 worked on Perl version 5.6.X. Reports from users has shown that unfortunately TWiki 4.1.0 does not support Perl versions older then 5.8.0. It is the goal that TWiki should work on at least Perl version 5.6.X but none of the developers have had access to Perl installations older than 5.8.0.
Since TWiki 4.1.0 has some urgent bugs the development team decided to release TWiki 4.1.1 without resolving the issue with Perl 5.6.X. We will however address this and try and resolve it for a planned 4.1.2 release. The TWiki community is very interested in contributions from users that have fixes for the code which will enable TWiki to run on older versions of Perl.
See the WhatVersionsOfPerlAreSupported topic to keep up to date with the discussion how to get back support for earlier Perl versions.
Until TWiki 4.0.5 TWikiTemplates the text inside template definition blocks (anything between %TMPL:DEF{"block"}% and %TMPL:END% was stripped of leading and trailing white space incl new lines.
This caused a lot of problems for skin developers when you wanted a newline before or after the block text.
From TWiki 4.1.0 this has changed so that white space is no longer stripped. Skins like PatternSkin and NatSkin have been updated so that they work with the new behavior. But if you use an older skin or have written your own you will most likely need to make some adjustments.
It is not difficult. The general rule is - if you get mysterious blank lines in your skin, the newline after the %TMPL:DEF{"block"}% needs to be removed. Ie. the content of the block must follow on the same line as the TMPL:DEF.
The spec change have the same impact on CommentPlugin templates where you may have to remove the first line break after the TMPL:DEF. See the CommentPluginTemplate for examples of how comment template definitions should look like in TWiki-4.1.X
An example: A CommentPlugin template that adds a comment as appending a row to a table. Before the spec change this would work.
<verbatim> %TMPL:DEF{OUTPUT:tabletest}%%POS:BEFORE% |%URLPARAM{"comment"}%| -- %WIKIUSERNAME% - %DATE% | %TMPL:END% </verbatim>
From Twiki 4.1.0 the old template definition will add an empty line before the new table row. To fix it simply remove the new line before the table.
<verbatim> %TMPL:DEF{OUTPUT:tabletest}%%POS:BEFORE%|%URLPARAM{"comment"}%| -- %WIKIUSERNAME% - %DATE% | %TMPL:END% </verbatim>
The advantage of the spec change is that now you can add leading and trailing white space including new lines. This was not possible before.
An upgrader upgrading to 4.1.1 should note the following important change
The directory for passthrough files and session files have been replaced by a common directory for temporary files used by TWiki. Previously the two configure settings {PassthroughDir}
and {Sessions}{Dir}
were by default set to /tmp
. These config settings have been replaced by {TempfileDir}
with the default setting value /tmp/twiki
. If the twiki
directory does not exist twiki will create it first time it needs it.
It is highly recommended no longer to use the tmp directory common to other web applications and the new default will work fine for most. You may want to delete all the old session files in /tmp after the upgrade to 4.1.1. They all start with cgisess_. It is additionally highly recommended to limit write access to the {TempfileDir}
for security reasons if you have non-admin users with login access to the webserver just like you would do with the other webserver directories.
TWiki site access control and user activity tracking options
Authentication, or "login", is the process by which a user lets TWiki know who they are.
Authentication isn't just to do with access control. TWiki uses authentication to identify users, so it can keep track of who made changes, and manage a wide range of personal settings. With authentication enabled, users can personalise TWiki and contribute as recognised individuals, instead of shadows.
TWiki authentication is very flexible, and can either stand alone or integrate with existing authentication schemes. You can set up TWiki to require authentication for every access, or only for changes. Authentication is also essential for access control.
Quick Authentication Test - Use the %USERINFO% variable to return your current identity:
TWiki user authentication is split into four sections; password management, user mapping, user registration, and login management. Password management deals with how users personal data is stored. Registration deals with how new users are added to the wiki. Login management deals with how users log in.
Once a user is logged on, they can be remembered using a Client Session stored in a cookie in the browser (or by other less elegant means if the user has disabled cookies). This avoids them having to log on again and again.
TWiki user authentication is configured through the Security Settings pane in the configure interface.
Please note FileAttachments are not protected by TWiki User Authentication.
Tip: TWiki:TWiki.TWikiUserAuthenticationSupplement on TWiki.org has supplemental documentation on user authentication.
As shipped, TWiki supports the Apache 'htpasswd' password manager. This manager supports the use of .htpasswd
files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encodings are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the [[/twiki/bin/configure][configure] interface for more details.
You can easily plug in alternate password management modules to support interfaces to other third-party authentication databases.
Often when you are using an external authentication method, you want to map from an unfriendly "login name" to a more friendly WikiName. Also, an external authentication database may well have user information you want to import to TWiki, such as user groups.
By default, TWiki supports mapping of usernames to wikinames, and supports TWiki groups internal to TWiki. If you want, you can plug in an alternate user mapping module to support import of groups etc.
New user registration uses the password manager to set and change passwords and store email addresses. It is also responsible for the new user verification process. the registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).
The registration process is also responsible for creating user topics, and setting up the mapping information used by the User Mapping support.
Login management controls the way users have to log in. There are three basic options; no login, login via a TWiki login page, and login using the webserver authentication support.
none
in configure) Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.
Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to the TWikiAdminGroup.
TWiki::Client::TemplateLogin
in configure) Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out. Client Sessions are used to remember users.
TWiki::Client::TemplateLogin
login manager (on the Security Settings pane).
.htpasswd
files, check that a new line with the username and encrypted password is added to the .htpasswd
file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
TWikiAccessControl has more information on setting up access controls.
At this time TWikiAccessControls cannot control access to files in the
pub
area, unless they are only accessed through the viewfile
script. If your pub
directory is set up in the webserver to allow open access you may want to add .htaccess
files in there to restrict access.
You can create a custom version of the TWikiRegistration form by deleting or adding input tags. The
name=""
parameter of the input tags must start with: "Twk0..."
(if this is an optional entry), or "Twk1..."
(if this is a required entry). This ensures that the fields are carried over into the user home page correctly.
You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics
TWiki::Client::ApacheLogin
in configure)
Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER
environment variable, which is set when you enable authentication in the webserver.
The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules such as mod_auth_ldap
or mod_auth_mysql
you can just plug in directly to them.
The disadvantage is that because the user identity is cached in the browser, you can log in, but you can't log out again unless you restart the browser.
TWiki maps the REMOTE_USER
that was used to log in to the webserver to a WikiName using the table in TWikiUsers. This table is updated whenever a user registers, so users can choose not to register (in which case their webserver login name is used for their signature) or register (in which case that login name is mapped to their WikiName).
The same private .htpasswd
file used in TWiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support.
Warning: Do not use the Apache htpasswd
program with .htpasswd
files generated by TWiki! htpasswd
wipes out email addresses that TWiki plants in the info fields of this file.
mod_auth
TWiki::Client::ApacheLogin
login manager.
.htpasswd
entries.
.htaccess
file in the twiki/bin
directory.twiki/bin/.htaccess.txt
that you can copy and change. The comments in the file explain what need to be done..htaccess
does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf
(if you have root access; otherwise, e-mail web server support) pub
area, unless they are only accessed through the viewfile
script. If your pub
directory is set up to allow open access you may want to add .htaccess
files in there as well to restrict access
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. .htpasswd
file. If not, you may have got a path wrong, or the permissions may not allow the webserver user to write to that file.
Any time a user enters a page that needs authentication, they will be forced to log on. It may be convenient to have a "logon" as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log on.
The bin/logon
script accomplishes this. The bin/logon
script must be setup in the bin/.htaccess
file to be a script which requires a valid user
. However, once authenticated, it will simply redirect the user to the view URL for the page from which the logon
script was linked.
TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address.
You don't have to enable sessions to support logins in TWiki. However it is strongly recommended. TWiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don;t enable sessions, TWiki will try hard to remember you, but due to limitations in the browsers it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.
There are a number of TWikiVariables available that you can use to interrogate your current session. You can even add your own session variables to the TWiki cookie. Session variables are referred to as "sticky" variables.
You can get, set, and clear session variables from within TWiki web pages or by using script parameters. This allows you to use the session as a personal "persistent memory space" that is not lost until the web browser is closed. Also note that if a session variable has the same name as a TWiki preference, the session variables value takes precedence over the TWiki preference. This allows for per-session preferences.
To make use of these features, use the tags:
%SESSION_VARIABLE{ "varName" }% %SESSION_VARIABLE{ "varName" set="varValue" }% %SESSION_VARIABLE{ "varName" clear="" }%
Note that you cannot override access controls preferences this way.
TWiki normally uses cookies to store session information on a client computer. Cookies are a common way to pass session information from client to server. TWiki cookies simply hold a unique session identifier that is used to look up a database of session information on the TWiki server.
For a number of reasons, it may not be possible to use cookies. In this case, TWiki has a fallback mechanism; it will automatically rewrite every internal URL it sees on pages being generated to one that also passes session information.
This section applies only if you are using authentication with existing login names (i.e. mapping from login names to WikiNames).
TWiki internally manages two usernames: Login Username and TWiki Username.
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.
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 if the {AllowLoginName} is enabled in configure. The default is to use your WikiName as a login name.
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces, for exampleMain.WikiUsername
or%MAINWEB%.WikiUsername
. This pointsWikiUsername
to the Main web, where user home pages are located, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic? everywhere but in the Main web.
If your {PasswordManager} supports password changing, you can change and reset passwords using forms on regular pages.
TWiki/ChangePassword
)
TWiki/ResetPassword
)
If the active {PasswordManager} supports storage and retrieval of user e-mail addresses, you can change your e-mail using a regular page. As shipped, this is true only for the Apache 'htpasswd' password manager.
TWiki/ChangeEmailAddress
)
.htaccess
One of the key features of TWiki is that it is possible to add HTML to topics. No authentication method is 100% secure on a website where end users can add HTML, as there is always a risk that a malicious user can add code to a topic that gathers user information, such as session IDs. The TWiki developers have been forced to make certain tradeoffs, in the pursuit of efficiency, that may be exploited by a hacker.
This section discusses some of the known risks. You can be sure that any potential hackers have read this section as well!
At one extreme, the most secure method is to use TWiki via SSL (Secure Sockets Layer), with a login manager installed and Client Sessions turned off.
Using TWiki with sessions turned off is a pain, though, as with all the login managers there are occasions where TWiki will forget who you are. The best user experience is achieved with sessions turned on.
As soon as you allow the server to maintain information about a logged-in user, you open a door to potential attacks. There are a variety of ways a malicious user can pervert TWiki to obtain another users session ID, the most common of which is known as a cross-site scripting attack. Once a hacker has an SID they can pretend to be that user.
To help prevent these sorts of attacks, TWiki supports IP matching, which ensures that the IP address of the user requesting a specific session is the same as the IP address of the user who created the session. This works well as long as IP addresses are unique to each client, and as long as the IP address of the client can't be faked.
Session IDs are usually stored by TWiki in cookies, which are stored in the client browser. Cookies work well, but not all environments or users permit cookies to be stored in browsers. So TWiki also supports two other methods of determining the session ID. The first method uses the client IP address to determine the session ID. The second uses a rewriting method that rewrites local URLs in TWiki pages to include the session ID in the URL.
The first method works well as long as IP addresses are unique to each individual client, and client IP addresses can't be faked by a hacker. If IP addresses are unique and can't be faked, it is almost as secure as cookies + IP matching, so it ranks as the fourth most secure method.
If you have to turn IP matching off, and cookies can't be relied on, then you may have to rely on the second method, URL rewriting. This method exposes the session IDs very publicly, so should be regarded as "rather dodgy".
Most TWiki sites don't use SSL, so, as is the case with most sites that don't use SSL, there is always a possibility that a password could be picked out of the aether. Browsers do not encrypt passwords sent over non-SSL links, so using Apache Login is no more secure than Template Login.
Of the two shipped login managers, Apache Login is probably the most useful. It lets you do this sort of thing: wget --http-user=RogerRabbit --http-password=i'mnottelling http://www.example.com/bin/save/Sandbox/StuffAUTOINC0?text=hohoho,%20this%20is%20interesting i.e. pass in a user and password to a request from the command-line. However it doesn't let you log out.
Template Login degrades to url re-writing when you use a client like dillo that does not support cookies. However, you can log out and back in as a different user.
Finally, it would be really neat if someone was to work out how to use certificates to identify users.....
See TWiki:TWiki.SecuringTWikiSite for more information.
Restricting read and write access to topics and webs, by Users and groups
TWiki Access Control allows you restrict access to single topics and entire webs, by individual user and by user Groups. Access control, combined with TWikiUserAuthentication, lets you easily create and manage an extremely flexible, fine-grained privilege system.
Tip: TWiki:TWiki.TWikiAccessControlSupplement on TWiki.org has additional documentation on access control.
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 great care - the more restrictions, the less Wiki in the mix. Experience shows that unrestricted write access works very well because:
See TWikiAccessControl for details
Please Note:
Note: Above table comes from SitePermissions
Authentication: Identifies who a user is based on a login procedure. See TWikiUserAuthentication.
Access control: Restrict access to content based on users and groups once a user is identified.
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.
A user can create an account in TWikiRegistration. The following actions are performed:
The default visitor name is TWikiGuest. This is the non-authenticated user.
Groups are defined by group topics located in the Main
web, such as the TWikiAdminGroup. To create a new group, visit TWikiGroups and enter the name of the new group ending in Group
into the "new group" form field. This will create a new group topic with two important settings:
Set GROUP = < list of Users and/or Groups >
Set ALLOWTOPICCHANGE = < list of Users and/or Groups >
The GROUP setting is a comma-separated list of users and/or other groups. Example:
Set GROUP = Main.SomeUser, Main.OtherUser, Main.SomeGroup
The ALLOWTOPICCHANGE setting 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
Note: TWiki has strict formatting rules. Make sure you have three spaces, an asterisk, and an extra space in front of any access control rule.
By mistyping a user or group name in the settings, it's possible to lock a topic so that no-one can edit it from a browser. To avoid this, add the WikiNames of registered administrators to the super admin group topic called TWikiAdminGroup
. The name of this topic is defined by the {SuperAdminGroup} configure setting. Example group setting:
Set GROUP= Main.ElizabethWindsor, Main.TonyBlair
You can define who is allowed to read or write to a web or a topic. Note that some plugins may not respect access permissions.
You can define restrictions on who is allowed to view a TWiki web. You can restrict access to certain webs to selected Users and Groups, by:
Set DENYWEBVIEW = < comma-delimited list of Users and Groups >
Set ALLOWWEBVIEW = < comma-delimited list of Users and Groups >
Set DENYWEBCHANGE = < comma-delimited list of Users and Groups >
Set ALLOWWEBCHANGE = < comma-delimited list of Users and Groups >
Be careful with empty values for any of these. In older versions of TWiki,
Set ALLOWWEBVIEW =
Set DENYWEBVIEW =
Set DENYTOPICVIEW = < comma-delimited list of Users and Groups >
Set ALLOWTOPICVIEW = < comma-delimited list of Users and Groups >
Set DENYTOPICCHANGE = < comma-delimited list of Users and Groups >
Set ALLOWTOPICCHANGE = < comma-delimited list of Users and Groups >
Remember when opening up access to specific topics within a restricted web that other topics in the web - for example, the WebLeftBar - may also be accessed when viewing the topics. The message you get when you are denied access should tell you what topic you were not permitted to access.
Be careful with empty values for any of these. In older versions of TWiki,
Set ALLOWTOPICVIEW =
Set DENYTOPICVIEW =
Attachments are referred to directly, and are not normally indirected via TWiki scripts. This means that the above instructions for access control will not apply to attachments. It is possible that someone may inadvertently publicise a URL that they expected to be access-controlled.
The easiest way to apply the same access control rules for attachments as apply to topics is to use the Apache mod_rewrite
module, and configure your webserver to redirect accesses to attachments to the TWiki viewfile
script. For example,
ScriptAlias /twiki/bin/ /filesystem/path/to/twiki/bin/ Alias /twiki/pub/ /filesystem/path/to/twiki/pub/ RewriteEngine on RewriteCond %{REQUEST_URI} !^/+twiki/+pub/+TWiki/+.+ RewriteRule ^/+twiki/+pub/+([^/]+)/+((([^/]+)/+)+)(.+) /twiki/bin/viewfile/$1/$4?filename=$5 [L,PT]
That way all the controls that apply to the topic also apply to attachments to the topic. Other types of webserver have similar support.
Note: Images embedded in topics will load much slower since each image will be delivered by the viewfile
script.
Set DENYROOTCHANGE = < comma-delimited list of Users and Groups >
Set ALLOWROOTCHANGE = < comma-delimited list of Users and Groups >
ROOTCHANGE
access to rename an existing top-level web. You just need WEBCHANGE
in the web itself.
When deciding whether to grant access, TWiki evaluates the following rules in order (read from the top of the list; if the logic arrives at PERMITTED or DENIED that applies immediately and no more rules are applied). You need to read the rules bearing in mind that VIEW and CHANGE access may be granted/denied separately.
Another way of hiding webs is to keep them hidden by not publishing the URL and by preventing the all webs
search option from accessing obfuscated webs. Do so by enabling the NOSEARCHALL
variable in WebPreferences:
Set NOSEARCHALL = on
This setup can be useful to hide a new web until content its ready for deployment, or to hide view access restricted webs.
Note: Obfuscating a web without view access control is very insecure, as anyone who knows the URL can access the web.
Use the following setup to authenticate users for topic viewing in all webs and to restrict access to selected webs. Requires TWikiUserAuthentication to be enabled.
Set DENYWEBVIEW = < list of Users and Groups >
Set ALLOWWEBVIEW = < list of Users and Groups >
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.
Use the following setup to provide unrestricted viewing access to open webs, with authentication only on selected webs. Requires TWikiUserAuthentication to be enabled.
Set DENYWEBVIEW = < list of Users and Groups >
Set ALLOWWEBVIEW = < list of Users and Groups >
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.
Tip: To hide access control settings from normal browser viewing, you can put them into the topic-local settings. You can access those settings via the "More" screen, as explained in TWikiVariables.
Alternatively, place them in HTML comment markers, but this exposes the access setting during ordinary editing.
<!--
* Set DENYTOPICCHANGE = Main.SomeGroup
-->
Working in TWiki is as easy as typing in text. You don't need to know HTML, though you can use it if you prefer. Links to topics are created automatically when you enter WikiWords. And TWiki shorthand gives you all the power of HTML with a simple coding system that takes no time to learn. It's all laid out below.
Formatting Command: | You write: | You get: | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Paragraphs: Blank lines will create new paragraphs. |
1st paragraph 2nd paragraph |
1st paragraph
2nd paragraph |
|||||||||||||||||||||||||
Headings: Three or more dashes at the beginning of a line, followed by plus signs and the heading text. One plus creates a top level heading, two pluses a second level heading, etc. The maximum heading depth is 6.
You can create a table of contents with the %TOC% variable. If you want to exclude a heading from the TOC, put
|
---++ Sushi ---+++ Maguro ---+++!! Not in TOC |
SushiMaguroNot in TOC |
|||||||||||||||||||||||||
Bold Text: Words get shown in bold by enclosing them in * asterisks.
|
*Bold* | Bold | |||||||||||||||||||||||||
Italic Text: Words get shown in italic by enclosing them in _ underscores.
|
_Italic_ | Italic | |||||||||||||||||||||||||
Bold Italic: Words get shown in bold italic by enclosing them in __ double-underscores.
|
__Bold italic__ | Bold italic | |||||||||||||||||||||||||
Fixed Font: Words get shown in fixed font by enclosing them in = equal signs.
|
=Fixed font= |
Fixed font
|
|||||||||||||||||||||||||
Bold Fixed Font: Words get shown in bold fixed font by enclosing them in double equal signs.
|
==Bold fixed== |
Bold fixed
|
|||||||||||||||||||||||||
![]() * _ __ = == ) indicator
with normal punctuation, such as commas and full stops.
|
_This works_, _this does not _ |
This works, _this does not _ |
|||||||||||||||||||||||||
Verbatim (Literal) Text: Surround code excerpts and other formatted text with <verbatim> and </verbatim> tags.![]() verbatim tags disable HTML code. Use <pre> and </pre> tags instead if you want the HTML code within the tags to be interpreted.![]() |
<verbatim> class CatAnimal { void purr() { <code here> } } </verbatim> |
class CatAnimal { void purr() { <code here> } } |
|||||||||||||||||||||||||
Separator (Horizontal Rule): Three or more three dashes at the beginning of a line.. |
------- |
|
|||||||||||||||||||||||||
Bulleted List: Multiple of three spaces, an asterisk, and another space. ![]() |
* level 1 * level 2 * back on 1 * A bullet broken over three lines * last bullet |
|
|||||||||||||||||||||||||
Numbered List: Multiple of three spaces, a type character, a dot, and another space. Several types are available besides a number:
|
1. Sushi 1. Dim Sum 1. Fondue A. Sushi A. Dim Sum A. Fondue i. Sushi i. Dim Sum i. Fondue |
|
|||||||||||||||||||||||||
Definition List: Three spaces, a dollar sign, the term, a colon, a space, followed by the definition. |
$ Sushi: Japan $ Dim Sum: S.F. |
|
|||||||||||||||||||||||||
Table: Each row of the table is a line containing of one or more cells. Each cell starts and ends with a vertical bar '|'. Any spaces at the beginning of a line are ignored.
![]() |^| multiple-span row functionality and additional rendering features
|
| *L* | *C* | *R* | | A2 | B2 | C2 | | A3 | B3 | C3 | | multi span ||| | A5-7 | 5 | 5 | |^| six | six | |^| seven | seven | | split\ | over\ | 3 lines | | A9 | B9 | C9 | |
|
|||||||||||||||||||||||||
WikiWord Links: CapitalizedWordsStuckTogether (or WikiWords) will produce a link automatically if preceded by whitespace or parenthesis. ![]() Otherweb.TopicName . ![]() It's generally a good idea to use the TWikiVariables %TWIKIWEB% and %MAINWEB% instead of TWiki and Main. |
WebStatistics Sandbox.WebNotify Sandbox.WebHome | WebStatistics | |||||||||||||||||||||||||
Anchors: You can define a reference inside a TWiki topic (called an anchor name) and link to that. To define an anchor write #AnchorName at the beginning of a line. The anchor name must be a WikiWord. To link to an anchor name use the [[MyTopic#MyAnchor]] syntax. You can omit the topic name if you want to link within the same topic.
|
[[WikiWord#NotThere]] [[#MyAnchor][Jump]] #MyAnchor To here | WikiWord#NotThere | |||||||||||||||||||||||||
Forced Links: You can create a forced internal link by enclosing words in double square brackets. Text within the brackets may contain optional spaces; the topic name is formed by capitalizing the initial letter and by removing the spaces; for example, [[text formatting FAQ]] links to topic TextFormattingFAQ. You can also refer to a different web and use anchors.
![]() |
[[wiki syntax]] [[Main.TWiki users]] escaped: ![[wiki syntax]] |
wiki syntax
escaped: [[wiki syntax]] |
|||||||||||||||||||||||||
Specific Links: You can create a link where you specify the link text and the URL separately using nested square brackets [[reference][text]] . Internal link references (e.g. WikiSyntax) and URLs (e.g. http://TWiki.org/) are both supported.
The rules described under Forced Links apply for internal link references.
![]() |
[[WikiSyntax][wiki syntax]] [[http://gnu.org][GNU]] | wiki syntax | |||||||||||||||||||||||||
Prevent a Link: Prevent a WikiWord from being linked by prepending it with an exclamation point. |
!SunOS | SunOS | |||||||||||||||||||||||||
Disable Links: You can disable automatic linking of WikiWords by surrounding text with <noautolink> and </noautolink> tags.![]() |
<noautolink> RedHat & SuSE </noautolink> | RedHat & SuSE | |||||||||||||||||||||||||
Mailto Links: E-mail addresses are linked automatically. To create e-mail links that have more descriptive link text, specify subject lines or message bodies, or omit the e-mail address, you can write [[mailto:user@domain][descriptive text]] .
|
a@b.com [[mailto:a@b.com]\ [Mail]] [[mailto:?subject=\ Hi][Hi]] | a@b.com |
You can use just about any HTML tag without a problem. You can add HTML if there is no TWiki equivalent, for example, write <strike>deleted text</strike>
to get deleted text.
There are a few usability and technical considerations to keep in mind:
Recommendations when pasting HTML from other sources:
<body>
and </body>
tags.
<p />
paragraph tags on empty lines, which causes problems if done between HTML tags that do not allow paragraph tags, like for example between table tags.
<...>
- of an HTML tag are on the same line, or the tag will be broken.
TWiki converts shorthand notation to HTML for display. To copy a fully marked-up page, simply view the source in your browser and save the contents. If you need to save HTML frequently, you may want to check out TWiki:Plugins/PublishAddOn.
You can use HTML <script>
tags for your TWiki applications. However note that your TWiki administrator can disable <script>
in topics, and may have chosen to do so for security considerations. TWiki markup and TWikiVariables are not expanded inside script tags.
Being able to create links without any special formatting is a core TWiki feature, made possible with WikiWords and inline URLs.
http://...
, https://...
, ftp://...
, gopher://...
, news://...
, file://...
, telnet://...
and mailto:...@...
are linked automatically.
name@domain.com
are linked automatically.
[[Square bracket rules]]
let you easily create non-WikiWord links. [[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 are names that are enclosed in percent signs %
that are expanded on the fly. Some variables take arguments, such as %INCLUDE%
. For those variables, the arguments are included in curly braces ({ and }).
Variable | In brief | Full documentation |
---|---|---|
%TOC% | Automatically generates a table of contents based on headings in a topic - see the top of this page for an example. | VarTOC |
%WEB% | The current web, is TWiki. | VarWEB |
%TOPIC% | The current topic name, is TWikiDocumentation. | VarTOPIC |
%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. | VarATTACHURL |
%INCLUDE{"SomeTopic"}% | Server side include, includes another topic. The current web is the default web. Example: %INCLUDE{"TWiki.SiteMap"}% | VarINCLUDE |
%SEARCH{"sushi"}% | Inline search showing the search result embedded in a topic. FormattedSearch gives you control over formatting, useful for creating web-based applications. | VarSEARCH |
TWikiPreferences defines some site-wide variables. Among them are:
%BR%
to start a new line.
%RED% Red %ENDCOLOR% and %BLUE% blue %ENDCOLOR% colors
to get: Red and blue colors.
There are many more variables. To see them all, go to TWikiVariables.
Documentation Graphics: There are many graphics available to use in your topics. Use %ICON{"help"}%
, %ICON{"tip"}%
, and %ICON{"warning"}%
to get: ,
, and
, respectively. TWikiDocGraphics lists them all.
To "escape" a variable, prefix it with an exclamation mark. Write:
!%SOMEVARIABLE%
to get: %SOMEVARIABLE%.
Plugins can extend the functionality of TWiki into many other areas. There are a huge number of TWiki plugins available from the Plugins web on TWiki.org.
Currently enabled plugins on this TWiki installation, as listed by %PLUGINDESCRIPTIONS%
:
"$SUM( $ABOVE() )"
to TWiki tables and other topic textExternalSite:Page
text to external sites based on aliases defined in a rules topic :-)
or Check on current Plugin status and settings for this site in TWikiPreferences.
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:
<filename>
is not displayed. How can I show it as it is? '<'
and '>'
characters have a special meaning in HTML, they define HTML tags. You need to escape them, so write '<'
instead of '<'
, and '>'
instead of '>'
. 'prog <filename>'
to get 'prog <filename>'
.
'&'
character sometimes not displayed? '&'
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 '&'
. 'This & that'
to get 'This & that'
.
Special text strings expand on the fly to display user data or system info
TWikiVariables are text strings - %VARIABLE%
or %VARIABLE{ parameter="value" }%
- that expand into content whenever a topic is rendered for viewing. There are two types of variables:
%CALC{}%
variable)
To use a variable type its name. For example,
%T%
to get %TOPIC%
to get TWikiVariables
(a predefined variable)
%CALC{ "$UPPER(Text)" }%
to get TEXT
(a variable defined by Plugin)
Note:
!%TOPIC%
to get %TOPIC%
%ALLVARIABLES%
to get a full listing of all variables defined for a particular topic
%MYVAR%
, %MyVar%
, %My2ndVar%
, and %My_Var%
are all valid variable names. Variables are case sensitive. %MyVAR%
and %MYVAR%
are not the same variable.
By convention all settings, predefined variables and variables used by plugins are always UPPER-CASE.
Unlike predefined variables, preferences variables can be defined by the user in various places.
Settings at higher-numbered levels override settings of the same variable at lower numbered levels, unless the variable was included in the setting of FINALPREFERENCES at a lower-numbered level, in which case it is locked at the value it has at that level.
The syntax for setting Variables is the same anywhere in TWiki (on its own TWiki bullet line, including nested bullets):
[multiple of 3 spaces] * [space] Set [space] VARIABLENAME [space] = [space] value
Examples:Spaces between the = sign and the value will be ignored. You can split a value over several lines by indenting following lines with spaces - as long as you don't try to use * as the first character on the following line.
Set VARIABLENAME = value
Set VARIABLENAME = value
Example:* Set VARIABLENAME = value starts here and continues here
Whatever you include in your Variable will be expanded on display, exactly as if it had been entered directly.
Example: Create a custom logo variable
- To place a logo anywhere in a web by typing
%MYLOGO%
, define the Variable on the web's WebPreferences topic, and upload a logo file, ex:mylogo.gif
. You can upload by attaching the file to WebPreferences, or, to avoid clutter, to any other topic in the same web, e.g.LogoTopic
. Sample variable setting in WebPreferences:
Set MYLOGO = %PUBURL%/%WEB%/LogoTopic/mylogo.gif
You can also set preferences variables on a topic by clicking the link Edit topic preference settings
under More topic actions
. Preferences set in this manner are not visible in the topic text, but take effect nevertheless.
These are special types of preferences variables to control access to content. TWikiAccessControl explains these security settings in detail.
Local
in place of Set
in the variable definition. For example, if the user sets the following in their home topic:
* Set EDITBOXHEIGHT = 10 * Local EDITBOXHEIGHT = 20Then when they are editing any other topic, they will get a 10 high edit box. However when they are editing their home topic, they will get a 20 high edit box.
Local
can be used wherever a preference needs to take a different value depending on where the current operation is being performed.
Use this powerful feature with great care! %ALLVARIABLES%
can be used to get a listing of the values of all variables in their evaluation order, so you can see variable scope if you get confused.
The following preferences variables are frequently used. They are defined in TWikiPreferences#Miscellaneous_Settings:
%BR%
- line break
%BULLET%
- bullet sign
%BB%
- line break and bullet combined
%BB2%
- indented line break and bullet
%RED% text %ENDCOLOR%
- colored text (also %YELLOW%
, %ORANGE%
, %PINK%
, %PURPLE%
, %TEAL%
, %NAVY%
, %BLUE%
, %AQUA%
, %LIME%
, %GREEN%
, %OLIVE%
, %MAROON%
, %BROWN%
, %BLACK%
, %GRAY%
, %SILVER%
, %WHITE%
)
%H%
- %I%
- %M%
- %N%
- %P%
- %Q%
- %S%
- %T%
- %U%
- %X%
- %Y%
- There are additional useful preferences variables defined in TWikiPreferences, in Main.TWikiPreferences, and in WebPreferences of every web.
Most predefined variables return values that were either set in the configuration when TWiki was installed, or taken from server info (such as current username, or date and time). Some, like %SEARCH%
, are powerful and general tools.
%INCLUDINGTOPIC%
, %INCLUDE%
, and the mighty %SEARCH%
.
This version of TWiki - TWiki-4.1.2, Sat, 03 Mar 2007, build 13046 - predefines the following variables:
%ACTIVATEDPLUGINS%
%ALLVARIABLES%
AQUA
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%AQUA% aqua text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%ATTACHURL%
http://wiki.di.uminho.pt/twiki/pub/TWiki/VarATTACHURL
%ATTACHURL%/image.gif
%ATTACHURLPATH%
/twiki/pub/TWiki/VarATTACHURLPATH
%AUTHREALM%
%TOPIC%
if there is no INCLUDE
%BASETOPIC%
%WEB%
in case there is no include.
%BASEWEB%
BLACK
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%BLACK% black text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
BLUE
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%BLUE% blue text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
BROWN
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%BROWN% brown text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%DATE%
30 Oct 2020
%DISPLAYTIME%
30 Oct 2020 - 14:50
%GMTIME%
%DISPLAYTIME{"format"}%
%DISPLAYTIME{"$hou:$min"}%
expands to 14:50
"\n"
) and linefeed ("\r"
)
"<"
, ">"
, "&"
, single quote ('
) and double quote ("
)
"%"
, "["
, "]"
, "@"
, "_"
, "*"
, "="
and "|"
%ENCODE{"string"}%
Parameter: | Description: | Default: |
---|---|---|
"string" | String to encode | required (can be empty) |
type="entity" | Encode special characters into HTML entities, like a double quote into " . Does not encode \n or \r . | type="url" |
type="html" | As type="entity" except it also encodes \n and \r | type="url" |
type="quote" | Escape double quotes with backslashes (\" ), does not change other characters | type="url" |
type="url" | Encode special characters for URL parameter use, like a double quote into %22 | (this is the default) |
%ENCODE{"spaced name"}%
expands to spaced%20name
<input type="text" name="address" value="%ENCODE{ "any text" type="entity" }%" />
%SEARCH{ "%ENCODE{ "string with "quotes"" type="quotes" }%" noheader="on" }%
ENDCOLOR
is a rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%RED% red text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%ENDSECTION{"name"}%
%ENDSECTION{type="include"}%
Parameter: | Description: |
---|---|
"name" | Name of the section. |
type="..." | Type of the section being terminated; supported types "section" , "include" , "templateonly" . |
STARTSECTION
is named, the corresponding ENDSECTION
must also be named with the same name. If the STARTSECTION
specifies a type, then the corresponding ENDSECTION
must also specify the same type. If the section is unnamed, ENDSECTION
will match with the nearest unnamed %STARTSECTION%
of the same type above it.
%FAILEDPLUGINS%
%FORMFIELD{"fieldname"}%
Parameter: | Description: | Default: |
---|---|---|
"fieldname" | The name of a TWiki form field | required |
topic="..." | Topic where form data is located. May be of the form Web.TopicName | Current topic |
format="..." | Format string. $value expands to the field value, and $title expands to the field title | "$value" |
default="..." | Text shown when no value is defined for the field | "" |
alttext="..." | Text shown when field is not found in the form | "" |
%FORMFIELD{"ProjectName" topic="Projects.SushiProject" default="(not set)" alttext="ProjectName field found"}%
%GMTIME%
30 Oct 2020 - 14:50
%GMTIME{"format"}%
Variable: | Unit: | Example |
---|---|---|
$seconds | seconds | 59 |
$minutes | minutes | 59 |
$hours | hours | 23 |
$day | day of month | 31 |
$wday | day of the Week (Sun, Mon, Tue, Wed, Thu, Fri, Sat) | Thu |
$dow | day of the week (Sun = 0) | 2 |
$week | number of week in year (ISO 8601) | 34 |
$month | month in ISO format | Dec |
$mo | 2 digit month | 12 |
$year | 4 digit year | 1999 |
$ye | 2 digit year | 99 |
$tz | either "GMT" (if set to gmtime), or "Local" (if set to servertime) | GMT |
$iso | ISO format timestamp | 2020-10-30T14:50:02Z |
$rcs | RCS format timestamp | 2020/10/30 14:50:02 |
$http | E-mail & http format timestamp | Fri, 30 Oct 2020 14:50:02 GMT |
$epoch | Number of seconds since 00:00 on 1st January, 1970 | 1604069402 |
%GMTIME{"$day $month, $year - $hour:$min:$sec"}%
expands to 30 Oct, 2020 - 14:50:02
GRAY
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%GRAY% gray text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
GREEN
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%GREEN% green text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%GROUPS%
%HEADLINES{"url"}%
variable is handled by the HeadlinesPlugin.
%HEADLINES{ "http://..." }%
"..." | Source of RSS or ATOM feed; this can be a URL (starting with http) or a web.topic location for internal feeds |
refresh="60" | Refresh rate in minutes for caching feed; "0" for no caching |
limit="12" | Maximum number of items shown |
header="..." | Header. May include these variables: - $channeltitle , $title : title of channel (channel.title) - $channellink , $link : link of channel (channel.link) - $channeldescription , $description : description (channel.description) - $channeldate , $date : publication date of the channel (channel.pubDate) - $rights : copyrights of the channel (channel.copyright) - $imagetitle : title text for site (image.title) - $imagelink : link for site (image.link) - $imageurl : URL of image (image.url) - $imagedescription : description of image (image.description) |
format="..." | Format of one item. May include these variables: - $title : news item title (item.title) - $link : news item link (item.link) - $description : news item description (item.description) - $date : the publication date (item.pubDate, item.date) - $category : the article category (item.category) |
Details |
%HEADLINES{ "http://slashdot.org/slashdot.rdf" header="*[[$link][$title]]:* $description" format="$t* [[$link][$title]]" limit="4" }%
shows the latest Slashdot news in bullet list format
%HOMETOPIC%
WebHome
, renders as WebHome
%HTTP%
%HTTP{"Header-name"}%
%HTTP% | |
%HTTP{"Accept-language"}% | |
%HTTP{"User-Agent"}% | Wget/1.19.5 (linux-gnu) |
%HTTP_HOST%
wiki.di.uminho.pt
%HTTP%
but operates on the HTTPS environment variables present when the SSL protocol is in effect. Can be used to determine whether SSL is turned on.
%HTTPS%
%HTTPS{"Header-name"}%
%ICON{"name"}%
%ICON{"flag-gray"}%
returns %ICON{"pdf"}%
returns %ICON{"smile.pdf"}%
returns %ICON{"/dont/you/dare/smile.pdf"}%
returns %ICON{"http://twiki.org/doc/xhtml.xsl"}%
returns arrowbright
, bubble
, choice-yes
, hand
bmp
, doc
, gif
, hlp
, html
, mp3
, pdf
, ppt
, txt
, xls
, xml
, zip
%ICON{"name"}%
generates the full HTML img tag. Specify image name or full filename (see ICON for details on filenames.)
%ICONURL{"name"}%
%ICONURL{"arrowbright"}%
returns http://wiki.di.uminho.pt/twiki/pub/TWiki/TWikiDocGraphics/arrowbright.gif
%ICONURL{"novel.pdf"}%
returns http://wiki.di.uminho.pt/twiki/pub/TWiki/TWikiDocGraphics/pdf.gif
%ICONURL{"/queen/boheme.mp3"}%
returns http://wiki.di.uminho.pt/twiki/pub/TWiki/TWikiDocGraphics/mp3.gif
%ICONURLPATH{"name"}%
%ICONURLPATH{"locktopic"}%
returns /twiki/pub/TWiki/TWikiDocGraphics/locktopic.gif
%ICONURLPATH{"eggysmell.xml"}%
returns /twiki/pub/TWiki/TWikiDocGraphics/xml.gif
%ICONURLPATH{"/doc/xhtml.xsl"}%
returns /twiki/pub/TWiki/TWikiDocGraphics/xsl.gif
%IF{"CONDITION" then="THEN" else="ELSE"}%
shows "THEN"
if "CONDITION"
evaluates to TRUE
, otherwise "ELSE"
will be shown
%IF{"defined FUNFACTOR" then="FUNFACTOR is defined" else=" is not defined"}%
renders as ==
%INCLUDE{"page" ...}%
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:80/index.html"}% . Supported content types are text/html and text/plain . ![]() | |
pattern="..." | Include a subset of a topic or a web page. Specify a RegularExpression that scans from start ('^' ) to end and contains the text you want to keep in parenthesis, e.g., pattern="^.*?(from here.*?to here).*" . IncludeTopicsAndWebPages has more. | none |
rev="2" | Include a previous topic revision; N/A for URLs | top revision |
raw="on" | When a page is included, normally TWiki will process it, doing the following: 1) Alter relative links to point back to originating host, 2) Remove some basic HTML tags (html, head, body, script) and finally 3) Remove newlines from HTML tags spanning multiple lines. If you prefer to include exactly what is in the source of the originating page set this to on . raw="on" is short for disableremoveheaders="on" , disableremovescript="on" , disableremovebody="on" , disablecompresstags="on" and disablerewriteurls="on" . | disabled |
literal="on" | While using the raw option will indeed include the raw content, the included content will still be processed and rendered like regular topic content. To disable parsing of the included content, set the literal option to "on" . | disabled |
disableremoveheaders="on" | Bypass stripping headers from included HTML (everything until first </head> tag) | disabled |
disableremovescript="on" | Bypass stripping all <script> tags from included HTML | disabled |
disableremovebody="on" | Bypass stripping the </body> tag and everything around over and below it | disabled |
disablecompresstags="on" | Bypass replacing newlines in HTML tags with spaces. This compression step rewrites unmatched <'s into < entities unless bypassed | disabled |
disablerewriteurls="on" | Bypass rewriting relative URLs into absolute ones | disabled |
warn="off" | Warn if topic include fails: Fail silently (if off ); output default warning (if set to on ); else, output specific text (use $topic for topic name) | %INCLUDEWARNING% preferences setting |
section="name" | Includes only the specified named section, as defined in the included topic by the STARTSECTION and ENDSECTION variables. Nothing is shown if the named section does not exists. | |
PARONE="val 1" | Any other parameter will be defined as a variable within the scope of the included topic. The example parameters on the left will result in %PARONE% and %PARTWO% being defined within the included topic. |
disableremovescript
parameter)
%TOPIC%
in case there is no include
%INCLUDINGTOPIC%
%WEB%
if there is no INCLUDE.
%INCLUDINGWEB%
LANGUAGE
preference is set, it's used as user's language instead of any language detected from the browser.
LANGUAGE
at a non per-user way, so each user can choose his/her preferred language.
PO
files) to TWiki. Those are the languages in which TWiki's user interface is available.
%LANGUAGES{...}%
Parameter: | Description: | Default: |
---|---|---|
format | format for each item. See below for variables available in the format string. | " * $langname" |
separator | separator between items. | "\n" (newline) |
marker="selected" | Text for $marker if the item matches selection | "selected" |
selection="%LANGUAGE%" | Current language to be selected in list | (none) |
format
variables: Variable | Meaning |
---|---|
$langname | language's name, as informed by the translators |
$langtag | language's tag. Ex: en , pt-br , etc. |
<select>%LANGUAGES{format="<option $marker value='$langtag'>$langname</option>" selection="%LANGUAGE%"}%</select>
creates an option list of the available languages with the current language selected
LIME
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%LIME% lime text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%LOCALSITEPREFS%
Main.TWikiPreferences
, renders as TWikiPreferences
%LOGIN%
%LOGOUT%
%MAINWEB%
Main
%MAKETEXT{"string" args="..."}
Parameter | Description | Default |
---|---|---|
"text" or string="text" | The text to be displayed. | none |
args="param1, param2" | a comma-separated list of arguments to be interpolated in the string, replacing the [_N] placeholders in it. | none |
%MAKETEXT{string="Notes:"}%
%MAKETEXT{"If you have any questions, please contact [_1]." args="%WIKIWEBMASTER%"}%
%MAKETEXT{"Did you want to [[[_1]][reset [_2]'s password]]?" args="%TWIKIWEB%.ResetPassword,%WIKIUSERNAME%"}%
string
to the current user's language only if it has such string in its translation table for that language.
&
) followed by one letter (one of a...z, A...Z) (say, X
) in the translatable string will be translated to <span class='twikiAccessKey'>X</span>
. This is used to implement access keys. If you want to write an actual amperstand that stays just before a letter, write two consecutive amperstands (&&
): they will be transformed in just one.
_
) are reserved. You cannot use translatable phrases starting with an underscore.
%VARIABLES%
inside the translatable strings (since they will get expanded before the %MAKETEXT{...}%
itself is handled).
MAROON
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%MAROON% maroon text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
formfield
item is the most likely to be useful to casual users.
%META{ "item" ...}%
Item | Options | Description |
---|---|---|
"formfield" | name="..." : name of the field. The field value can be shortened as described in FormattedSearch for $formfield newline="..." : by default, each newline character will be rewritten to <br /> to allow metadata that contains newlines to be used in tables, etc. $n indicates a newline character. bar="..." : by default, each vertical bar is rewritten to an HTML entity so as to not be mistaken for a table separator. | Show a single form field |
"form" | none | Generates the table showing the form fields. See Form Templates |
"attachments" | all="on" to show hidden attachments. title="..." to show a title - only if attachments are displayed. template="..." to use a custom template for the rendering of attachments; default attachtables is used. | Generates the list of attachments |
"moved" | none | Details of any topic moves |
"parent" | dontrecurse="on" : By default recurses up tree, this has some cost. nowebhome="on" : Suppress WebHome. prefix="..." : Prefix that goes before parents, but only if there are parents, default "" . format="..." : Format string used to display each parent topic where $web expands to the web name, and $topic expands to the topic name; default: "[[$web.$topic][$topic]]" suffix="..." : Suffix, only appears if there are parents; default "" . separator="..." : Separator between parents; default " > " . | Generates the parent link |
%METASEARCH{...}%
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 "field" if searching for topics that have a particular form field value (use the name and value parameters to specify which field to search) | required |
web="%WEB%" | Wiki web to search: A web, a list of webs separated by whitespace, or all webs. | current web |
topic="%TOPIC%" | The topic the search relates to, for topicmoved and parent searches | current topic |
name | form field to search, for field type searches. May be a regular expression (see SEARCH). | |
value | form field value, for field type searches. May be a regular expression (see SEARCH). | |
title="Title" | Text that is prefixed to any search results | empty |
default="none" | Default text shown if no search hit | empty |
%METASEARCH{type="topicmoved" web="%WEB%" topic="%TOPIC%" title="This topic used to exist and was moved to: "}%
%METASEARCH{type="parent" web="%WEB%" topic="%TOPIC%" title="Children: "}%
%METASEARCH{type="field" name="Country" value="China"}%
NAVY
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%NAVY% navy text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%NOP%
%NOP{...}%
deprecated %STARTSECTION{type="templateonly"}%
.. %ENDSECTION{type="templateonly"}%
instead (see TWikiTemplates for more details).
%NOTIFYTOPIC%
WebNotify
, renders as WebNotify
OLIVE
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%OLIVE% olive text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
ORANGE
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%ORANGE% orange text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
PINK
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%PINK% pink text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%PLUGINDESCRIPTIONS%
"$SUM( $ABOVE() )"
to TWiki tables and other topic textExternalSite:Page
text to external sites based on aliases defined in a rules topic :-)
or
%PLUGINVERSION{"name"}%
to get the version of a specific plugin
%PLUGINVERSION{"InterwikiPlugin"}%
expands to $Rev: 11935$
%PLUGINVERSION%
to get the version of the API
1.11
%PUBURL%
http://wiki.di.uminho.pt/twiki/pub
%PUBURL%/%WEB%/OtherTopic/image.gif
%PUBURLPATH%
/twiki/pub
PURPLE
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%PURPLE% purple text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%QUERYPARAMS{...}%
format="..."
format string for each entry, default $name=$value
separator="..."
separator string, default separator="$n"
(newline)
Sequence: | Expands To: |
---|---|
$name | Name of the parameter |
$value | String value of the parameter. Multi-valued parameters will have a "row" for each value. |
$n or $n() | New line. Use $n() if followed by alphanumeric character, e.g. write Foo$n()Bar instead of Foo$nBar |
$nop or $nop() | Is a "no operation". |
$quot | Double quote (" ) |
$percnt | Percent sign (% ) |
$dollar | Dollar sign ($ ) |
%QUERYPARAMS{format="<input type='hidden' name='$name' value='$percntENCODE{$quot()$value$quot type=$quot()html$quot}$percnt' />"}%
%QUERYPARAMS%
.
%QUERYSTRING%
rev=45
RED
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%RED% red text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%REMOTE_ADDR%
192.168.85.246
%REMOTE_PORT%
37342
%REMOTE_USER%
%REVINFO%
r1 - 25 Jun 2006 - 16:26:29 - TWikiContributor
%REVINFO{"format"}%
Parameter: | Description: | Default: |
---|---|---|
"format" | Format of revision information, see supported variables below | "r1.$rev - $date - $wikiusername" |
web="..." | Name of web | Current web |
topic="..." | Topic name | Current topic |
rev="1.5" | Specific revison number | Latest revision |
Variable: | Unit: | Example |
---|---|---|
$web | Name of web | Current web |
$topic | Topic name | Current topic |
$rev | Revison number. Prefix r1. to get the usual r1.5 format | 5 |
$username | Login username of revision | jsmith |
$wikiname | WikiName of revision | JohnSmith |
$wikiusername | WikiName with Main web prefix | Main.JohnSmith |
$date | Revision date | 21 Sep 2006 |
$time | Revision time | 23:24:25 |
$iso | Revision date in ISO date format | 2006-09-22T06:24:25Z |
$min , $sec , etc. | Same date format qualifiers as GMTIME{"format"} |
%REVINFO{"$date - $wikiusername" rev="1.1"}%
returns revision info of first revision
viewauth.cgi
)
%SCRIPTNAME%
view
.pl
or .cgi
%SCRIPTSUFFIX%
%SCRIPTURL%
http://wiki.di.uminho.pt/twiki/bin
%SCRIPTURL{"script"}%
http://wiki.di.uminho.pt/twiki/bin/script
%SCRIPTURL{"viewauth"}%/%WEB%/%TOPIC%
which expands to http://wiki.di.uminho.pt/twiki/bin/viewauth/TWiki/TWikiVariables
%SCRIPTURLPATH{"script"}%
instead, as it works with URL rewriting much better
%SCRIPTURL%
, but doesn't include the protocol and host part of the URL
%SCRIPTURLPATH%
/twiki/bin
%SCRIPTURL{"script"}%
, but doesn't include the protocol and host part of the URL
%SCRIPTURLPATH{"script"}%
/twiki/bin/script
%SEARCH{"text" ...}%
Parameter: | Description: | Default: |
---|---|---|
"text" | Search term. Is a keyword search, literal search or regular expression search, depending on the type parameter. SearchHelp has more | required |
search="text" | (Alternative to above) | N/A |
web="Name" web="Main, Know" web="all" | Comma-separated list of webs to search. You can specifically exclude webs from an all search using a minus sign - for example, web="all,-Secretweb" . The special word all means all webs that do not have the NOSEARCHALL variable set to on in their WebPreferences. Note that TWikiAccessControls are respected when searching webs; it is much better to use them than NOSEARCHALL . | Current web |
topic="WebPreferences" topic="*Bug" | Limit search to topics: A topic, a topic with asterisk wildcards, or a list of topics separated by comma. Note this is a list of topic names and must not include web names. | All topics in a web |
excludetopic="Web*" excludetopic="WebHome, WebChanges" | Exclude topics from search: A topic, a topic with asterisk wildcards, or a list of topics separated by comma. Note this is a list of topic names and must not include web names. | None |
type="keyword" type="literal" type="regex" | Do a keyword search like soap "web service" -shampoo ; a literal search like web service ; or RegularExpression search like soap;web service;!shampoo | %SEARCHVAR- DEFAULTTYPE% preferences setting (literal) |
scope="topic" scope="text" scope="all" | Search topic name (title); the text (body) of topic; or all (both) | "text" |
order="topic" order="created" order="modified" order="editby" order= | Sort the results of search by the topic names, topic creation time, last modified time, last editor, or named field of TWikiForms. The sorting is done web by web; if you want to sort across webs, create a formatted table and sort it with TablePlugin's initsort. Note that dates are sorted most recent date last (i.e at the bottom of the table). | Sort by topic name |
limit="all" limit="16" | Limit the number of results returned. This is done after sorting if order is specified | All results |
date="..." | limits the results to those pages with latest edit time in the given TimeInterval. | All results |
reverse="on" | Reverse the direction of the search | Ascending search |
casesensitive="on" | Case sensitive search | Ignore case |
bookview="on" | BookView search, e.g. show complete topic text | Show topic summary |
nonoise="on" | Shorthand for nosummary="on" nosearch="on" nototal="on" zeroresults="off" noheader="on" noempty="on" | Off |
nosummary="on" | Show topic title only | Show topic summary |
nosearch="on" | Suppress search string | Show search string |
noheader="on" | Suppress default search header Topics: Changed: By: , unless a header is explicitly specified | Show default search header, unless search is inline and a format is specified (Cairo compatibility) |
nototal="on" | Do not show number of topics found | Show number |
zeroresults="off" | Suppress all output if there are no hits | zeroresults="on" , displays: "Number of topics: 0" |
noempty="on" | Suppress results for webs that have no hits. | Show webs with no hits |
header="..." format="..." | Custom format results: see FormattedSearch for usage, variables & examples | Results in table |
expandvariables="on" | Expand variables before applying a FormattedSearch on a search hit. Useful to show the expanded text, e.g. to show the result of a SpreadSheetPlugin %CALC{}% instead of the formula | Raw text |
multiple="on" | Multiple hits per topic. Each hit can be formatted. The last token is used in case of a regular expression ";" and search | Only one hit per topic |
nofinalnewline="on" | If on , the search variable does not end in a line by itself. Any text continuing immediately after the search variable on the same line will be rendered as part of the table generated by the search, if appropriate. | off |
recurse="on" | Recurse into subwebs, if subwebs are enabled. | off |
separator=", " | Line separator between search hits | "$n" (Newline) |
newline="%BR%" | Line separator within a search hit. Useful if the format="" parameter contains a $pattern() that captures more than one line, i.e. contents of a textfield in a form. | "$n" (Newline) |
%SEARCH{"wiki" web="Main" scope="topic"}%
%SEARCH{"FAQ" scope="topic" nosearch="on" nototal="on" header="| *Topic: * | *Summary: * |" format="| $topic | $summary |"%
(displays results in a table with header - details)
%TABLE{}%
variable just before the %SEARCH{}%
to alter the output of a search. Example: %TABLE{ tablewidth="90%" }%
%SERVERTIME%
30 Oct 2020 - 14:50
%GMTIME%
%SERVERTIME{"format"}%
%SERVERTIME{"$hou:$min"}%
expands to 14:50
%SESSIONID%
%SESSIONVAR%
%SESSION_VARIABLE{"name"}%
%SESSION_VARIABLE{"name" set="value"}%
%SESSION_VARIABLE{"name" clear=""}%
AUTHUSER
session variable, and is read-only
SILVER
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%SILVER% silver text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%SPACEDTOPIC%
Var%20*SPACEDTOPIC
%ENCODE{%SPACEOUT{"%TOPIC%" separator=" *"}%}%
%SPACEOUT{ "%TOPIC%" }%
TWiki Variables
Parameter: | Description: | Default: |
---|---|---|
separator | The separator to put between words e.g. %SPACEOUT{"DogsCatsBudgies" separator=", "}% -> Dogs, Cats, Budgies | ' ' |
[[WebHome][%SPACEOUT{"WebHome"}%]]
expands to Web Home
%STOPINCLUDE%
variable. A normal view of the topic shows everything exept the %STARTINCLUDE%
variable itself.
%STARTSECTION{type="include"}%
instead
%STARTINCLUDE%
%STARTSECTION{}%
and %ENDSECTION{}%
.
type="section"
- the default, used for a generic section, such as a named section used by INCLUDE.
type="include"
- like %STARTINCLUDE%
... %STOPINCLUDE%
except that you can have as many include blocks as you want (%STARTINCLUDE%
is restricted to only one).
type="templateonly"
- start position of text to be removed when a template topic is used. This is used to embed text that you do not want expanded when a new topic based on the template topic is created. See TWikiTemplates for more information.
%STARTSECTION{"name"}% ................ %ENDSECTION{"name"}%
%STARTSECTION{type="include"}% ........ %ENDSECTION{type="include"}%
%STARTSECTION{type="templateonly"}% ... %ENDSECTION{type="templateonly"}%
Parameter: | Description: | Default |
---|---|---|
"name" | Name of the section. Must be unique inside a topic. | Generated name |
type="..." | Type of the section; type "section" , "include" or "templateonly" | "section" |
_SECTION0
for the first unnamed section in the topic, _SECTION1
for the second, etc..
%STATISTICSTOPIC%
WebStatistics
, renders as WebStatistics
%STOPINCLUDE%
variable itself.
%STOPINCLUDE%
TEAL
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%TEAL% teal text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%TOC%
"---++ 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
%TOC{"SomeTopic" ...}%
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 |
title="Some text" | Title to appear at top of TOC | none |
%TOC{depth="2"}%
%TOC{"TWikiDocumentation" web="TWiki" title="Contents:"}%
%TOPIC%
expands to the name of the topic. If you are looking at the text of an included topic, it is the name of the included topic.
%TOPIC%
TWikiVariables
, renders as TWikiVariables
$name
variable gets expanded to the topic name, $qname
to double quoted name, $marker
to marker
parameter where topic matches selection
, and $web
to the name of the web.
%TOPICLIST{"format" ...}%
Parameter: | Description: | Default: |
---|---|---|
"format" | Format of one line, may include $web (name of web), $name (name of the topic), $qname (name of topic in double quotes), $marker (which expands to marker for the item matching selection only) | "$name" |
format="format" | (Alternative to above) | "$name" |
separator=", " | line separator | "$n" (new line) |
marker="selected" | Text for $marker if the item matches selection | "selected" |
selection="TopicA, TopicB" | Current value to be selected in list | (none) |
web="Name" | Name of web | Current web |
%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)
<select>%TOPICLIST{" <option $marker value='$name'>$name</option>" separator=" " selection="%TOPIC%"}%</select>
creates an option list of web topics with the current topic selected
%TWIKIWEB%
TWiki
%URLPARAM{"name"}%
Parameter: | Description: | Default: |
---|---|---|
"name" | The name of a URL parameter | required |
default="..." | Default value in case parameter is empty or missing | empty string |
newline="<br />" | Convert newlines in textarea to other delimiters | no conversion |
encode="entity" | Encode special characters into HTML entities. See ENCODE for more details. | no encoding |
encode="url" | Encode special characters for URL parameter use, like a double quote into %22 | no encoding |
encode="quote" | Escape double quotes with backslashes (\" ), does not change other characters; required when feeding URL parameters into other TWiki variables | no encoding |
multiple="on" multiple="[[$item]]" | If set, gets all selected elements of a <select multiple="multiple"> tag. A format can be specified, with $item indicating the element, e.g. multiple="Option: $item" | first element |
separator=", " | Separator between multiple selections. Only relevant if multiple is specified | "\n" (new line) |
%URLPARAM{"skin"}%
returns print
for a .../view/TWiki/TWikiVariables?skin=print
URL
%SEARCH{ "%URLPARAM{ "search" encode="quotes" }%" noheader="on" }%
%USERINFO%
guest, TWikiGuest,
(comma-separated list of the username, wikiusername, and emails)
$emails
, $username
, $wikiname
, $wikiusername
, and $groups
: %USERINFO{ format="$username is really $wikiname" }%
guest is really TWikiGuest
%USERINFO{ "TWikiGuest" format="$username is really $wikiname" }%
guest is really TWikiGuest
{AntiSpam}{HideUserDetails}
configuration option is not enabled, or if you are an admin. (User details are hidden in this TWiki)
jsmith
, WIKINAME like JohnSmith
and WIKIUSERNAME like Main.JohnSmith
. Un-authenticated users are all TWikiGuest.
%USERNAME%
guest
%VAR{"NAME" web="Web"}%
%WEBBGCOLOR%
of the Main web write %VAR{"WEBBGCOLOR" web="Main"}%
, which expands to #FFEFA6
%WEB%
expands to the name of the web where the topic is located. If you are looking at the text of an included topic, it is the web where the included topic is located.
%WEB%
TWiki
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
.
%WEBLIST{"format" ...}%
Parameter: | Description: | Default: |
---|---|---|
"format" | Format of one line, may include $name (the name of the web), $qname (the name of the web in double quotes), $indentedname (the name of the web with parent web names replaced by indents, for use in indented lists), and $marker (which expands to marker for the item matching selection only) | "$name" |
format="format" | (Alternative to above) | "$name" |
separator=", " | Line separator | "$n" (new line) |
webs="public" | Comma separated list of webs, public expands to all non-hidden.NOTE: Administrators will see all webs, not just the public ones | "public" |
marker="selected" | Text for $marker if the item matches selection | "selected" |
selection="%WEB%" | Current value to be selected in list | section="%WEB%" |
%WEBLIST{" * [[$name.WebHome]]"}%
creates a bullet list of all webs.
%WEBLIST{"<option $marker value=$qname>$name</option>" webs="Trash, public" selection="TWiki" separator=" "}%
creates a dropdown of all public webs + Trash web, with the current web highlighted.
%WEBPREFSTOPIC%
WebPreferences
, renders as WebPreferences
WHITE
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%WHITE% white text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
%WIKIHOMEURL%
/twiki/bin/view
%SCRIPTURLPATH{"view"}%
%WIKILOGOURL%
defined in WebPreferences instead.
%USERNAME%
if not defined in the TWikiUsers topic
%WIKINAME%
TWikiGuest
%WIKIPREFSTOPIC%
TWikiPreferences
, renders as TWikiPreferences
%WIKITOOLNAME%
TWiki
%WIKIUSERNAME%
Main.TWikiGuest
, renders as TWikiGuest
%WIKIUSERSTOPIC%
TWikiUsers
, with Main prefix renders as TWikiUsers
%WIKIVERSION%
TWiki-4.1.2, Sat, 03 Mar 2007, build 13046
YELLOW
is one of the rendering shortcut settings predefined in TWikiPreferences. See the section rendering shortcut settings in that topic for a complete list of colors.
%YELLOW% yellow text %ENDCOLOR%
%<color>%
text must end with %ENDCOLOR%
. If you want to switch from one color to another one you first need to end the active color with %ENDCOLOR%
, e.g. write %RED% some text %ENDCOLOR% %GREEN% more text %ENDCOLOR%
.
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.
File Attachments can be used to archive data, or to create powerful customized groupware solutions, like file sharing and document management systems, and quick Web page authoring.
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. *.php
files are renamed to *.php.txt
so that no one can place code that would be read in a .php file.
%ATTACHFILESIZELIMIT%
variable of the TWikiPreferences, currently set at 10000 KB.
An attachment can be moved between topics.
Manage
on the Attachment to be moved.
Move
. The attachment and its version history are moved. The original location is stored as topic Meta Data.
Move unwanted Attachments to web Trash
, topic TrashAttachment
.
Attach
file: Sample.txt
Edit
topic and enter: %ATTACHURL%/Sample.txt
Preview
: %ATTACHURL%/Sample.txt
text appears as: /twiki/pub/TWiki/FileAttachment/Sample.txt, a link to the text file.
%PUBURLPATH%/%WEB%/OtherTopic/Sample.txt
(if it's within the same web)
%PUBURLPATH%/Otherweb/OtherTopic/Sample.txt
(if it's in a different web)
Attach
file: Sample.txt
Edit
topic and write text: %INCLUDE{"%ATTACHURL%/Sample.txt"}%
Attach
file: Smile.gif
Edit
topic and write text: %ATTACHURL%/Smile.gif
Preview
: text appears as /twiki/pub/TWiki/FileAttachment/Smile.gif, an image.
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.
I | Attachment | Action | Size | Date | Who | Comment |
---|---|---|---|---|---|---|
![]() | Sample.txt | manage | 0.1 K | 22 Jul 2000 - 19:37 | TWikiContributor | Just a sample |
![]() | Smile.gif | manage | 0.1 K | 22 Jul 2000 - 19:38 | TWikiContributor | Smiley face |
Clicking on a Manage
link takes you to a new page that looks a bit like this (depending on what skin is selected):
Select a new local file to update attachment Sample.txt
(UploadingUser)
Upload up to 10000 KB.
h
means the attachment is hidden, it isn't listed when viewing a topic.
Hide file
checkbox, then click Change properties
.
Add structure to content with forms attached to twiki topics. TWiki forms (with form fields) and formatted search are the base for building database applications.
By adding form-based input to freeform content, you can structure topics with unlimited, easily searchable categories. A form is enabled for a web and can be added to a topic. The form data is shown in tabular format when the topic is viewed, and can be changed in edit mode using edit fields, radio buttons, check boxes and list boxes. Many different form types can be defined in a web, though a topic can only have only form attached to it at a time.
Typical steps to build an application based on TWiki forms:
YourForm
, ExpenseReportForm
, InfoCategoryForm
, RecordReviewForm
, whatever you need.
Name
, Type
, Size
, Values
, Tooltip message
, and Attributes
(see sample below).
Example:
| *Name* | *Type* | *Size* | *Values* | *Tooltip message* | *Attributes* |
| TopicClassification | select | 1 | NoDisclosure, PublicSupported, PublicFAQ | blah blah... | |
| OperatingSystem | checkbox | 3 | OsHPUX, OsLinux, OsSolaris, OsWin | blah blah... | |
| OsVersion | text | 16 | | blah blah... | |
Name Type Size Values Tooltip message Attributes TopicClassification select 1 NoDisclosure, PublicSupported, PublicFAQ blah blah... OperatingSystem checkbox 3 OsHPUX, OsLinux, OsSolaris, OsWin blah blah... OsVersion text 16 blah blah...
See structure of a form for full details of what types are available and what all the columns mean.
You can also retrieve possible values for select
, checkbox
or radio
types from other topics:
Example:
- In the WebForm topic, define the form:
Name Type Size Values Tooltip message Attributes TopicClassification select 1 blah blah... OperatingSystem checkbox 3 blah blah... OsVersion text 16 blah blah...
Leave the
Values
field blank.
- Then in the TopicClassification topic, define the possible values:
| *Name* |
| NoDisclosure |
| Public Supported |
| Public FAQ |
Name NoDisclosure Public Supported Public FAQ
Field values can also be obtained as the result of a FormattedSearch. For example,
%SEARCH{"Office$" scope="topic" web="%MAINWEB%" nonoise="on" type="regex" format="$web.$topic" separator=", " }%
when used in the value field of the form definition, this will find all topic names in the Main web which end in "Office" and use them as the legal field values.
Forms have to be enabled for each individual web. The WEBFORMS
variable in WebPreferences is optional and defines a list of possible form templates.
Example:
- Set WEBFORMS = BugForm, FeatureForm, Books.BookLoanForm
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.
SEARCH
to define WEBFORMS
.
WebTopicEditTemplate
topic in a web, or a new topic that serves as an application specific template topic. Initial Form values can be set there.
formtemplate
parameter in the (edit or save) URL. Initial values can then be provided in the URLs or as form values: name
, ex: ?BugPriority=1
namevalue=1
, ex: ?ColorRed=1
. <form name="newtopic" action="%SCRIPTURLPATH{"edit"}%/%WEB%/"> <input type="hidden" name="formtemplate" value="MyForm" /> New topic name <input type="text" name="topic" size="40" /> <input type="submit" class="twikiSubmit" value="Create" /> </form>
A Form Template specifies the fields in a form. A Form Template is simply a page containing a TWiki table, where each row of the table specifies one form field.
Each column of the table is one element of an entry field: Name
, Type
, Size
, Values
, Tooltip message
, and Attributes
.
The Name
, Type
and Size
columns are required. Other columns are optional. The form must have a header row (e.g. | *Name* | *Type* | *Size* |
).
Name
is the name of the form field.
The Type
, Size
and Value
fields describe the legal values for this field, and how to display them.
Type
checkbox
specifies one or more checkboxes. The Size
field specifies how many checkboxes will be displayed on each line. The Value
field should be a comma-separated list of item labels. Type
checkbox+buttons
will add Set and Clear buttons to the basic checkbox
type.
Type
radio
is like checkbox
except that radio buttons are mutually exclusive; only one can be selected.
Type
label
specifies read-only label text, The Value
field should contian the text of the label.
Type
select
specifies a select box. The Value
field should contain a comma-separated list of options for the box. The Size
field can specify a fixed size for the box (e.g. 1
, or a range e.g. 3..10
. If you specify a range, then the box will never be smaller than 3 items, never larger than 10, and will be 5 high if there are only 5 options. select
type: select+multi
turns multiselect on for the select, to allow Shift+Click and Ctrl+Click to select (or deselect) multiple items.
select+values
allows the definition of values that are different to the displayed text. For example: | Field 9 | select+values | 5 | One, Two=2, Three=III, Four | Various values formats |shows but the values or options
Two
and Three
are 2
and III
respectively.select+multi+values
Type
text
specifies a one-line text field. Size
specifies the text box width in number of characters. Value
is the initial (default) content when a new topic is created with this form template.
Type
textarea
specifies a multi-line text box. The Size
field should specify columns x rows, e.g. 80x6
; default size is 40x5. As for text
, the Value
field specifies the initial text
Type
date
specifies a single-line text box and a button next to it; clicking on the button will bring up a calendar from which the user can select a date. The date can also be typed into the text box. Size
specifies the text box width in characters. As for text
, the Value
field specifies the initial text
Tooltip message
is a message that will be displayed when the cursor is hovered over the field in edit
view.
Attributes
specifies special attributes for the field. Multiple attributes can be entered, separated by spaces.
H
indicates that this field should not be shown in view mode. However, the field is available for editing and storing information.
M
indicates that this field is mandatory. The topic cannot be saved unless a value is provided for this field. If the field is found empty during topic save, an error is raised and the user is redirected to an oops
page. Mandatory fields are indicated by an asterisks next to the field name.
For example, a simple form just supporting entry of a name and a date would look as follows:
| *Name* | *Type* | *Size* | | Name | text | 80 | | Date | date | 30 |Field Name Notes:
Aeroplane Manufacturers
is equivalent to AeroplaneManufacturers
.
label
field has no name, it will not be shown when the form is viewed, only when it is edited.
select
, checkbox
or radio
field, and want to get the values from another topic, you can use [[...]]
links. This notation can also be used when referencing another topic to obtain field values, but a name other than the topic name is required as the name of the field.
label
, text
, and textarea
fields the value may also contain commas. checkbox
fields cannot be initialized through the form template.
$quot
("), $percnt
(%), $dollar
($), $n
(newline), and $nop
can be used to prevent expansion.
| *Name* | *Type* | *Size* | | AeroplaneManufacturers | select | |the TWiki will look for the topic AeroplaneManufacturers to get the possible values for the
select
.
The AeroplaneManufacturers topic must contain a table, where each row of the table describes a possible value. The table only requires one column, Name
. Other columns may be present, but are ignored.
For example:
| *Name* | | Routan | | Focke-Wulf | | De Havilland |
Notes:
Values
column must be empty in the referring form definition.
checkbox
+multi
anywhere in the name
SubmitExpenseReport
topic where you can create new expense reports, a SubmitVacationRequest
topic, and so on. These can specify the required template topic with its associated form. Template topics has more.
FORMFIELD
, SEARCH
and METASEARCH
variables in TWikiVariables, and TWiki Formatted Search.
Example
TWiki users often want to have an overview of topics they contributed to. With the$formfield
parameter it is easy to display the value of a classification field next to the topic link:| *Topic* | *Classification* | %SEARCH{"%MAINWEB%.UserName" scope="text" nosearch="on" nototal="on" order="modified" reverse="on" format="|<b>[[$web.$topic][$topic]]</b> |<nop>$formfield(TopicClassification) |" web="Sandbox"}%
Searching forms this way is obviously pretty inefficient, but it's easy to do. If you want better performance, take a look at some of the structured wiki extensions that support higher performance searching e.g. TWiki:Plugins.DBCachePlugin.
text
fields when a topic is saved. If you need linefeeds in a field, make sure it is a textarea
.
Definition of the templates used to render all HTML pages displayed in TWiki
There are three types of template:
All three types of template use the TWiki template system.
Tip: TWiki:TWiki.TWikiTemplatesSupplement on TWiki.org has supplemental documentation on TWiki templates.
Templates are plain text with embedded template directives that tell TWiki how to compose blocks of text together to create something new.
%TMPL:<key>%
and %TMPL:<key>{"attr"}%
.
%TMPL:INCLUDE{"file"}%
: Includes a template file. The file is found as described below.
%TMPL:DEF{"block"}%
: Define a block. All text between this and the next %TMPL:END%
directive is removed and saved for later use with %TMPL:P
.
%TMPL:END%
: Ends a block definition.
%TMPL:P{"var"}%
: Includes a previously defined block.
%{...}%
: is a comment.
twiki.tmpl
master template, like twiki.print.tmpl
, that redefines the header and footer.
TMPL:P also supports simple parameters. For example, given the definition
%TMPL:DEF{"x"}% x%P%z%TMPL:END%
then %TMPL:P{"x" P="y"}%
will expand to xyz
.
Note that parameters can simply be ignored; for example=%TMPL:P{"x"}%= will expand to x%P%z.
Any alphanumeric characters can be used in parameter names. You are highly recommended to use parameter names that cannot be confused with TWikiVariables.
Note that three parameter names, context
, then
and else
are reserved. They are used to support a limited form of "if" condition that you can use to select which of two templates to use, based on a context identifier:
%TMPL:DEF{"link_inactive"}%<input type="button" disabled value="Link>%TMPL:END% %TMPL:DEF{"link_active"}%<input type="button" onclick="link()" value="Link" />%TMPL:END% %TMPL:P{context="inactive" then="inactive_link" else="active_link"}% for %CONTEXT%When the "inactive" context is set, then this will expand the "link_inactive" template; otherwise it will expand the "link_active" template. See IfStatements for details of supported context identifiers.
Templates are stored either in the twiki/templates
directory, or can also be read from user topics. As an example, twiki/templates/view.tmpl
is the default template file for the twiki/bin/view
script.
Templates that are included using %TMPL:INCLUDE%
are also found using the same search algorithm, unless you explicitly put '.tmpl'
at the end of the template name. In this case, the string is assumed to be the full name of a template in the templates
directory, and the algorithm isn't used.
TWiki uses the following search order to determine which template file or topic to use for a particular script. The skin path is set as described in TWikiSkins.
For example, theLegend:
- templates/web/script.skin.tmpl for each skin on the skin path
this usage is supported for compatibility only and is deprecated. Store web-specific templates in TWiki topics instead.
- templates/script.skin.tmpl for each skin on the skin path
- templates/web/script.tmpl
this usage is supported for compatibility only and is deprecated. Store web-specific templates in TWiki topics instead.
- templates/script.tmpl
- The TWiki topic aweb.atopic if the template name can be parsed into aweb.atopic
- The TWiki topic web.SkinSkinScriptTemplate for each skin on the skin path
- The TWiki topic web.ScriptTemplate
- The TWiki topic %TWIKIWEB%.SkinSkinScriptTemplate for each skin on the skin path
- The TWiki topic %TWIKIWEB%.ScriptTemplate
- script refers to the script name, e.g
view
,edit
- Script refers to the same, but with the first character capitalized, e.g
View
- skin refers to a skin name, e.g
dragon
,pattern
. All skins are checked at each stage, in the order they appear in the skin path.- Skin refers to the same, but with the first character capitalized, e.g
Dragon
- web refers to the current web
example
template file will be searched for in the following places, when the current web is Thisweb
and the skin path is print,pattern
: templates/Thisweb/example.print.tmpl
deprecated; don't rely on it
templates/Thisweb/example.pattern.tmpl
deprecated; don't rely on it
templates/example.print.tmpl
templates/example.pattern.tmpl
templates/Thisweb/example.tmpl
deprecated; don't rely on it
templates/example.tmpl
Thisweb.PrintSkinExampleTemplate
Thisweb.PatternSkinExampleTemplate
Thisweb.ExampleTemplate
TWiki.PrintSkinExampleTemplate
TWiki.PatternSkinExampleTemplate
TWiki.ExampleTemplate
Template names are usually derived from the name of the currently executing script; however it is also possible to override these settings in the view
and edit
scripts, for example when a topic-specific template is required. Two preference variables can be user to override the templates used:
VIEW_TEMPLATE
sets the template to be used for viewing a topic
EDIT_TEMPLATE
sets the template for editing a topic.
view
and edit
respectively. The template search order is as specified above.
If there is recusion in the TMPL:INCLUDE chain (eg twiki.classic.tmpl contains %TMPL:INCLUDE{"twiki"}%
, the templating system will include the next twiki.SKIN in the skin path.
For example, to create a customisation of pattern skin, where you only want to over-ride the breadcrumbs for the view script, you can create only a view.yourlocal.tmpl:
%TMPL:INCLUDE{"view"}% %TMPL:DEF{"breadcrumb"}% We don't want any crumbs %TMPL:END%and then set SKIN=yourlocal,pattern
%TMPL:DEF
and %TMPL:END%
) to define common sections that appear in two or more other templates. 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 are files of HTML mixed with template directives that tell TWiki how to build up an HTML page. As described above, the template system supports the use of 'include' directives that let you re-use the same sections of HTML - such as headers and footers - in several different places.
TWiki uses HTML page templates when composing the output from 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.
HTML page templates are also used in the definition of TWikiSkins.
Template topics define the default text for new topics. There are three types of template topic:
When you create a new topic, TWiki locates a topic to use as a content template according to the following search order:
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.
templatetopic
CGI parameter The following variables get expanded when a user creates a new topic based on a template topic:
Variable: Description: %DATE%
Signature format date. See VarDATE %GMTIME%
Date/time. See VarGMTIME %GMTIME{...}%
Formatted date/time. See VarGMTIME2 %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, such as %URLPA%NOP%RAM{...}%
escaping URLPARAM%STARTSECTION{type="templateonly"}%
...
%ENDSECTION{type="templateonly"}%Text that gets removed when a new topic based on the template is created. See notes below. %SERVERTIME%
Date/time. See VarSERVERTIME %SERVERTIME{...}%
Formatted date/time. See VarSERVERTIME2 %USERNAME%
Login name of user who is instantiating the new topic, e.g. guest %URLPARAM{"name"}%
Value of a named URL parameter %WIKINAME%
WikiName of user who is instantiating the new topic, e.g. TWikiGuest %WIKIUSERNAME%
User name of user who is instantiating the new tpoic, e.g. Main.TWikiGuest
%STARTSECTION{type="templateonly"}%
markers are used to embed text that you do not want expanded when a new topic based on the template topic is created. For example, you might want to write in the template topic:
...
%ENDSECTION{type="templateonly"}%
This template can only be changed by: * Set ALLOWTOPICCHANGE = %MAINWEB%.TWikiAdminGroupThis will restrict who can edit the template topic, but will get removed when a new topic based on that template topic is created.
%NOP%
can be used to prevent expansion of TWiki variables that would otherwise be expanded during topic creation e.g.i escape %nop>SERVERTIME%
with %SER%NOP%VERTIME%
.
All other variables are unchanged, e.g. are carried over "as is" into the new topic.
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}%/%WEB%/"> * New example topic: <input type="text" name="topic" value="ExampleTopic%SERVERTIME{$yearx$mox$day}%" size="26" /> <input type="hidden" name="templatetopic" value="ExampleTopicTemplate" /> <input type="hidden" name="topicparent" value="%TOPIC%" /> <input type="hidden" name="onlywikiname" value="on" /> <input type="hidden" name="onlynewtopic" value="on" /> <input type="submit" class="twikiSubmit" value="Create" /> (date format is <nop>YYYYxMMxDD) </form>
See TWikiScripts for details of the parameters that the edit
script understands.
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%
For TWiki application it is useful to automatically generate unique topicnames, such as BugID0001, BugID0002, etc. You can add AUTOINC<n>
to the topic name in the edit and save scripts, it gets replaced with an auto-incremented number on topic save. <n>
is a number starting from 0, and may include leading zeros. Leading zeros are used to zero-pad numbers so that auto-incremented topic names can sort properly. Deleted topics are not re-used to ensure uniqueness of topic names. That is, the auto-incremented number is always higher than the existing ones, even if there are gaps in the number sequence.
Examples:
BugAUTOINC0
- creates topic names Bug0
, Bug1
, Bug2
, ... (does not sort properly)
ItemAUTOINC0000
- creates topic names Item0000
, Item0001
, Item0002
, ... (sorts properly up to 9999)
DocIDAUTOINC10001
- start with DocID10001
, DocID10002
, ... (sorts properly up to 99999; auto-links)
Example link to create a new topic:
[[%SCRIPTURLPATH{"edit"}%/%WEB%/BugIDAUTOINC00000?templatetopic=BugTemplate&topicparent=%TOPIC%&t=%SERVERTIME{"$day$hour$min$sec"}%][Create new item]]=
Attached is an example of an oops based template oopsbase.tmpl
and an example oops dialog oopstest.tmpl
based on the base template. NOTE: This isn't the release version, just a quick, simple demo.
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="%SCRIPTURLPATH{"view"}%/%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>
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"}%
With URL: .../bin/oops/Sandbox/TestTopic2?template=oopstest¶m1=WebHome¶m2=WebNotify
Related Topics: TWikiSkins, DeveloperDocumentationCategory, AdminDocumentationCategory
Skins overlay regular templates to give different looks and feels to TWiki screens.
TWiki uses TWikiTemplates files as the basis of all the screens it uses to interact with users. Each screen has an associated template file that contains the basic layout of the screen. This is then filled in by the code to generate what you see in the browser.
TWiki ships with a default set of template files that give a basic look-and-feel. TWiki also includes support for skins that can be selected to give different, more sophisticated, look and feels. A default TWiki installation will usually start up with the PatternSkin already selected. Skins may also be defined by third parties and loaded into a TWiki installation to give more options. To see how TWiki looks when no skin is selected, view this topic with a non-existant skin.
Topic text is not affected by the choice of skin, though a skin can be defined to use a CSS (Cascading Style Sheet), which can sometimes give a radically different appearance to the text.
Relevant links on TWiki.org:
See other types of extensions: TWikiAddOns, TWikiContribs, TWikiPlugins
TWiki default ships with the skin PatternSkin activated. If you want to modify the layout, colors or even the templates to suit your own needs, have a look first at the topics PatternSkinCustomization and PatternSkinCssCookbook.
You may want to define your own skin, for example to comply with corporate web guidelines, or because you have a aesthetic vision that you want to share.
The TWikiTemplates files used for skins are located in the twiki/templates
directory and are named according to the skin: <scriptname>.<skin>.tmpl
. Skin files may also be defined in TWiki topics - see TWikiTemplates for details.
To start creating a new skin, copy the default TWikiTemplates (like view.tmpl
), or copy an existing skin to use as a base for your own skin. You should only need to copy the files you intend to customise, as TWiki can be configured to fall back to another skin if a template is not defined in your skin. Name the files as described above (for example view.myskin.tmpl
.
For your own TWiki skin you are encouraged to show a small 80x31 pixel logo at the bottom of your skin:
<a href="http://twiki.org/"><img src="%PUBURL%/%TWIKIWEB%/TWikiLogos/T-logo-80x15.gif" alt="This site is powered by the TWiki collaboration platform" width="80" height="15" title="This site is powered by the TWiki collaboration platform" border="0" /></a>
The standard TWiki skins show the logo in the %WEBCOPYRIGHT%
variable.
Note: Two skin names have reserved meanings;
text
skin, and skin names starting with rss
have hard-coded meanings.
The following template files are used for TWiki screens, and are referenced in the TWiki core code. If a skin doesn't define its own version of a template file, then TWiki will fall back to the next skin in the skin path, or finally, to the default version of the template file.
(Certain template files are expected to provide certain TMPL:DEFs - these are listed in sub-bullets)
addform
- used to select a new form for a topic
attachagain
- used when refreshing an existing attachment
attachnew
- used when attaching a new file to a topic
attachtables
- defines the format of attachments at the bottom of the standard topic view ATTACH:files:footer
, ATTACH:files:header
, ATTACH:files:row
, ATTACH:versions:footer
, ATTACH:versions:header
, ATTACH:versions:row
changeform
- used to change the form in a topic
changes
- used by the changes
script
edit
- used for the edit screen
form
formtables
- used to defined the format of forms FORM:display:footer
, FORM:display:header
, FORM:display:row
login
- used for loggin in when using the TemplateLoginManager LOG_IN
, LOG_IN_BANNER
, LOG_OUT
, LOGGED_IN_BANNER
, NEW_USER_NOTE
, UNRECOGNISED_USER
moveattachment
- used when moving an attachment
oopsaccessdenied
- used to format Access Denied messages no_such_topic
, no_such_web
, only_group
, topic_access
oopsattention
- used to format Attention messages already_exists
, bad_email
, bad_ver_code
, bad_wikiname
, base_web_missing
, confirm
, created_web
, delete_err
, invalid_web_color
, invalid_web_name
, in_a_group
, mandatory_field
, merge_notice
, missing_action
, missing_fields
, move_err
, missing_action
, no_form_def
, no_users_to_reset
, notwikiuser
, oversized_upload
, password_changed
, password_mismatch
, problem_adding
, remove_user_done
, rename_err
, rename_not_wikiword
, rename_topic_exists
, rename_web_err
, rename_web_exists
, rename_web_prerequisites
, reset_bad
, reset_ok
, save_error
, send_mail_error
, thanks
, topic_exists
, unrecognized_action
, upload_name_changed
, web_creation_error
, web_exists
, web_missing
, wrong_password
, zero_size_upload
oopschangelanguage
- used to prompt for a new language when internationalisation is enabled
oopsgeneric
- a basic dialog for user information; provides "ok" button only
oopslanguagechanged
- used to confirm a new language when internationalisation is enabled
oopsleaseconflict
- used to format lease Conflict messages lease_active
, lease_old
preview
- used for previewing edited topics before saving
rdiff
- used for viewing topic differences
registernotify
- used by the user registration system
registernotifyadmin
- used by the user registration system
rename
- used when renaming a topic
renameconfirm
- used when renaming a topic
renamedelete
- used when renaming a topic
renameweb
- used when renaming a web
renamewebconfirm
- used when renaming a web
renamewebdelete
- used when renaming a web
searchbookview
- used to format inline search results in book view
searchformat
- used to format inline search results
search
- used by the search
CGI script
settings
view
- used by the view
CGI script
viewprint
- used to create the printable view
twiki.tmpl
is a master template conventionally used by other templates, but not used directly by code.
Note: It is best to create these templates for your skin. If you
TMPL:INCLUDE
the default templates, or templates from other skins, when you are defining your own skin, you run the risk that the included file might change and break your skin.
You can use recusion in the TMPL:INCLUDE chain (eg twiki.classic.tmpl contains %TMPL:INCLUDE{"twiki"}%
, the templating system will include the next twiki.SKIN in the skin path.
For example, to create a customisation of pattern skin, where you only want to remove the edit & WYSIWYG buttons from view page, you create only a view.yourlocal.tmpl
:
%TMPL:INCLUDE{"view"}% %TMPL:DEF{"edit_topic_link"}%%TMPL:END% %TMPL:DEF{"edit_wysiwyg_link"}%%TMPL:END%and then set
SKIN=yourlocal,pattern
.
Because ClassicSkin and the default templates use the same Template definition names, you can over-ride the edit links in them (or any skin derived from them) using the same view.yourlocal.tmpl
(just set SKIN=yourlocal,classic either in TWikiPreferences for globally, or a Web's Webname.WebPreferences for a particular web)
You can use template variables, TWikiVariables, and other predefined variables to compose your skins. Some commonly used variables in skins:
Variable: | Expanded to: |
---|---|
%WEBLOGONAME% | Filename of web logo |
%WEBLOGOIMG% | Image URL of web logo |
%WEBLOGOURL% | Link of web logo |
%WEBLOGOALT% | Alt text of web logo |
%WIKILOGOURL% | Link of page logo |
%WIKILOGOIMG% | Image URL of page logo |
%WIKILOGOALT% | Alt text of page logo |
%WEBBGCOLOR% | Web-specific background color, defined in the WebPreferences |
%WIKITOOLNAME% | The name of your TWiki site |
%SCRIPTURL% | The script URL of TWiki |
%SCRIPTURLPATH% | The script URL path |
%SCRIPTSUFFIX% | The script suffix, ex: .pl , .cgi |
%WEB% | The name of the current web. |
%TOPIC% | The name of the current topic. |
%WEBTOPICLIST% | Common links of current web, defined in the WebPreferences. It includes a Go box |
%TEXT% | The topic text, e.g. the content that can be edited |
%META{"form"}% | TWikiForm, if any |
%META{"attachments"}% | FileAttachment table |
%META{"parent"}% | The topic parent |
%EDITTOPIC% | Edit link |
%REVTITLE% | The revision title, if any, ex: (r1.6) |
%REVINFO% | Revision info, ex: r1.6 - 24 Dec 2002 - 08:12 GMT - TWikiGuest |
%WEBCOPYRIGHT% | Copyright notice, defined in the WebPreferences |
%BROADCASTMESSAGE% | Broadcast message at the beginning of your view template, can be used to alert users of scheduled downtimes; can be set in TWikiPreferences |
The default skins include a "Go" box, also called "Jump" box, to jump to a topic.
The box also understands URLs, e.g. you can type http://www.google.com/
to jump to an external web site. The feature is handy if you build a skin that has a select box of frequently used links, like Intranet home, employee database, sales database and such. A little JavaScript gets into action on the onchange
method of the select tag to fill the selected URL into the "Go" box field, then submits the form.
Here is an example form that has a select box and the "Go" box for illustration purposes. You need to have JavaScript enabled for this to work:
Note: Redirect to a URL only works if it is enabled in configure
(Miscellaneous, {AllowRedirectUrl}
).
CSS files are gererally attachments to the skin topic that are included in the the skin templates - in the case of PatternSkin in the template styles.pattern.tmpl
.
<style type='text/css' media='all'>@import url('%PUBURLPATH%/%TWIKIWEB%/MySkin/mystyle.css');</style>
The format of standard attachment tables is defined through the use of special TWiki template macros which by default, are defined in the attachtables.tmpl
template using the %TMPL:DEF
macro syntax described in TWikiTemplates. These macros are:
Macro | Description |
---|---|
ATTACH:files:header | Standard title bar |
ATTACH:files:row | Standard row |
ATTACH:files:footer | Footer for all screens |
ATTACH:files:header:A | Title bar for upload screens, with attributes column |
ATTACH:files:row:A | Row for upload screen |
ATTACH:files:footer:A | Footer for all screens |
The format of tables of file versions in the Upload screen can also be changed, using the macros:
Macro | Description |
---|---|
ATTACH:versions:header | Header for versions table on upload screen |
ATTACH:versions:row | Row format for versions table on upload screen |
ATTACH:versions:footer | Footer for versions table on upload screen |
The ATTACH:row
macros are expanded for each file in the attachment table, using the following special tags:
Tag | Description |
---|---|
%A_URL% | URL that will recover the file |
%A_REV% | Revision of this file |
%A_ICON% | A file icon suitable for representing the attachment content |
%A_FILE% | The name of the file |
%A_SIZE% | The size of the file |
%A_DATE% | The date the file was uploaded |
%A_USER% | The user who uploaded it |
%A_COMMENT% | The comment they put in when uploading it |
%A_ATTRS% | The attributes of the file as seen on the upload screen e.g "h" for a hidden file |
See TWiki:Plugins/SkinPackagingHowTo and TWiki:Plugins/SkinDeveloperFAQ
You can try out all installed skins in the TWikiSkinBrowser.
TWiki uses a skin search path, which lets you combine skins additively. The skin path is defined using a combination of TWikiVariables and URL parameters.
TWiki works by asking for a template for a particular function - for example, 'view'. The detail of how templates are searched for is described in TWikiTemplates, but in summary, the templates directory is searched for a file called view.
skin.tmpl
, where skin is the name of the skin e.g. pattern
. If no template is found, then the fallback is to use view.tmpl
. Each skin on the path is searched for in turn. For example, if you have set the skin path to local,pattern
then view.local.tmpl
will be searched for first, then view.pattern.tmpl
and finally view.tmpl
.
The basic skin is defined by a SKIN
setting:
Set SKIN = catskin, bearskin
You can also add a parameter to the URL, such as ?skin=catskin,bearskin
:
Setting SKIN
(or the ?skin
parameter in the URL) replaces the existing skin path setting, for the current page only. You can also extend the existing skin path as well, using covers.
Set COVER = ruskin
This pushes a different skin to the front of the skin search path (so for our example above, that final skin path will be ruskin, catskin, bearskin
). There is also an equivalent cover
URL parameter. The difference between setting SKIN
vs. COVER
is that if the chosen template is not found (e.g., for included templates), SKIN
will fall back onto the next skin in line, or the default skin, if only one skin was present, while COVER
will always fall back onto the current skin.
An example would be invoking the printable mode, which is achieved by applying ?cover=print
. The view.print.tmpl
simply invokes the viewprint
template for the current skin which then can appropriately include all other used templates for the current skin. Where the printable mode be applied by using SKIN
, all skins would have the same printable appearance.
The full skin path is built up as follows: SKIN
setting (or ?skin
if it is set), then COVER
setting is added, then ?cover
.
The text
skin is reserved for TWiki internal use.
Skin names starting with rss
also have a special meaning; if one or more of the skins in the skin path starts with 'rss' then 8-bit characters will be encoded as XML entities in the output, and the content-type
header will be forced to text/xml
.
Related Topics: TWikiSkinBrowser, AdminDocumentationCategory, DeveloperDocumentationCategory, TWiki:TWiki.TWikiSkinsSupplement
-- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.MikeMannix, TWiki:Main.CrawfordCurrie
Inline search feature allows flexible formatting of search result
The default output format of a %SEARCH{...}%
is a table consisting of topic names and topic summaries. Use the format="..."
parameter to customize the search result. The format parameter typically defines a bullet or a table row containing variables, such as %SEARCH{ "food" format="| $topic | $summary |" }%
. See %SEARCH{...}%
for other search parameters, such as separator=""
.
Two parameters can be used to specify a customized search result:
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:* |"
Variables that can be used in the header string:
Name: | Expands To: |
---|---|
$web | Name of the web |
$n or $n() | New line. Use $n() if followed by alphanumeric character, e.g. write Foo$n()Bar instead of Foo$nBar |
$nop or $nop() | Is a "no operation". This variable gets removed; useful for nested search |
$quot | Double quote (" ). Alternatively write \" to escape it |
$percnt | Percent sign (% ) |
$dollar | Dollar sign ($ ) |
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:
Name: | Expands To: |
---|---|
$web | Name of the web |
$topic | Topic name |
$topic(20) | Topic name, "- " hyphenated each 20 characters |
$topic(30, -<br />) | Topic name, hyphenated each 30 characters with separator "-<br />" |
$topic(40, ...) | Topic name, shortended to 40 characters with "..." indication |
$parent | Name of parent topic; empty if not set |
$parent(20) | Name of parent topic, same hyphenation/shortening like $topic() |
$text | Formatted topic text. In case of a multiple="on" search, it is the line found for each search hit. |
$locked | LOCKED flag (if any) |
$date | Time stamp of last topic update, e.g. 30 Oct 2020 - 14:50 |
$isodate | Time stamp of last topic update, e.g. 2020-10-30T14:50Z |
$rev | Number of last topic revision, e.g. 4 |
$username | Login name of last topic update, e.g. jsmith |
$wikiname | Wiki user name of last topic update, e.g. JohnSmith |
$wikiusername | Wiki user name of last topic update, like Main.JohnSmith |
$createdate | Time stamp of topic revision 1 |
$createusername | Login name of topic revision 1, e.g. jsmith |
$createwikiname | Wiki user name of topic revision 1, e.g. JohnSmith |
$createwikiusername | Wiki user name of topic revision 1, e.g. Main.JohnSmith |
$summary | Topic summary, just the plain text, all formatting and line breaks removed; up to 162 characters |
$summary(50) | Topic summary, up to 50 characters shown |
$summary(showvarnames) | Topic summary, with %ALLTWIKI{...}% variables shown as ALLTWIKI{...} |
$summary(noheader) | Topic summary, with leading ---+ headers removedNote: The tokens can be combined, for example $summary(100, showvarnames, noheader) |
$changes | Summary of changes between latest rev and previous rev |
$changes(n) | Summary of changes between latest rev and rev n |
$formname | The name of the form attached to the topic; empty if none |
$formfield(name) | The field value of a form field; for example, $formfield(TopicClassification) would get expanded to PublicFAQ . This applies only to topics that have a TWikiForm |
$formfield(name, 10) | Form field value, "- " hyphenated each 10 characters |
$formfield(name, 20, -<br />) | Form field value, hyphenated each 20 characters with separator "-<br />" |
$formfield(name, 30, ...) | Form field value, shortended to 30 characters with "..." indication |
$pattern(reg-exp) | A regular expression pattern to extract some text from a topic (does not search meta data; use $formfield instead). In case of a multiple="on" search, the pattern is applied to the line found in each search hit.• Specify a RegularExpression that covers the whole text (topic or line), which typically starts with .* , and must end in .* • Put text you want to keep in parenthesis, like $pattern(.*?(from here.*?to here).*) • Example: $pattern(.*?\*.*?Email\:\s*([^\n\r]+).*) extracts the e-mail address from a bullet of format * Email: ... • This example has non-greedy .*? patterns to scan for the first occurance of the Email bullet; use greedy .* patterns to scan for the last occurance • Limitation: Do not use .*) inside the pattern, e.g. $pattern(.*foo(.*)bar.*) does not work, but $pattern(.*foo(.*?)bar.*) does • Note: Make sure that the integrity of a web page is not compromised; for example, if you include an HTML table make sure to include everything including the table end tag |
$count(reg-exp) | Count of number of times a regular expression pattern appears in the text of a topic (does not search meta data). Follows guidelines for use and limitations outlined above under $pattern(reg-exp) . Example: $count(.*?(---[+][+][+][+]) .*) counts the number of <H4> headers in a page. |
$n or $n() | New line. Use $n() if followed by alphanumeric character, e.g. write Foo$n()Bar instead of Foo$nBar |
$nop or $nop() | Is a "no operation". This variable gets removed; useful for nested search |
$quot | Double quote (" ). Alternatively write \" to escape it |
$percnt | Percent sign (% ) |
$dollar | Dollar sign ($ ) |
Here are some samples of formatted searches. The SearchPatternCookbook has other examples, such as creating a picklist of usernames, searching for topic children and more.
Write this:
%SEARCH{ "FAQ" scope="topic" nosearch="on" nototal="on" header=" * *Topic: Summary:*" format=" * [[$topic]]: $summary" }%
To get this:
In a web where there is a form that contains a TopicClassification
field, an OperatingSystem
field and an OsVersion
field we could write:
| *Topic:* | *OperatingSystem:* | *OsVersion:* |
%SEARCH{ "[T]opicClassification.*?value=\"[P]ublicFAQ\"" scope="text" type="regex" nosearch="on" nototal="on" format="| [[$topic]] | $formfield(OperatingSystem) | $formfield(OsVersion) |" }%
To get this:
Topic: | OperatingSystem: | OsVersion: |
---|---|---|
IncorrectDllVersionW32PTH10DLL | OsWin | 95/98 |
WinDoze95Crash | OsWin | 95 |
Write this:
%SEARCH{ "__Back to\:__ TWikiFAQ" scope="text" type="regex" nosearch="on" nototal="on" header="TWiki FAQs:" format=" * $pattern(.*?FAQ\:[\n\r]*([^\n\r]+).*) [[$topic][Answer...]]" }%
To get this:
TWiki FAQs:
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).
%SEARCH{ "culture" format=" * $topic is referenced by: (list all references)" nosearch="on" nototal="on" }%
%SEARCH{ "(topic found in first search)" format="$topic" nosearch="on" nototal="on" separator=", " }%
$percnt
to escape the leading percent of the second search
\"
to escape the double quotes
$dollar
to escape the $
of $topic
$nop
to escape the }%
sequence
Write this:
%SEARCH{ "culture" format=" * $topic is referenced by:$n * $percntSEARCH{ \"$topic\" format=\"$dollartopic\" nosearch=\"on\" nototal=\"on\" separator=\", \" }$nop%" nosearch="on" nototal="on" }%
To get this:
Note: Nested search can be slow, especially if you nest more then 3 times. Nesting is limited to 16 levels. For each new nesting level you need to "escape the escapes", e.g. write $dollarpercntSEARCH{
for level three, $dollardollarpercntSEARCH{
for level four, etc.
Write this:
%SEARCH{ "\.*" scope="topic" type="regex" nosearch="on" nototal="on" order="modified" reverse="on" format="| [[$topic]] | $wikiusername | $date |" limit="7" }%
To get this:
HeadlinesPlugin | TWikiContributor | 17 Jul 2011 - 22:41 |
VarHEADLINES | TWikiContributor | 09 Jul 2011 - 00:26 |
WysiwygPlugin | TWikiContributor | 16 Jan 2007 - 04:12 |
WikiReferences | TWikiContributor | 17 Nov 2006 - 06:10 |
WhatDoesTWikiStandFor | TWikiContributor | 16 Oct 2006 - 03:59 |
WikiWord | TWikiContributor | 04 Oct 2006 - 20:12 |
WelcomeGuest | TWikiContributor | 07 Mar 2006 - 18:10 |
A regular expression search is flexible, but there are limitations. For example, you cannot show all topics that are up to exactly one week old, or create a report that shows all records with invalid form fields or fields within a certain range, etc. You need some additional logic to format output based on a condition:
This requires the TWiki:Plugins.SpreadSheetPlugin. The following example shows all topics that are up to exactly one week old.
Write this:
%CALC{$SET(weekold, $TIMEADD($TIME(), -7, day))}%
%SEARCH{ "." scope="topic" type="regex" nosearch="on" nototal="on" order="modified" reverse="on" format="$percntCALC{$IF($TIME($date) < $GET(weekold), <nop>, | [[$topic]] | $wikiusername | $date | $rev |)}$percnt" limit="100" }%
weekold
variable to the serialized date of exactly one week ago
$percnt
makes sure that the CALC gets executed once for each search hit
weekold
date
<nop>
is returned, which gets removed at the end of the TWiki rendering process
To get this:
Use an HTML form and an embedded formatted search on the same topic. You can link them together with an %URLPARAM{"..."}%
variable. Example:
Write this:
<form action="%SCRIPTURLPATH{"view"}%/%WEB%/%TOPIC%"> Find Topics: <input type="text" name="q" size="32" value="%URLPARAM{"q"}%" /> <input type="submit" class="twikiSubmit" value="Search" /> </form> Result: %SEARCH{ search="%URLPARAM{"q"}%" format=" * $web.$topic: %BR% $summary" nosearch="on" }%
To get this:
Result:
Related Topics: UserDocumentationCategory, SearchHelp, TWikiVariables#VarSEARCH, SearchPatternCookbook, RegularExpression
-- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.CrawfordCurrie
Additional topic data, program-generated or from TWikiForms, is stored in META
variable name/value pairs
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:<type>{key1="value1" key2="value2" ...}%
name
, this appears first for easier searching (note the order of the variables themselves is defined).
\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="LastEditorWikiName" format="1.0"}% text of the topic %META:TOPICMOVED{from="Codev.OldName" to="Codev.NewName" by="TopicMoverWikiName" 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"}%
The current version of Meta Data is 1.0, with support for the following variables.
Key | Comment |
---|---|
version | Same as RCS version |
date | integer, unix time, seconds since start 1970 |
author | last to change topic, is the REMOTE_USER |
format | Format of this topic, will be used for automatic format conversion |
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"}%
Key | Comment |
---|---|
from | Full name, i.e., web.topic |
to | Full name, i.e., web.topic |
by | Who did it, is the REMOTE_USER, not WikiName |
date | integer, unix time, seconds since start 1970 |
Notes:
Key | Comment |
---|---|
name | The topic from which this was created, typically when clicking on a ? questionmark link, or by filling out a form. Normally just TopicName , but it can be a full Web.TopicName format if the parent is in a different Web. |
Key | Comment |
---|---|
name | Name of file, no path. Must be unique within topic |
version | Same as RCS revision |
path | Full path file was loaded from |
size | In bytes |
date | integer, unix time, seconds since start 1970 |
user | the REMOTE_USER, not WikiName |
comment | As supplied when file uploaded |
attr | h if hidden, optional |
Extra fields that are added if an attachment is moved:
Key | Comment |
---|---|
movedfrom | full topic name - web.topic |
movedby | the REMOTE_USER, not WikiName |
movedto | full topic name - web.topic |
moveddate | integer, unix time, seconds since start 1970 |
Key | Comment |
---|---|
name | A topic name - the topic represents one of the TWikiForms. Can optionally include the web name (i.e., web.topic), but doesn't normally |
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.
Key | Name |
---|---|
name | Ties to entry in TWikiForms template, is title with all bar alphanumerics and . removed |
title | Full text from TWikiForms template |
value | Value user has supplied via form |
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:
diff
function output appears in a logical order
The recommended sequence is:
META:TOPICINFO
META:TOPICPARENT
(optional)
META:TOPICMOVED
(optional)
META:FILEATTACHMENT
(0 or more entries)
META:FORM
(optional)
META:FIELD
(0 or more entries; FORM required)
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
Meta Data is rendered with the %META% variable. This is mostly used in the view
, preview
and edit
scripts.
You can render form fields in topic text by using the FORMFIELD variable. Example:
%FORMFIELD{"TopicClassification"}%
For details, see VarFORMFIELD.
Current support covers:
Variable usage: | Comment: |
---|---|
%META{"form"}% | Show form data, see TWikiForms. |
%META{"formfield"}% | Show form field value. Parameter: name="field_name" . Example:%META{ "formfield" name="TopicClassification" }% |
%META{"attachments"}% | Show attachments, except for hidden ones. Options: all="on" : Show all attachments, including hidden ones. |
%META{"moved"}% | Details of any topic moves. |
%META{"parent"}% | Show topic parent. Options: dontrecurse="on" : By default recurses up tree, at some cost. nowebhome="on" : Suppress WebHome. prefix="..." : Prefix for parents, only if there are parents, default "" . suffix="..." : Suffix, only appears if there are parents, default "" . separator="..." : Separator between parents, default is " > " . |
Note: SEARCH can also be used to render meta data, see examples in FormattedSearch and SearchPatternCookbook.
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.
Related Topics: DeveloperDocumentationCategory, UserDocumentationCategory
-- Contributors: TWiki:Main.JohnTalintyre, TWiki:Main.MikeMannix, TWiki:Main.PeterThoeny, TWiki:Main.CrawfordCurrie
Add functionality to TWiki with readily available Plugins; create Plugins based on APIs
You can add Plugins to extend TWiki functionality, without altering the core code. A plug-in approach lets you:
Everything to do with TWiki Plugins - demos, new releases, downloads, development, general discussion - is available at TWiki.org, in the TWiki:Plugins web.
TWiki Plugins are developed and contributed by interested members of the community. Plugins are provided on an 'as is' basis; they are not a part of TWiki, but are independently developed and maintained.
Relevant links on TWiki.org:
See other types of extensions: TWikiAddOns, TWikiContribs, TWikiSkins
Each TWiki Plugin comes with its own documentation: step-by-step installation instructions, a detailed description of any special requirements, version details, and a working example for testing. Many Plugins have an install script that automates these steps for you.
Special Requirements: Some Plugins need certain Perl modules to be preinstalled on the host system. Plugins may also use other resources, like graphics, other modules, applications, and templates. You should be able to find detailed instructions in the Plugin's documentation.
Each Plugin has a standard release topic, located in the TWiki:Plugins web at TWiki.org. There's usually a number of other related topics, such as a developers page, and an appraisal page.
The recommended approach to testing new Plugins before making them public is to create a second local TWiki installation, and test the Plugin there. You can allow selected users access to the test area. Once you are satisifed that it won't compromise your main installation, you can install it there as well.
InstalledPlugins shows which Plugins are: 1) installed, 2) loading properly, and 3) what TWiki:Codev.PluginHandlers they invoke. Any failures are shown in the Errors section. The %FAILEDPLUGINS%
variable can be used to debug failures. You may also want to check your webserver error log and the various TWiki log files.
The performance of the system depends to some extent on the number of Plugins installed and on the Plugin implementation. Some Plugins impose no measurable performance decrease, some do. For example, a Plugin might use many Perl libraries that need to be initialized with each page view (unless you run mod_perl). You can only really tell the performance impact by installing the Plugin and by measuring the performance with and without the new Plugin. Use the TWiki:Plugins.PluginBenchmarkAddOn, or test manually with the Apache ab
utility. Example on Unix:
time wget -qO /dev/null /twiki/bin/view/TWiki/AbcPlugin
If you need to install an "expensive" Plugin, but you only need its functionality only in a subset of your data, you can disable it elsewhere by defining the %DISABLEDPLUGINS% TWiki variable.
Define DISABLEDPLUGINS
to be a comma-separated list of names of plugins to disable. Define it in Main.TWikiPreferences to disable those plugins everywhere, in the WebPreferences topic to disable them in an individual web, or in a topic to disable them in that topic. For example,
* Set DISABLEDPLUGINS = SpreadSheetPlugin, EditTablePlugin
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:
Plugins can be enabled and disabled with the configure script. An installed Plugin needs to be enabled before it can be used.
By default, TWiki executes Plugins in alphabetical order on Plugin name. It is possible to change the order, for example to evaluate database variables before the speadsheet CALCs. This can be done with {PluginsOrder}
in the Plugins section of configure.
Plugins are usually configured by variables accessible though the configure interface, but in some cases (usually older plugins) TWiki preferences are used. If a TWiki variable is defined in a Plugin topic e.g:
%<pluginname>_<var>%
. For example, %RUBBERPLUGIN_SETTING%
shows the value of SETTING in the RubberPlugin topic.
Plugin status variables let you list all active Plugins wherever needed.
%ACTIVATEDPLUGINS%
%PLUGINDESCRIPTIONS%
"$SUM( $ABOVE() )"
to TWiki tables and other topic textExternalSite:Page
text to external sites based on aliases defined in a rules topic :-)
or
%FAILEDPLUGINS%
Plugin | Errors |
---|---|
SpreadSheetPlugin | none |
BreadCrumbsPlugin | none |
CommentPlugin | none |
EditTablePlugin | none |
FilterPlugin | none |
FlexWebListPlugin | none |
GluePlugin | none |
HeadlinesPlugin | none |
IfDefinedPlugin | none |
InterwikiPlugin | none |
NatSkinPlugin | none |
NewsPlugin | none |
PreferencesPlugin | none |
SlideShowPlugin | none |
SmiliesPlugin | none |
TablePlugin | none |
TwistyPlugin | none |
Handler | Plugins |
---|---|
beforeCommonTagsHandler | PreferencesPlugin TwistyPlugin |
beforeSaveHandler | CommentPlugin NewsPlugin |
commonTagsHandler | SpreadSheetPlugin CommentPlugin EditTablePlugin FilterPlugin GluePlugin HeadlinesPlugin IfDefinedPlugin NatSkinPlugin SlideShowPlugin SmiliesPlugin |
initPlugin | SpreadSheetPlugin BreadCrumbsPlugin CommentPlugin EditTablePlugin FilterPlugin FlexWebListPlugin GluePlugin HeadlinesPlugin IfDefinedPlugin InterwikiPlugin NatSkinPlugin NewsPlugin PreferencesPlugin SlideShowPlugin SmiliesPlugin TablePlugin TwistyPlugin |
postRenderingHandler | EditTablePlugin NatSkinPlugin PreferencesPlugin TwistyPlugin |
preRenderingHandler | InterwikiPlugin SmiliesPlugin TablePlugin |
The Application Programming Interface (API) for TWiki Plugins provides the specifications for hooking into the core TWiki code from your external Perl Plugin module.
The TWikiFuncDotPm module (lib/TWiki/Func.pm
) describes all the interfaces available to Plugins. Plugins should only use the interfaces described in this module.
Note: If you use other core functions not described in
Func.pm
, you run the risk of creating security holes. Also, your Plugin will likely break and require updating when you upgrade to a new version of TWiki.
In addition to TWiki core functions, Plugins can use predefined hooks, or callbacks, as described in the lib/TWiki/Plugins/EmptyPlugin.pm
module.
DISABLE_
from the function name.
TWiki:Codev/StepByStepRenderingOrder helps you decide which rendering handler to use.
eval
block like this:eval { require IPC::Run }
return "<font color=\"red\">SamplePlugin: Can't load required modules ($@)</font>" if $@;
To eliminate the incompatibility problems bound to arise from active open Plugin development, a Plugin versioning system is provided for automatic compatibility checking.
$VERSION='0.000'
variable, beginning at 1.000
.
initPlugin
handler should check all dependencies and return TRUE if the initialization is OK or FALSE if something went wrong. initPlugin
handler).
$TWiki::Plugins::VERSION
in the TWiki::Plugins
module contains the TWiki Plugin API version, currently 1.11. %PLUGINVERSION{}%
variable to query the Plugin API version or the version of installed Plugins.
%TWiki::cfg
hash than adding it as preferences in the Plugin topic 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.
A basic TWiki Plugin consists of two elements:
MyFirstPlugin.pm
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.
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();
A high quality Plugin performs well. You can use the TWiki:Plugins.PluginBenchmarkAddOn to measure your TWiki:Plugins.PluginBenchmarks. The data is needed as part of the Documentation Topic.
See also Hints on Writing Fast Plugins.
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:
MyFirstPlugin
, press enter and create the new topic
OUTLINE: Doc Topic Contents
Check the Plugins web on TWiki.org for the latest Plugin doc topic template. Here's a quick overview of what's covered:Syntax Rules: <Describe any special text formatting that will be rendered.>"
Example: <Include an example of the Plugin in action. Possibly include a static HTML version of the example to compare if the installation was a success!>"
Plugin Settings: <Description and settings for custom Plugin %VARIABLES%, and those required by TWiki.>"
- 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.>"
The TWiki:Plugins.BuildContrib is a powerful build environment that is used by the TWiki project to build TWiki itself, as well as many of the Plugins. You don't have to use it, but it is highly recommended!
If you don't want (or can't) use the BuildContrib, then a minimum Plugin release consists of a Perl module with a WikiName that ends in Plugin
, ex: MyFirstPlugin.pm
, and a documentation page with the same name(MyFirstPlugin.txt
).
lib/TWiki/Plugins/MyFirstPlugin.pm
data/TWiki/MyFirstPlugin.txt
pub/TWiki/MyFirstPlugin/uparrow.gif
[a required graphic]
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
You can release your tested, packaged Plugin to the TWiki community through the TWiki:Plugins web. All Plugins submitted to TWiki.org are available for download and further development in TWiki:Plugins/PluginPackage.
Publish your Plugin by following these steps:
MyFirstPlugin
MyFirstPlugin.zip
Dev
, ex: MyFirstPluginDev
. This is the discussion page for future development. (User support for Plugins is handled in TWiki:Support.)
Once you have done the above steps once, you can use the BuildContrib to upload updates to your Plugin.
Thank you very much for sharing your Plugin with the TWiki community
Plugins sometimes need to store data. This can be Plugin internal data such as cache data, or data generated for browser consumption such as images. Plugins should store data using TWikiFuncDotPm functions that support saving and loading of topics and attachments.
You can create a Plugin "work area" using the TWiki::Func::getWorkArea()
function, which gives you a persistant directory where you can store data files. By default they will not be web accessible. The directory is guaranteed to exist, and to be writable by the webserver user. For convenience, TWiki::Func::storeFile()
and TWiki::Func::readFile()
are provided to persistently store and retrieve simple data in this area.
Topic-specific data such as generated images can be stored in the topic's attachment area, which is web accessible. Use the TWiki::Func::saveAttachment()
function to store the data.
Recommendation for file name:
_FooBarPlugin_img123.gif
Web specific data can be stored in the Plugin's attachment area, which is web accessible. Use the TWiki::Func::saveAttachment()
function to store the data.
Recommendation for file names in Plugin attachment area:
_Main_roundedge-ul.gif
Each published Plugin has a Plugin development topic on TWiki.org. Plugin development topics are named after your Plugin and end in Dev
, such as MyFirstPluginDev
. The Plugin development topic is a great resource to discuss feature enhancements and to get feedback from the TWiki community.
The Plugin interface (TWikiFuncDotPm functions and handlers) evolve over time. TWiki 4.0 introduced new API functions to address the needs of Plugin authors. It also deprecated some functions. Some Plugins written for earlier TWiki releases using unofficial TWiki internal functions no longer work on the TWiki 4.0 codebase. All this means that some Plugins need to be updated to work on the TWiki 4.0 codebase.
Organizations typically do not upgrade to the latest TWiki for many months. However, many administrators still would like to install the latest versions of a Plugin on their older TWiki installation. This need is fullfilled if Plugins are maintained in a compatible manner.
Tip: Plugins can be written to be compatible with older and newer TWiki releases. This can be done also for Plugins using unofficial TWiki internal functions of an earlier release that no longer work on the latest TWiki codebase. TWiki:TWiki.TWikiPluginsSupplement#MaintainPlugins has more.
From time-to-time, the TWiki developers will add new functions to the interface (either to TWikiFuncDotPm, or new handlers). Sometimes these improvements mean that old functions have to be deprecated to keep the code manageable. When this happens, the deprecated functions will be supported in the interface for at least one more TWiki release, and probably longer, though this cannot be guaranteed.
When a plugin defines deprecated handlers, a warning will be shown in the list generated by %FAILEDPLUGINS%. Admins who see these warnings should check TWiki.org and if necessary, contact the plugin author, for an updated version of the plugin.
Updated plugins may still need to define deprecated handlers for compatibility with old TWiki versions. In this case, the plugin package that defines old handlers can suppress the warnings in %FAILEDPLUGINS%.
This is done by defining a map from the handler name to the TWiki::Plugins
version in which the handler was first deprecated. For example, if we need to define the endRenderingHandler
for compatibility with TWiki::Plugins
versions before 1.1, we would add this to the plugin:
package TWiki::Plugins::SinkPlugin; use vars qw( %TWikiCompatibility ); $TWikiCompatibility{endRenderingHandler} = 1.1;If the currently-running TWiki version is 1.1 or later, then the handler will not be called and the warning will not be issued. TWiki with versions of
TWiki::Plugins
before 1.1 will still call the handler as required.
Warning: Can't find topic TWiki.TWikiFuncModule
Utilities for searching, navigation, and monitoring site activity
TWiki Site Tools 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 e-mail alerts when topics are edited, and WebStatistics, to generate detailed activity reports.
Each TWiki web has an automatic e-mail 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 e-mail to subscribed users if topics were changed in a web since the script was last run.
%NOTIFYTOPIC%
Each TWiki web has an automatic e-mail notification service that sends you an e-mail with links to all of the topics modified since the last alert.
Users subscribe to email notifications using their WikiName or an alternative email address, and can specify the webs/topics they wish to track using one of these bullet list formats:
three spaces * [ webname . ] wikiName - SMTP mail address
three spaces * [ webName . ] wikiName
three spaces * SMTP mail address
three spaces * SMTP mail address : topics
three spaces * [ webname . ] wikiName : topics
In the above examples, topics is a space-separated list of topic names. The user may further customize the specific content they will receive using the following formats:
For example: Subscribe Daisy to all changes to topics in this web.
* daisy.cutter@flowers.comSubscribe Daisy to all changes in all webs that start with
Web
.
* daisy.cutter@flowers.com: Web*Subscribe Daisy to changes to topics starting with
Petal
, and their immediate children, WeedKillers and children to a depth of 3, and all topics that match start with Pretty
and end with Flowers
e.g. PrettyPinkFlowers
* DaisyCutter: Petal* (1) WeedKillers (3) Pretty*FlowersSubscribe StarTrekFan to changes to all topics that start with
Star
except those that end in Wars
, sInTheirEyes
or shipTroopers
.
* StarTrekFan: Star* - *Wars - *sInTheirEyes - *shipTroopersSubscribe Daisy to the full content of NewsLetter whenever it has changed
* daisy@flowers.com: NewsLetter?Subscribe buttercup to NewsLetter and its immediate children, even if it hasn't changed.
* buttercup@flowers.com: NewsLetter! (1)Subscribe GardenGroup (which includes Petunia) to all changed topics under AllnewsLetters to a depth of 3. Then unsubscribe Petunia from the ManureNewsLetter, which she would normally get as a member of GardenGroup? :
* GardenGroup: AllNewsLetters? (3) * petunia@flowers.com: - ManureNewsLetterA user may be listed many times in the WebNotify topic. Where a user has several lines in WebNotify that all match the same topic, they will only be notified about changes that topic once (though they will still receive individual mails for news topics).
If a TWiki group is listed for notification, the group will be recursively expanded to the e-mail addresses of all members.
Tip: List names in alphabetical order to make it easier to find the names.
Note for System Administrators: Notification is supported by an add-on to the TWiki kernel called the MailerContrib. See the MailerContrib topic for details of how to set up this service.
Note: If you prefer a news feed, point your reader to WebRss (for RSS 1.0 feeds) or WebAtom (for ATOM 1.0 feeds). Learn more at WebRssBase and WebAtomBase, respectively.
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 configure.
WebSearch is an extremely fast and flexible search facility, part of the core TWiki feature set. WebSearchAdvanced offers more options, including:
See also: SearchHelp for help; TWikiVariables and FormattedSearch for including hard-coded searches in text.
To check for the most recently edited topics while on-site, use the WebChanges link, usually located in the 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" type="regex" nosearch="on" order="modified"
reverse="on" limit="50" }%
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" type="regex" nosearch="on" }%
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.
%STATISTICSTOPIC%
twiki/bin/statistics
script from a cron job, once a day is recommended. This will update the WebStatistics topics in all webs.
nobody
on many systems. Example crontab entry: 0 0 * * * (cd /path/to/twiki/bin; ./statistics >/dev/null 2>&1)
nobody
: Run the utility twiki/tools/geturl.pl
in your cron job and specify the URL of the twiki/bin/statistics
script as a parameter. Example: 0 0 * * * (cd /path/to/twiki/tools; ./geturl.pl mydomain.com /urlpath/to/twiki/bin/statistics >/dev/null 2>&1)
When running from the command line or a cron job, you can pass parameters to the script like this:
./statistics -logdate 200605 -webs TWiki,Sandbox
twiki/bin/statistics
script can also be executed as a CGI script, just enter the URL in your browser. Examples: /twiki/bin/statistics
/twiki/bin/statistics/Main
/twiki/bin/statistics/Main?logdate=202010
/twiki/bin/statistics?logdate=202010;webs=ProjectX,ProjectY,ProjectZ
TWiki generates monthly log files which are used by the statistics script
log<year><month>.txt
twiki/logs/log202010.txt
| <time> | <wikiusername> | <action> | <web>.<topic> | <extra info> | <IP address> |
| 30 Oct 2020 - 14:50 | TWikiGuest | view | WebRss | | 66.124.232.02 |
Script | Action name | Extra info |
---|---|---|
attach | attach | when viewing attach screen of previous uploaded attachment: filename |
changes | changes | |
edit | edit | when editing non-existing topic: (not exist) |
rdiff | rdiff | higher and lower revision numbers: 4 3 |
register | regstart | WikiUserName, e-Mail address, LoginName: user attempts to register |
register | register | E-mail address: user successfully registers |
register | bulkregister | WikiUserName of new, e-mail address, admin ID |
rename | rename | when moving topic: moved to Newweb.NewTopic |
rename | move | when moving attachment: Attachment filename moved to Newweb.NewTopic |
passwd | resetpasswd | LoginName, WikiName, E-mail address, success code from addUserPassword |
passwd | changepasswd | LoginName, WikiName |
save | save | when replacing existing revision: repRev 3 when user checks the minor changes box: dontNotify when user changes attributes to an exising attachment: filename.ext |
save | cmd | special admin parameter used when saving |
search | search | search string |
upload | upload | filename |
view | view | when viewing non-existing topic: (not exist) when viewing previous topic revision: r3 |
Outgoing mail is required for TWikiRegistration and for recent changes alert.
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, such as sendmail
, if the Net::SMTP
module is not installed. Set the program path in {MailProgram}
in configure.
SMTPMAILHOST
in TWikiPreferences to an empty value.
SMTPSENDERHOST
variable to define the mail sender host (some SMTP installations require this).
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 0 2 * * * (cd /path/to/twiki/bin; ./mailnotify -q)The above line will run mailnotify nightly at 02:00. The
-q
switch suppresses all normal output.
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: You can use a scheduled task if you have administrative privileges. TWiki:Codev/CronTabWin is a free scheduler for Windows.
Related Topics: AdminDocumentationCategory, AdminToolsCategory
Browser-based rename, move, and delete for individual topics
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.
[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:
Trash
to delete a topic.
[Rename/Move]
: the topic will be renamed and links to the topic updated as requested. [Rename/Move]
.
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 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.
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.
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: "}%
<pre>
and <verbatim>
are honoured - no changes are made to text within these areas.
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
. All webs will be searched during rename, even if NOSEARCHALL
is defined on a web, though access permissions will of course be honoured.
Changed references are kept are as short as possible, ex: topic
is used in preference to web.topic
.
User permissions affect the Rename function in various ways. To rename a topic, you need both ALLOWTOPICVIEW
and ALLOWTOPICCHANGE
permission for that topic. To alter referring topics, you need change permission. See TWikiAccessControl for information on setting up access permissions.
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:
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.
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]]
Related Topics: UserDocumentationCategory, AdminDocumentationCategory
Adding, renaming and deleting webs are all web-based operations.
A TWikiSite is divided into webs; each one represents one subject, one area of collaboration. Administrators (in the TWikiAdminGroup) can add/rename/delete webs.
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 (for example _default
). All topics in the 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 would 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.
Notes:
ROOTCHANGE
access to create a top-level web (one with no parent)
WEBBGCOLOR
, SITEMAPLIST
, SITEMAPWHAT
, SITEMAPUSETO
and NOSEARCHALL
. These variables are used to dynamically generate the SiteMap
WIKIWEBLIST
. This must be done by hand
Rename a web via the Tools section in each web's WebPreferences topic. You may delete a web by moving it into a Trash web.
You may only rename a web if you have permissions to rename all the topics within that web, including any topics in that web's subwebs. You will also need permissions to update any topics containing references to that web.
If anyone is editing a topic which requires updating, or which lives in the web being renamed, a second confirmation screen will come up which will indicate which topics are still locked for edit. You may continue to hit the refresh button until an edit lease is obtained for each topic which requires updating (the "Refresh" button will change to "Submit"), or hit "Cancel", which will cancel your edit lease on all affected topics.
If you plan to rename the Main web, remember that TWiki stores user and group topics in this web. That means that every WikiName signature - Main.SomeUserName
- points to it and would need updating (unless the variable, %MAINWEB%.SomeUserName
, is used throughout). This potentially large change can be performed automatically if you rename the web from the Tools section of WebPreferences, as described above.
If you want to rename the TWiki or Main webs, remember they are referred to in the TWiki configuration. You will need to change the
{SystemWebName}
, {UsersWebName}
and/or {LocalSitePreferences}
settings in the configuration using the configure interface.
Hierarchical web support is enabled by turning on the {EnableHierarchicalWebs}
setting in configure. Without this setting, TWiki will only allow a single level of hierarchy (webs). If you set this, you can use multiple levels, like a directory tree, i.e. webs within webs.
Note: You might not need hierarchical webs. TWiki topics already have a parent/child relationship within a web, which is shown in the breadcrumb. Try to keep the number of webs to a minimum in order to keep search and cross-referencing simple.
You can create hierarchical webs via the Adding a New Web form above, by using a slash- or dot-separated path name which is based on an existing web name in the Name of new web: field.
Example:
To create a subweb named Bar
inside a web named Foo
, use Foo/Bar
or Foo.Bar
as the new web name in the form above.
The preferences of a subweb are inherited from the parent web and overridden locally. Preferences are ultimately inherited from the TWiki.TWikiPreferences topic.
Example Preference Inheritance for Sandbox/TestWeb/SubWeb.SubWebTopic
topic:
TWiki.TWikiPreferences
site-wide preferences
Sandbox.WebPreferences
inherits from and overrides settings in TWiki.TWikiPreferences
Sandbox/TestWeb.WebPreferences
inherits from and overrides settings in Sandbox.WebPreferences
Sandbox/TestWeb/SubWeb.WebPreferences
inherits from and overrides settings in Sandbox/TestWeb.WebPreferences
Sandbox/TestWeb/SubWeb.SubWebTopic
inherits from and overrides settings in Sandbox/TestWeb/SubWeb.WebPreferences
The Pattern skin (default) indicates Subwebs by indenting them in the sidebar relative to their level in the hierarchy.
Related Topics: AdminDocumentationCategory, AdminToolsCategory
Warning: Can't find topic TWiki.AppendixFileSystem
Listing of CSS class names emitted from TWiki core code and standard plugins, for the Dakar release.
Most html elements generated by TWiki core code now have Cascading Style Sheet (CSS) tags. Skin builders and others who want to change the appearance of the default TWiki installation or any of the skins can use this document to see what styles can be created for these html elements.
twiki
. So: twikiAlert, twikiToc, etcetera. Remember that CSS class names are case sensitive - TWiki CSS uses lowercase tw
.
twiki
prefix to prevent undesired overriding effects.
A wide range of standard styles are used in the TWiki core code and topics, and more are used in plugins. The following is an exhaustive list of all styles defined by the Pattern skin. For the most part, the names are the only documentation of the purpose of the style. For more information on how these styles are used, read the code (sorry!)
.twikiAlert | Client.pm, Form.pm, Statistics.pm |
.twikiFirstCol | Render.pm |
.twikiForm | Render.pm |
.twikiNew | Changes.pm, Search.pm |
.twikiHelp | Changes.pm |
.twikiTopRow | Manage.pm |
.twikiSummary | Manage.pm |
.twikiGrayText | Manage.pm |
.twikiCheckBox | Manage.pm |
.twikiLink | Render.pm |
.twikiNewLink | Render.pm |
.twikiAnchorLink | Render.pm |
.twikiCurrentWebHomeLink | Render.pm |
.twikiCurrentTopicLink | Render.pm |
.twikiEmulatedLink | Preview.pm |
.twikiWebIndent | TWiki.pm |
.twikiEditFormDateField | Form.pm |
.twikiEditFormTextField | Form.pm |
.twikiEditFormLabelField | Form.pm |
.twikiEditFormTextAreaField | Form.pm |
.twikiEditFormCheckboxButton | Form.pm |
.twikiEditFormCheckboxField | Form.pm |
.twikiRadioButton | Form.pm |
.twikiEditFormRadioField | Form.pm |
.twikiEditFormError | Form.pm |
.twikiDiffTable | RDiff.pm |
.twikiDiffDeletedHeader | RDiff.pm |
.twikiDiffDeletedMarker | RDiff.pm |
.twikiDiffDeletedText | RDiff.pm |
.twikiDiffAddedHeader | RDiff.pm |
.twikiDiffAddedMarker | RDiff.pm |
.twikiDiffAddedText | RDiff.pm |
.twikiDiffChangedHeader | RDiff.pm |
.twikiDiffChangedText | RDiff.pm |
.twikiDiffUnchangedText | RDiff.pm |
.twikiDiffUnchangedTextContents | RDiff.pm |
.twikiDiffLineNumberHeader | RDiff.pm |
.twikiToc | TWiki.pm |
.twikiTocTitle | TWiki.pm |
.twikiTable | TablePlugin |
.twikiSortedAscendingCol | TablePlugin |
.twikiSortedDescendingCol | TablePlugin |
.twikiFirstCol | TablePlugin |
.twikiTableEven | TablePlugin |
.twikiTableOdd | TablePlugin |
.twikiFormTable | formtables.tmpl, form.tmpl |
.twikiFormTableHRow | formtables.tmpl, form.tmpl |
.twikiFormTableRow | formtables.tmpl |
.twikiFormTableFooter | formtables.tmpl |
.twikiAttachments | attachtables.tmpl |
.twikiEditForm | form.tmpl |
.twikiSubmit | |
.twikiSubmitDisabled | |
.twikiInputField | |
.twikiInputFieldDisabled | |
.twikiButton | |
.twikiLeft | |
.twikiRight | |
.twikiClear | |
.twikiHidden | |
.twikiSmall | |
.twikiBottomRow | |
.twikiSRAuthor | |
.twikiSRRev | |
.twikiPageForm | |
.twikiSeparator | |
.twikiAccessKey | |
.twikiLinkLabel | |
.twikiFormSteps | container around a form, such as the attach form: attach.tmpl |
.twikiFormStep | form row |
configure
#twikiLogin | CSS.pm |
.twikiFormSteps | CSS.pm |
.twikiFormStep | CSS.pm |
.twikiBroadcastMessage | TWikiPreferences |
#twikiSearchTable | WebSearch, WebSearchAdvanced |
#twikiLogin | login.pattern.tmpl |
Practical introduction to CSS: http://www.w3.org/Style/LieBos2e/enter/
Related Topics: TWikiSkins, PatternSkin, DeveloperDocumentationCategory, AdminDocumentationCategory
Use internationalised characters within WikiWords and attachment names
This topic addresses implemented UTF-8 support for URLs only. The overall plan for UTF-8 support for TWiki is described in TWiki:Codev.ProposedUTF8SupportForI18N.
To simplify use of internationalised characters within WikiWords and attachment names, TWiki now supports UTF-8 URLs, converting on-the-fly to virtually any character set, including ISO-8859-*, KOI8-R, EUC-JP, and so on.
Support for UTF-8 URL encoding avoids having to configure the browser to turn off this encoding in URLs (the default in Internet Explorer, Opera Browser and some Mozilla Browser URLs) and enables support of browsers where only this mode is supported (e.g. Opera Browser for Symbian smartphones). A non-UTF-8 site character set (e.g. ISO-8859-*) is still used within TWiki, and in fact pages are stored and viewed entirely in the site character set - the browser dynamically converts URLs from the site character set into UTF-8, and TWiki converts them back again.
System requirements are updated as follows:
The following 'non-ASCII-safe' character encodings are now excluded from use as the site character set, since they interfere with TWiki markup: ISO-2022-*, HZ-*, Shift-JIS, MS-Kanji, GB2312, GBK, GB18030, Johab and UHC. However, many multi-byte character sets work fine, e.g. EUC-JP, EUC-KR, EUC-TW, and EUC-CN. In addition, UTF-8 can already be used, with some limitations, for East Asian languages where EUC character encodings are not acceptable - see TWiki:Codev.ProposedUTF8SupportForI18N.
It's now possible to override the site character set defined in the {SiteLocale}
setting in configure - this enables you to have a slightly different spelling of the character set in the server locale (e.g. 'eucjp') and the HTTP header sent to the browser (e.g. 'euc-jp').
This feature should also support use of Mozilla Browser with TWiki:Codev.TWikiOnMainframe (as long as mainframe web server can convert or pass through UTF-8 URLs) - however, this specific combination is not tested. Other browser-server combinations should not have any problems.
Please note that use of UTF-8 as the site character set is not yet supported - see Phase 2 of TWiki:Codev.ProposedUTF8SupportForI18N for plans and work to date in this area.
This feature is complete in TWiki releases newer than February 2004.
Note for skin developers: is no longer required (TWiki:Plugins.InternationalisingYourSkin).
URLs are not allowed to contain non-ASCII (8th bit set) characters: http://www.w3.org/TR/html4/appendix/notes.html#non-ascii-chars
The overall plan for UTF-8 support for TWiki is described in two phases in TWiki:/Codev.ProposedUTF8SupportForI18N - this page addresses the first phase, in which UTF-8 is supported for URLs only.
UTF-8 URL translation to virtually any character set is supported as of TWiki Release 01 Sep 2004, but full UTF-8 support (e.g. pages in UTF-8) is not supported yet - this will be phase 2.
The code automatically detects whether a URL is UTF-8 or not, taking care to avoid over-long and illegal UTF-8 encodings that could introduce TWiki:Codev.MajorSecurityProblemWithIncludeFileProcessing (tested against a comprehensive UTF-8 test file, which IE 5.5 fails quite dangerously, and Opera Browser passes). Any non-ASCII URLs that are not valid UTF-8 are then assumed to be directly URL-encoded as a single-byte or multi-byte character set (as now), e.g. EUC-JP.
The main point is that you can use TWiki with international characters in WikiWords without changing your browser setup from the default, and you can also still use TWiki using non-UTF-8 URLs. This works on any Perl version from 5.005_03 onwards and corresponds to Phase 1 of TWiki:Codev.ProposedUTF8SupportForI18N. You can have different users using different URL formats transparently on the same server.
UTF-8 URLs are automatically converted to the current {Site}{Charset}, using modules such as CPAN:Encode if needed.
TWiki generates the whole page in the site charset, e.g. ISO-8859-1 or EUC-JP, but the browser dynamically UTF-8 encodes the attachment's URL when it's used. Since Apache serves attachment downloads without TWiki being involved, TWiki's code can't do its UTF-8 decoding trick, so TWiki URL-encodes such URLs in ISO-8859-1 or whatever when generating the page, to bypass this URL encoding, ensuring that the URLs and filenames seen by Apache remain in the site charset.
TWiki:Codev.TWikiOnMainframe uses EBCDIC web servers that typically translate their output to ASCII, UTF-8 or ISO-8859-1 (and URLs in the other direction) since there are so few EBCDIC web browsers. Such web servers don't work with even ISO-8859-1 URLs if they are URL encoded, since the automated translation is bypassed for URL-encoded characters. For TWiki on Mainframe, TWiki assumes that the web server will automatically translate UTF-8 URLs into EBCDIC URLs, as long as URL encoding is turned off in TWiki pages.
It should work with TWiki:Codev.TWikiOnMainframe. Tested with IE 5.5, Opera 7.11 and Mozilla (Firebird 0.7).
Opera Browser on the P800 smartphone is working for page viewing but leads to corrupt page names when editing pages.
For up to date information see TWiki:Codev.EncodeURLsWithUTF8
New Features and Enhancements of TWiki Release 4.1
Eng.ajax
into the Jump box... Here we go, the third link is the AjaxCookbook I was looking for."
redirectto
parameter to redirect to a topic or a URL; for security, redirect to URL needs to be enabled with a {AllowRedirectUrl}
configure flag.
redirectto
parameter to redirect to a URL or link to TWiki topic after submitting comment.
topic
URL parameter also respects the {AllowRedirectUrl}
configure flag so redirects to URLs can be disabled which could be abused for phishing attacks.
section
URL parameter to view just a named section within a topic. Useful for simple AJAX type applications.
$nop
, $quot
, $percnt
, $dollar
.
$LISTRAND()
, $LISTSHUFFLE()
, $LISTTRUNCATE()
.
cellborder
.
Hall of Fame of TWiki Release 4.1
Although many more people have been involved in creating TWiki-4.1, special thanks go to the most active contributors in the following areas:
If you find an omission please fix it at TWiki:TWiki.TWikiHistory. For the full list of contributors see TWikiContributor.
Note: Sequence of contributors under "Spec, code, testing", "Templates and skins" and "Documentation" is based on number of SVN check-ins for core and default extensions from 2006-02 to 2006-12. Sequence of contributors under "TWiki.org wiki champions" and "Customer support" is based on TWiki.org web statistics from 2006-02 to 2006-12.
See more details on the TWiki 4.1 release at TWikiReleaseNotes04x01.
Major New Features
Many, many people worked on TWiki-4.0.0. The credits in the table below only list the people who worked on individual enhancements. If you find an omission please fix it at TWiki:TWiki.TWikiHistory. There were many other contributors; for a full list, visit TWikiContributor.
Most of the redesign, refactoring and new documentation work in Dakar release was done by Crawford Currie. Michael Sparks provided ideas and proof of concept for several improvements. Other people who gave large amounts of their time and patience to less sexy aspects of the work, such as testing, infrastructure and documentation, are AntonAylward, KennethLavrsen, LynnwoodBrown, MichaelDaum, Peter Thoeny, SteffenPoulsen, Sven Dowideit, WillNorris.
Installation & configuration | Contributor |
---|---|
Much simpler install and configuration | Crawford Currie, LynnwoodBrown, ArthurClemens |
mod_perl safe code for better performance | Crawford Currie |
Security | |
Security sandbox blocking exploits for remote command execution on the server | Florian Weimer, Crawford Currie, Sven Dowideit |
Reworked access permission model | Crawford Currie |
Internationalization & localization | |
User Interface Internationalisation | AntonioTerceiro |
Chinese translation | CheDong |
Danish translation | SteffenPoulsen |
Dutch translation | ArthurClemens |
French translation | BenVoui |
German translation | AndreUlrich |
Italian translation | MassimoMancini |
Polish translation | ZbigniewKulesza |
Portuguese translation | AntonioTerceiro, CarlinhosCecconi |
Spanish translation | WillNorris, MiguelABayona |
Swedish translation | Erik Åman |
New features for users | |
Edit conflict resolution with automatic merge | Crawford Currie |
Fine grained change notification on page level and parent/child relationship | Crawford Currie |
WYSIWYG editor | Crawford Currie, ColasNahaboo, DamienMandrioli, RomainRaugi |
Integrated session support | GregAbbas, Crawford Currie |
Webserver-independent login/logout | Crawford Currie |
Registration process with e-mail confirmation | MartinCleaver |
Tip of the Day box in TWiki Home | PaulineCheung, Peter Thoeny, AntonAylward |
ATOM feeds | Peter Thoeny |
"Force New Revision" check box for topic save | WillNorris |
New features for TWiki administrators and wiki application developers | |
Improved preferences handling | ThomasWeigert, Crawford Currie |
Named include sections | RafaelAlvarez |
Create topic names with consecutive numbers | Sven Dowideit |
Parameterized includes | Crawford Currie |
Dynamic form option definitions of TWikiForms with FormattedSearch | MartinCleaver |
SEARCH enhancements with new parameters excludeweb , newline , noempty , nofinalnewline , nonoise , recurse , zeroresults | Crawford Currie, ArthurClemens, Peter Thoeny, ThomasWeigert |
FormattedSearch enhancements with $changes , $count , $formfield(name, 30, ...) , $summary(expandvar) , $summary(noheaders) , $summary(showvarnames) | ColasNahaboo, Crawford Currie, Peter Thoeny, Sven Dowideit |
New TWikiVariables ACTIVATEDPLUGINS, ALLVARIABLES, AUTHREALM, EMAILS, FAILEDPLUGINS, HTTP, HTTPS, ICONURL, ICONURLPATH, IF, LANGUAGES, LOCALSITEPREFS, LOGIN, LOGOUT, MAKETEXT, META, PLUGINDESCRIPTIONS, QUERYSTRING, STARTSECTION/ENDSECTION, SESSION_VARIABLE, SESSIONID, SESSIONVAR, SPACEOUT, USERLANGUAGE, WIKIHOMEURL | ArthurClemens, AntonioTerceiro, Crawford Currie, GregAbbas, Peter Thoeny, Sven Dowideit, WillNorris and many more |
TWiki form with hidden type and other form enhancements | LynnwoodBrown, ThomasWeigert |
Support topic-specific templates for TWiki applications | ThomasWeigert |
Direct save feature for one-click template-based topic creation | LynnwoodBrown, Crawford Currie, ThomasWeigert |
Automatic Attachments showing all files in the attachment directory | MartinCleaver |
Rename, move or delete webs | PeterNixon |
Hierarchical subwebs (beta) | PeterNixon |
New features for Plugin developers | |
REST (representational state transfer) interface for Plugins | RafaelAlvarez, TWiki:Main.MartinCleaver, Sven Dowideit |
New and improved Plugins APIs | Crawford Currie, ThomasWeigert |
Improvements in the TWiki engine room | |
Major OO redesign and refactoring of codebase | Crawford Currie |
Automatic build system | Crawford Currie |
Extensive test suite, unit tests and testcases | Crawford Currie |
TWiki:Codev.DevelopBranch , DEVELOP branch Bugs system | Sven Dowideit |
Documentation, logo artwork, skins: | |
Documentation | Crawford Currie, LynnwoodBrown, Peter Thoeny, Sven Dowideit and others |
Design of TWikiLogos with big "T" in a speech bubble | ArthurClemens, Peter Thoeny |
Improved templates and PatternSkin | ArthurClemens |
See more details at TWikiReleaseNotes04x00
Major New Features
Details of New Features and Enhancements of 01-Sep-2004 Release | Developer, Sponsor |
---|---|
Install: Ship with an automatic upgrade script to facilitate TWiki upgrades. Details | TWiki:Main.MartinGregory TWiki:Main.SvenDowideit |
Install: New testenv function to change the locks in the TWiki database to the web server user id (automates installation step). Details | TWiki:Main.MattWilkie TWiki:Main.SvenDowideit |
Install: The shipped .htaccess.txt now needs to be edited before it is valid, to help reduce chances of error. Details | TWiki:Main.CrawfordCurrie TWiki:Main.SvenDowideit |
Install: Configurable password file handling for different types of encryption. Details | TWiki:Main.PavelGoran TWiki:Main.SvenDowideit |
Install: Remove office locations from registration. Details | TWiki:Main.PeterThoeny |
Install: Changes to support shorter URLs with Apache Rewrite rules. Details | TWiki:Main.AntonioBellezza TWiki:Main.WalterMundt |
Install: Remove the Know web from the distribution. Details | TWiki:Main.PeterThoeny |
Internationalization: Support use of UTF-8 URLs for I18N characters in TWiki page and attachment names. Details | TWiki:Main.RichardDonkin |
Authentication: Authenticate users when creating new topic in view restricted web. Details | TWiki:Main.JonathanGraehl TWiki:Main.SvenDowideit |
Preferences: TWiki Preferences need to be secured properly. Details | TWiki:Main.PeterThoeny |
Preferences: Use TWiki Forms to set user preferences. Details | TWiki:Main.JohnTalintyre |
Skins: New pre-installed skins PatternSkin and DragonSkin. Details | TWiki:Main.ArthurClemens TWiki:Main.PeterThoeny |
Skins: New skin browser to choose from installed skins. Details | TWiki:Main.PeterThoeny |
Skins: Documented set of CSS classes that are used in standard skins. Details | TWiki:Main.ArthurClemens TWiki:Main.SvenDowideit |
Skins: Added CSS class names to Diff output. Details | TWiki:Main.SvenDowideit |
Skins: Templates can now be read from user topics, as well as from files in the templates diretcory. Details | TWiki:Main.CrawfordCurrie TWiki:Main.WalterMundt |
Skins: Ensure that the default template gets overridden by a template passed in. Details | TWiki:Main.MartinCleaver TWiki:Main.WalterMundt |
Skin: Convey an important broadcast message to all users, e.g. scheduled server downtime. Details | TWiki:Main.PeterThoeny |
Skin: Balanced pastel colors for TWiki webs. Details | TWiki:Main.ArthurClemens |
Rendering: Use exclamation point prefix to escape TWiki markup rendering. Details | TWiki:Main.ArthurClemens |
Rendering: Ordered lists with uppercase & lowercase letters, uppercase & lowercase Roman numerals. Details | TWiki:Main.DanBoitnott TWiki:Main.PeterThoeny |
Rendering: Allow custom styles for the "?" of uncreated topics. Details | TWiki:Main.SvenDowideit |
Rendering: Render IRC and NNTP as a URL. Details | TWiki:Main.PeterThoeny |
Rendering: Make acronym linking more strict by requiring a trailing boundary, e.g. excluding TLAfoobar. Details | TWiki:Main.CrawfordCurrie TWiki:Main.SvenDowideit |
Rendering: TWiki Form with Label type. Details | TWiki:Main.PeterThoeny |
Rendering: Web names can now be WikiWords. Details | TWiki:Main.PeterThoeny |
Rendering: New syntax for definition list with dollar sign and colon. Details | TWiki:Main.AdamTheo TWiki:Main.PeterThoeny |
Rendering: Table with multi-span rows, functionality provided by Table Plugin. Details | TWiki:Main.WalterMundt |
Variables: New title parameter for TOC variable. Details | TWiki:Main.PeterThoeny TWiki:Main.ArthurClemens |
Variables: New REVINFO variable in templates supports flexible display of revision information. Details | TWiki:Main.PeterThoeny TWiki:Main.SvenDowideit |
Variables: Set times to be displayed as gmtime or servertime. Details | TWiki:Main.SueBlake TWiki:Main.SvenDowideit |
Variables: Properly encode parameters for form fields with ENCODE variable. Details | TWiki:Main.PeterThoeny |
Variables: Expand USERNAME and WIKINAME in Template Topics. Details | TWiki:Main.PeterThoeny |
Variables: Expand same variables in new user template as in template topics. Details | TWiki:Main.PeterThoeny |
Variables: Optionally warn when included topic does not exist; with the option to create the included topic. Details | TWiki:Main.PeterThoeny |
Variables: In topic text show file-types of attached files as icons. Details | TWiki:Main.PeterThoeny |
Variables: New variable FORMFIELD returns the value of a field in the form attached to a topic.. Details | TWiki:Main.DavidSachitano TWiki:Main.SvenDowideit |
Variables: Meta data rendering for form fields with META{"formfield"}. Details | TWiki:Main.PeterThoeny |
Variables: New PLUGINVERSION variable. Details | TWiki:Main.PeterThoeny |
Variables: URLPARAM now has a default="..." argument, for when no value has been given. Details | TWiki:Main.PeterThoeny |
Variables: URLPARAM variable with newline parameter. Details | TWiki:Main.PeterThoeny |
Variables: URLPARAM variable with new multiple=on parameter. Details | TWiki:Main.PaulineCheung TWiki:Main.PeterThoeny |
Search: New switch for search to perform an AND NOT search. Details | TWiki:Main.PeterThoeny |
Search: Keyword search to search with implicit AND. Details | TWiki:Main.PeterThoeny |
Search: Multiple searches in same topic with new multiple="on" paramter. Details | TWiki:Main.PeterThoeny |
Search: Remove limitation on number of topics to search in a web. Details | TWiki:Main.PeterThoeny |
Search: Exclude topics from search with an excludetopic parameter. Details | TWiki:Main.PeterThoeny |
Search: Expand Variables on Formatted Search with expandvariables Flag. Details | TWiki:Main.PeterThoeny |
Search: Formatted Search with Web Form variable to retrieve the name of the form attached to a topic. Details | TWiki:Main.FrankSmith TWiki:Main.PeterThoeny |
Search: Formatted Search with Conditional Output. Details | TWiki:Main.PeterThoeny |
Search: Formatted Search with $parent token to get the parent topic. Details | TWiki:Main.PeterThoeny |
Search: New separator parameter to SEARCH supports better SEARCH embedding. Details | TWiki:Main.PeterThoeny |
Search: Improved search performance when sorting result by topic name. Details | TWiki:Main.PeterThoeny |
Search: New scope=all search parameter to search in topic name and topic text at the same time. Details | TWiki:Main.PeterThoeny |
Search: New topic parameter for AND search on topic text and topic name. Details | TWiki:Main.PeterThoeny |
Search modules uses Perl-style keyword parameters (code cleanup). Details | TWiki:Main.PeterThoeny |
Search: New $wikiname variable in format parameter of formatted search. Details | TWiki:Main.ArthurClemens |
Search: Sort search by topic creation date. Details | TWiki:Main.PeterThoeny |
Search: Topic creation date and user in Formatted Search. Details | TWiki:Main.CoreyFruitman TWiki:Main.SvenDowideit |
Search: Increase levels of nested search from 2 to 16. Details | TWiki:Main.PeterThoeny |
Plugins: New pre-installed Plugins CommentPlugin, EditTablePlugin, RenderListPlugin, SlideShowPlugin, SmiliesPlugin, SpreadSheetPlugin, TablePlugin. Details | TWiki:Main.PeterThoeny |
Plugins: New callback afterSaveHandler , called after a topic is saved. Details | TWiki:Main.WalterMundt |
Plugins: New callbacks beforeAttachmentSaveHandler and afterAttachmentSaveHandler , used to intervene on attachment save event. Details | TWiki:Main.MartinCleaver TWiki:Main.WalterMundt |
Plugins: New callbacks beforeCommonTagsHandler and afterCommonTagsHandler . Details | TWiki:Main.PeterThoeny |
Plugins: New callback renderFormFieldForEditHandler to render form field for edit. Details | TWiki:Main.JohnTalintyre |
Plugins: New callback renderWikiWordHandler to custom render links. Details | TWiki:Main.MartinCleaver TWiki:Main.WalterMundt |
Plugins: New function TWiki::Func::formatTime to format time into a string. Details | TWiki:Main.SvenDowideit |
Plugins: New function TWiki::Func::getRegularExpression to get predefined regular expressions. Details | TWiki:Main.RichardDonkin |
Plugins: New functions TWiki::Func::getPluginPreferences* to get Plugin preferences. Details | TWiki:Main.WalterMundt |
Plugins: New function TWiki::Func::extractParameters to extract all parameters from a variable string. Details | TWiki:Main.PeterThoeny |
Plugins: New function TWiki::Func::checkDependencies to check for module dependency. Details | TWiki:Main.CrawfordCurrie TWiki:Main.SvenDowideit |
Plugins: A recommendation for where a Plugin can store its data. Details | TWiki:Main.PeterThoeny |
UI: Show tool-tip topic info on WikiWord links. Details | TWiki:Main.PeterThoeny |
UI: Save topic and continue edit feature. Details | TWiki:Main.ColasNahaboo |
UI: Change topic with direct save (without edit/preview/save cycle) and checkpoint save. Details | TWiki:Main.MattWilkie TWiki:Main.SvenDowideit |
UI: In attachment table, change 'action' to 'manage'. Details | TWiki:Main.PeterThoeny TWiki:Main.ArthurClemens |
UI: Smaller usability enhancements on the file attachment table. Details | TWiki:Main.PeterThoeny TWiki:Main.ArthurClemens |
UI: Removes anchor links from header content and places them before the text to fix 'header becomes link'. Details | TWiki:Main.ArthurClemens |
UI: Improved functionality of the More screen. Details | TWiki:Main.PeterThoeny TWiki:Main.ArthurClemens |
UI: Quick reference chart of most used markup is now listed on the edit screen. Details | TWiki:Main.ArthurClemens |
UI: Flag for edit script to avoid overwrite of existing topic text and form data. Details | TWiki:Main.NielsKoldso TWiki:Main.PeterThoeny |
UI: Disable Escape key in IE textarea to prevent it cancelling work. Details | TWiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny |
UI: Improved warning message on unsaved topic. Details | TWiki:Main.MartinGregory TWiki:Main.SvenDowideit |
UI: Reverse order of words in page title for better multi-window/tab navigation. Details | TWiki:Main.ArthurClemens |
UI: Provides a framework to create and modify a topic without going through edit->preview->save sequence. Details | TWiki:Main.AndreUlrich TWiki:Main.SvenDowideit |
UI: Set the topic parent to none in More screen, e.g. remove the current topic parent. Details | TWiki:Main.PeterThoeny |
UI: Use templates to define how file attachments are displayed. Was previously hard-coded. Details | TWiki:Main.CrawfordCurrie TWiki:Main.SvenDowideit |
UI: Topic diff shows unified diff with unchanged context. Details | TWiki:Main.SvenDowideit |
UI: Diff feature shows TWiki form changes in nice tables. Details | TWiki:Main.SvenDowideit |
Code refactoring: The log entry for a save now has a dontNotify flag in the extra field if the user checked the minor changes flag. Details | TWiki:Main.PeterThoeny |
Code refactoring: Server-side include of attachments accelerates INCLUDE. Details | TWiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny |
Code refactoring: Move functionality out of bin scripts and into included modules. Details | TWiki:Main.CrawfordCurrie TWiki:Main.SvenDowideit |
Code refactoring: Move bin script functionality into TWiki::UI modules. Details | TWiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny |
Code refactoring: Optimize preferences handling for better performance. Details | TWiki:Main.PavelGoran TWiki:Main.WalterMundt |
Code refactoring: Refactor variable expansion for edit and register. Details | TWiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny |
Code refactoring: Move savemulti script into TWiki::UI::Save. Details | TWiki:Main.MattWilkie TWiki:Main.SvenDowideit |
Code refactoring: Topic search is done natively in Perl, it does not depend anymore on system calls with pipes. Details | TWiki:Main.PeterThoeny |
Code refactoring: Fix logical error in upload script which prevented MIME filename from being used. Details | TWiki:Main.WalterMundt |
Bug Fixes of 01-Sep-2004 Release | Developer, Sponsor |
---|---|
Fix: Consistently create headings with empty anchor tags. Details | TWiki:Main.PeterThoeny |
Fix: TOC does not work for headings containing & without spaces surrounding it. Details | TWiki:Main.PeterThoeny |
Fix: Backslash line break breaks TWiki form definitions. Details | TWiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny |
Fix: Rename fixes unrelated topic references. Details | TWiki:Main.RichardDonkin |
Fix: Bug with infinite recursion in search. Details | TWiki:Main.PeterThoeny |
Fix: Can't send mail with full 'From' address. Details | TWiki:Main.PeterThoeny |
Fix: All scripts change to $bin before execute (for mod_perl2). Details | TWiki:Main.PeterThoeny |
Fix: Several RSS readers do not show all entries seen in the WebChanges list; repeated updates to the same topics get lost. Details | TWiki:Main.ArthurClemens |
Fix: TWiki::Access::checkAccessPermission function improperly handles Main and TWiki webs. Details | TWiki:Main.SvenDowideit |
Fix: Topic save returns error CI Date precedes date in revision. Details | TWiki:Main.PeterThoeny |
Fix: Double quotes got replaced by " in TWiki forms. Details | TWiki:Main.MichaelSparks TWiki:Main.PeterThoeny |
Fix: Duplicated Wiki name in .htpasswd entry for sha1 encoding. Details | TWiki:Main.PeterThoeny |
Fix: When viewing a previous version of a topic, the view script substitutes only one occurrence of the variable EDITTOPIC. Details | TWiki:Main.PeterThoeny |
Fix: Form default values are not working for text fields. Details | TWiki:Main.ThomasWeigert TWiki:Main.SvenDowideit |
Fix: Formatted searches using a $pattern which unbalanced parenthesis crash TWiki. Details | TWiki:Main.PeterThoeny |
Fix: Formatted Search uses title but should use name for formfield parameter. Details | TWiki:Main.PeterThoeny |
Fix: GMTIME variable returns unwanted GMT text. Details | TWiki:Main.SvenDowideit |
Fix: Include from other Web links ACRONYMS. Details | TWiki:Main.PeterThoeny |
Fix: Including an HTML file is very slow. Details | TWiki:Main.JohnTalintyre |
Fix: includeUrl() mess up absolute URLs. Details | TWiki:Main.SvenDowideit |
Fix: Filter out fixed font rendering in TOC to avoid unrendered = equal signs in TOC. Details | TWiki:Main.PeterThoeny |
Fix: The initializeUserHandler is broken for session Plugins. Details | TWiki:Main.JohnTalintyre |
Fix: SEARCH fails with very large webs. Details | TWiki:Main.PeterThoeny |
Fix: Security alert: User could gain view access rights of another user. Details | TWiki:Main.KimCovil TWiki:Main.PeterThoeny |
Fix: 'print to closed file handle' error of log files are not writable. Details | TWiki:Main.MartinGregory TWiki:Main.SvenDowideit |
Fix: Meta data handler can't process CR-LF line endings. Details | TWiki:Main.PeterThoeny |
Fix: METAFIELD meta data is not shown in view raw=on mode. Details | TWiki:Main.PeterThoeny |
Fix: Minor XHTML non-compliance in templates and code. Details | TWiki:Main.PeterThoeny |
Fix: Getting pages from virtual hosts fails. Details | TWiki:Main.JohnTalintyre |
Fix: Create new web fails if RCS files do not exist. Details | TWiki:Main.ClausBrunzema TWiki:Main.SvenDowideit |
Fix: Metacharacters can be passed through to the shell in File Attach. Details | TWiki:Main.PeterThoeny |
Fix: Ability to delete non-WikiWord topics without confirmation. Details | TWiki:Main.PeterThoeny |
Fix: + symbol in password reset fails. Details | TWiki:Main.PeterThoeny |
Fix: Pathinfo cleanup for hosted sites. Details | TWiki:Main.MikeSalisbury TWiki:Main.SvenDowideit |
Fix: Software error in SEARCH if regular expression pattern has unmached parenthesis. Details | TWiki:Main.PeterThoeny |
Fix: Pipe chars in the comment field of the attachment table are not escaped. Details | TWiki:Main.PeterThoeny |
Fix: Link escaping in preview fails for not quoted hrefs. Details | TWiki:Main.TedPavlic TWiki:Main.PeterThoeny |
Fix: Preview expands variables twice. Details | TWiki:Main.PeterThoeny |
Fix: Using a proxy with TWiki fails; no proxy-HTTP request, minimal request not HTTP 1.0, requests marked 1.1 are at best 1.0. Details | TWiki:Main.MichaelSparks TWiki:Main.JohnTalintyre |
Fix: Runaway view processes with TWiki::Sore::RcsLite. Details | TWiki:Main.SvenDowideit |
Fix: Regex Error in WebTopicList with topics that have meta characters in the name. Details | TWiki:Main.PeterThoeny |
Fix: Rename script misses some ref-by topics. Details | TWiki:Main.JohnTalintyre |
Fix: Links to self within the page being renamed are not changed. Details | TWiki:Main.SvenDowideit |
Fix: Rename topic does 'Main.Main.UserName' for attachments. Details | TWiki:Main.PeterThoeny |
Fix: Revision date is set to Jan 1970 when using RCS Lite. Details | TWiki:Main.SvenDowideit |
Fix: The new dynamically-created SiteMap is very nice, but somewhat slow. Details | TWiki:Main.PeterThoeny |
Fix: The makeAnchorName function did not produce the same results if called iteratively, resulting in problems trying to link to headers.. Details | TWiki:Main.WalterMundt |
Fix: Statistics page does not provide links to non-wikiword topics. Details | TWiki:Main.PeterThoeny |
Fix: Make TOC link URI references relative. Details | TWiki:Main.MartinGregory TWiki:Main.PeterThoeny |
Fix: TWiki hangs when used on Apache 2.0. Details | TWiki:Main.SvenDowideit |
Fix: TOC incorrectly strips out links in headers. Details | TWiki:Main.PeterThoeny |
Fix: The HTML tags that are generated by TOC do not close properly. Details | TWiki:Main.PeterThoeny |
Fix: TOC on INCLUDEd topic ignores STOPINCLUDE. Details | TWiki:Main.WillNorris TWiki:Main.PeterThoeny |
Fix: Quotes in tooltip message can break a TWiki form. Details | TWiki:Main.PeterThoeny |
Fix: Better error message if the file attachment directory is not writable. Details | TWiki:Main.CrawfordCurrie TWiki:Main.SvenDowideit |
Fix: Image size of PNG files. Details | TWiki:Main.ArthurClemens |
Fix: The testenv script distinguishes between real user ID and effective user ID. Details | TWiki:Main.RichardDonkin |
Fix: Variables in square bracket links dont work in form fields. Details | TWiki:Main.SvenDowideit |
Fix: Variable with Parameters in Form Fields Disappear. Details | TWiki:Main.PeterThoeny |
Fix: Verbatim tag should escape HTML entities. Details | TWiki:Main.PeterThoeny |
Fix: Field names of TWiki Forms can be WikiWords, this is used to link to a help topic. Details | TWiki:Main.PeterThoeny |
Fix: Clean up the WebRssBase INCLUDES to use VARIABLES set in TWikiPreferences. Details | TWiki:Main.SvenDowideit |
Fix: Resolving variables in included topics. Details | TWiki:Main.OliverKrueger TWiki:Main.SvenDowideit |
/bin/view/Web.TopicName
topic view URL (besides the default /bin/view/Web/TopicName
URL); useful for InterwikiPlugin links like TWiki:Codev.ReadmeFirst
readTopicText
, saveTopicText
, setTopicEditLock
, checkTopicEditLock
%NOAUTOLINK%
setting in the TWikiPreferences to disable the auto-linking of WikiWords
registrationHandler
, beforeEditHandler
, afterEditHandler
, beforeSaveHandler
, writeHeaderHandler
, redirectCgiQueryHandler
, getSessionValueHandler
, setSessionValueHandler
%INCLUDE{ "OtherTopic" rev="1.2" }%
%NOP{}%
variable in TWikiTemplates topic gets removed at topic creation time; useful to write protect template topics
%URLPARAM{}%
variable in TWikiTemplates topic gets expanded at topic creation time; useful for dynamic content creation
$logDir
introduced in TWiki.cfg to set the log directory
setlib.cfg
file in the bin directory to set the TWiki library path
%PROXYHOST
and %PROXYPORT%
settings in the TWikiPreferences
%WIKILOGOIMG%
, %TWIKILOGOURL%
and %WIKILOGOALT%
variables in TWikiPreferences; replacing $wikiHomeUrl
in TWiki.cfg
%WIKITOOLNAME%
variable in TWikiPreferences; replacing $wikiToolName
in TWiki.cfg
%EDITBOXSTYLE%
preferences variable which sets the edit box width automatically to the window width
%URLENCODE{}%
variable to encodes a string for using in a URL parameter, e.g. %URLENCODE{"spaced name"}%
returns spaced%20name
/twiki/templates/register.tmpl
template file
%TOC%
table of content, e.g. ---+!! This heading
is not shown in a TOC
%SEARCH{}%
variable, FormattedSearch and WebSearch
<verbatim>
tags are no longer expanded
%SEARCH{}%
variable for database like reporting.
TWiki.cfg
notedited.tmpl
, notext.tmpl
and notwiki.tmpl
templates. More in TWikiTemplates.
%TOPICLIST{"format"}%
and %WEBLIST{"format"}%
variables to get a formatted topic index and web index, respectively. More in TWikiVariables.
%URLPARAM{"name"}%
variable to query URL parameters. More in TWikiVariables.
| *bold* |
cells as table headers, (ii) render space padded cells | center aligned |
and | right aligned |
, (iii) span multiple columns using | empty cells |||
. More in TextFormattingRules.
.htaccess
files that are attached to a topic get a .txt
suffix appended to the file name. See also TWiki:Codev/FileAttachmentFilterSecurityAlert
---++ My Title
; and new %TOC%
variable to build a table of content from headings in a topic. More in TWikiVariables.
[[http://TWki.org][TWiki]]
) and internal links (i.e [[WikiSyntax][syntax]]
). More in TWikiVariables.
#MyAnchor
at the beginning of a line, and link to it with [[#MyAnchor]]
. More in TWikiVariables.
Net::SMTP
module instead of sendmail
if installed.
<verbatim>
... </verbatim>
tags to show source code "as is". Unlike the <pre>
... </pre>
tags, it also shows <
, >
, &
characters "as is".
==Bold Fixed==
to get Bold Fixed
.
%GMTIME{"..."}%
and %SERVERTIME{"..."}%
variables. Format is now "$hour:$min"
instead of "hour:min"
. More in TWikiVariables. Attention: Check your existing topics when you upgrade TWiki!
%STARTINCLUDE%
and %STOPINCLUDE%
variables to control what gets included of a topic. More in TWikiVariables.
print
skin for a printable view of a topic. More in TWikiSkins and TWiki:Codev/TWikiSkins.
%BASEWEB%
, %INCLUDINGWEB%
, %BASETOPIC%
and %INCLUDINGTOPIC%
to have more control over include handling. More in TWikiVariables and TWiki:Codev/IncludeHandlingImprovements.
noheader="on"
switch in %SEARCH{...}%
to suppress table header. More in TWikiVariables.
$doHidePasswdInRegistration
in wikicfg.pm
to hide plain text password in registration e-mail.
%VAR{"NAME" web="Web"}%
to get web-specific preferences. More in TWikiVariables.
view
"knows" the user once authenticated in edit
. More in TWikiUserAuthentication.
png
image support.
%INCLUDE{"%TWIKIWEB%.TWikiWebsTable"}%
. More in TWiki:Codev/BetterTWikiTagTemplateProcessing.
mailnotify
to suppress all normal output.
[[text formatting FAQ]]
to get the link text formatting FAQ that points to topic TextFormattingFAQ.
%HTTP_EQUIV_ON_VIEW%
, %HTTP_EQUIV_ON_EDIT%
and %HTTP_EQUIV_ON_PREVIEW%
that define the <meta http-equiv="...">
meta tags for the TWiki templates. This can be used for example to set a document expiration time.
%GMTIME{"..."}%
and %SERVERTIME{"..."}%
. More in TWikiVariables.
%INCLUDE{"Web/TopicName.txt"}%
to %INCLUDE{"Web.TopicName"}%
. Legacy syntax still supported.
*bold*, italic, __bold italic__
and fixed
, where it is not necessary anymore to have a trailing space before .,;:?!
characters.
%INCLUDE%
of arbitrary files.
%GMTIME%
variable that shows the current GM time.
%HTTP_HOST%
, %REMOTE_ADDR%
, %REMOTE_PORT%
and %REMOTE_USER%
.
%ATTACHLINKBOX%
controls the default state of the link check box in the attach file page.
Perl -T
option )
%EDITBOXWIDTH%
and %EDITBOXHEIGHT%
to specify the edit box size.
wikiwebs.inc
, wikiwebtable.inc
, weblist.inc
, webcopyright.inc
and webcolors.inc
files.
%SCRIPTSUFFIX%
/ $scriptSuffix containing an optional file extension of the TWiki Perl script. Templates have been changed to use this variable. This allows you to rename the Perl script files to have a file extension like for example ".cgi".
%SCRIPTURLPATH%
/ $scriptUrlPath containing the script URL without the domain name. Templates have been changed to use this variable instead of %SCRIPTURL%
. This is for performance reasons.
%INCLUDE:"filename.ext"%
to %INCLUDE{"filename.ext"}%
. (Previous syntax still supported. Change was done because of inline search syntax)
%SEARCH{"str" ...}%
to show a search result embedded in a topic text. TWikiVariables has more on the syntax. Inline search combined with the category table feature can be used for example to create a simple bug tracking system.
initialize
in wiki.pm
did not handle $thePathInfo
correctly.
$doLogTopic*
in wikicfg.pm to selectively log topic view, edit, save, rdiff, attach, search and changes to monthly log file.
$doRemovePortNumber
in wikicfg.pm to optionally remove the port number from the TWiki URL. Example www.some.domain:1234/twiki
gets www.some.domain/twiki
.
%INCLUDE:"file.inc"%
variable. Search first in the current web, then in parent data directory. Useful to overload default include text in the data directory by web-specific text, like for example webcopyright.inc
text.
TestVersion
/ TestVersions
, TestPolicy
/ TestPolicies
, TestAddress
/ TestAddresses
, TestBox
/ TestBoxes
.
webcopyright.inc
file. This is to easily customize the copyright text.
%WIKIHOMEURL%
(link when pressing the icon on the upper left corner) and %WIKITOOLNAME%
(the name of the wiki tool TWiki
).
%PUBURL%
(Public directory URL) and %ATTACHURL%
(URL of topic file attachment).
fixed font text
. Words get showns in fixed font
by enclosing them in "=" equal signs. Example Writing =fixed font= will show up as fixed font
.
Diffs
link at the bottom of each topic, e.g. Topic TWikiHistory . { Edit Ref-By Diffs r1.3 > r1.2 > r1.1 }
Revision r1.3 1998/11/10 01:34 by PeterThoeny
data/logYYYYMM.txt
, where YYYYMM
the year and month in numeric format is. Intended for auditing only, not accessible from the web.
r1.3
) and differences thereof (e.g. >
) at the bottom Topic TWikiHistory . { Edit Ref-By r1.3 > r1.2 > r1.1 }
Revision r1.3 1998/11/10 01:34 by TWiki:Main.PeterThoeny
Topic TWikiHistory . { Edit Ref-By r1.3 r1.2 r1.1 }
Revision r1.3 1998/10/26 01:34:00 by TWiki:Main.PeterThoeny
AaA
sequence, e.g. AaA1
is a valid TWikiTopics name, but not Aa1
.
%INCLUDE:"filename.ext"%
%TOPIC%
(Topic name), %WEB%
(web name), %SCRIPTURL%
(script URL), %DATE%
(current date), %WIKIWEBMASTER%
(Wiki webmaster address), %WIKIVERSION%
(Wiki version), %USERNAME%
(user name), %WIKIUSERNAME%
(Wiki user name).
PeterThoeny
instead of thoeny
in case the Wiki username exists. Implementation Automatic lookup of Wiki username in topic TWikiUsers.
Know.WebSeach
.
The typical TWiki development flow...
Related Topics: DeveloperDocumentationCategory