This page contains all documentation topics as one long and complete reference sheet. Use the extended menu below to jump directly to sections. Doubleclick anywhere on-screen to return to the top of the page.
(You can also browse the TWiki reference as individual pages from the full topics menu.)
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
Installation instructions for the TWiki 01-Feb-2003 production release. Update notes for the new RCS configuration are marked Dataframework.
These installation steps are based on the Apache web server on Linux. TWiki runs on other web servers and Unix systems, and should be fine with any web server and OS that meet the system requirements. Documentation for other platforms is somewhat limited:
Request and download the TWiki 01-Feb-2003 distribution in Unix ZIP format from http://TWiki.org/download.html. Please review the AdminSkillsAssumptions before you install TWiki.
NOTE: If you don't have access to your Web server configuration files - for example, if you're installing on an ISP-hosted account, or you don't have administrator privileges on your intranet server - use the alternative Step 1 instead.
/home/httpd/twiki
and unzip the TWiki distribution into this directory.
twiki/bin
directory of TWiki must be set as a cgi-bin directory. Add /home/httpd/twiki/bin
to file /etc/httpd/httpd.conf
with only ExecCGI
option.
twiki/pub
directory of TWiki must be set so that it is visible as a URL. Add /home/httpd/twiki
to file httpd.conf
with normal access options (copy from /home/httpd/html
).
ScriptAlias
for /twiki/bin
and Alias
for /twiki
to file httpd.conf
.
ScriptAlias
must come before the Alias
, otherwise, Apache will fail to correctly set up /twiki/bin/
, by treating it as just another subdirectory of the /twiki/
alias.
twiki/data
and twiki/templates
directories should be set so that they are not visible as URLs. Add them to httpd.conf
with deny from all
.
Examplehttpd.conf
entries:ScriptAlias /twiki/bin/ "/home/httpd/twiki/bin/" Alias /twiki/ "/home/httpd/twiki/" <Directory "/home/httpd/twiki/bin"> Options +ExecCGI SetHandler cgi-script Allow from all </Directory> <Directory "/home/httpd/twiki/pub"> Options FollowSymLinks +Includes AllowOverride None Allow from all </Directory> <Directory "/home/httpd/twiki/data"> deny from all </Directory> <Directory "/home/httpd/twiki/templates"> deny from all </Directory>
/etc/rc.d/rc5.d/S85httpd restart
.
twiki/bin
directory is CGI-enabled by trying visiting it in your browser:
bin
directory, http://yourdomain.com/twiki/bin/
.
"Forbidden. You don't have permission to access /twiki/bin/ on this server"
.
"Index of /twiki/bin"
- recheck your httpd.conf
file.
To install TWiki on a system where you don't have Unix/Linux root (administrator) privileges, for example, on a hosted Web account or an intranet server administered by someone else:
pub
)
TWiki dir: What it is: Where to copy: Example: twiki
start-up pages root TWiki dir /home/smith/twiki/
twiki/bin
CGI bin CGI-enabled dir /home/smith/twiki/bin
twiki/lib
library files same level as twiki/bin
/home/smith/twiki/lib
twiki/pub
public files htdoc enabled dir /home/smith/twiki/pub
twiki/data
topic data dir secure from public access /home/smith/twiki/data
twiki/templates
web templates dir secure from public access /home/smith/twiki/templates
If you are not able to create the twiki/lib
directory at the same level as the twiki/bin
directory (e.g. because CGI bin
directories can't be under your home directory and you don't have root access), you can create this directory elsewhere and edit the setlib.cfg
file in the bin
directory:
# -------------- Change these settings if required $twikiLibPath = '/some/other/path/lib'; # Path to lib directory containing TWiki.pm
You can also edit $localPerlLibPath
in the setlib.cfg
file if you are not root and need to install additional CPAN modules, but can't update the main Perl installation files on the server. Just set this variable to the full pathname to your local lib directory, typically under your home directory.
/usr/bin/perl
. If it's elsewhere, change the path to Perl in the first line of each script in the twiki/bin
directory, or create a symbolic link from /usr/bin/perl
.
.cgi
extension to run. Some systems need .pl
, the regular Perl extension. Modify all twiki/bin
script filenames if necessary.
twiki/bin
directory as executable to -rwxr-xr-x
(755).
.tmpl
files it is necessary to chown
and chgrp -R twiki
so all the files have the owner you want.
nobody
ownership for all files manipulated by the CGI scripts (executed by the Web server), and user twiki
for all other files. You can:
nobody
with another user if your server executes scripts under a different name (ex: default for Debian is www-data
).
testenv
script from your browser: http://yourdomain.com/twiki/bin/testenv
. It will show you the user name of the CGI scripts, a table listing all CGI environment variables, and a test of your twiki/lib/TWiki.cfg
configuration file (you'll configure that in a minute).
twiki
with your own username
twiki/data
so that they are writable by user nobody
. A simple way is to chmod
them to -rw-rw-r--
(664) and to chown
them to nobody
.
twiki/data
directory and its subdirectories so that files in there are writable by user nobody
. A simple way is to chmod them to drwxrwxr-x
(775) and to chown
them to nobody
.
twiki/pub
directory and all its subdirectories so that files in there are writable by user nobody
. A simple way is to chmod
them to drwxrwxr-x
(775) and to chown
them to nobody
.
twiki/data/*/*.txt,v
RCS repository files in the installation package are locked by user nobody
. If your CGI scripts are not running as user nobody
, it's not possible to check in files (you'll see that the revision number won't increase after saving a topic). In this case, you need to unlock all repository files (check the RCS man pages) and lock them with a different user, ex www-data
, or delete them all - new files will be automatically created the first time each topic is edited. A simple way to change ownership is with a search-and-replace in all files; for example, using perl:
cd twiki/data perl -pi~ -e 's/nobody:/www-data:/' */*,v
twiki/lib/TWiki.cfg
, setting the variables to your needs.
$scriptSuffix
variable to cgi
or pl
if required.
$storeTopicImpl = "RcsWrap";
for the RCS executables and make sure RCS is installed. Set $rcsDir
in twiki/lib/TWiki.cfg
to match the location of your RCS binaries. You can check this by issuing the command rcs
at the prompt, it should result in something like "rcs: no input file"
.
diff
, by typing diff -v
- an error indicates you have a non-GNU diff, so install the GNU diffutils
package and make sure that diff
is on the PATH used by TWiki (see $safeEnvPath
in the TWiki.cfg
file).
$storeTopicImpl = "RcsLite";
for the Perl based RCS
twiki/data
, twiki/templates
and all their subdirectories should be set so that they are not visible through URLs. (Alternatively, move the directories to a place where they are not visible, and change the variables in twiki/lib/TWiki.cfg
accordingly)
testenv
script from your browser: http://yourdomain.com/twiki/bin/testenv
. Check if your twiki/lib/TWiki.cfg
configuration file settings are correct.
WIKIWEBMASTER
email address, and other email settings required for registration and WebChangesAlert to work:
WIKIWEBMASTER
should be set to the email address of the TWiki administrator
SMTPMAILHOST
is typically set on Windows or other non-Unix/Linux systems, where sendmail
or similar is not available. When this is set and the Perl module Net::SMTP
is installed, TWiki will connect to this SMTP server (e.g. mail.yourdomain.com
) to send email for user registration and WebChangesAlerts. If you do have a sendmail-type program, leave SMTPMAILHOST
unset so that the external sendmail program is used instead (defined by $mailProgram
in TWiki.cfg
).
SMTPSENDERHOST
is optional, and set to the domain name sending the email (e.g. twiki.yourdomain.com
). For use where the SMTP server requires that you identify the TWiki server sending mail. If not set, Net::SMTP
will guess it for you.
http://yourdomain.com/twiki/bin/view
and start TWiki-ing away!
http://yourdomain.com/twiki/
to get the pre-TWiki index.html
page, with a link to the view
script. Customize this page if you want a public intro screen with a login link, instead of immediately calling up the .htaccess login dialog by going directly to view
.
WEBCOPYRIGHT
messages, and other preferences.
%VARIABLES%
. Define site-level variables in the TWikiPreferences topic. See also: TWikiVariables.
That's it for the standard virgin installation of TWiki. Read on for server-level customization options.
With your new TWiki installation up and running, you can manage most aspects of your site from the browser interface. Only a few functions require access to the server file system, via Telnet or FTP. You can make these server-level changes during installation, and at any time afterwards.
.htaccess.txt
in the twiki/bin
directory to .htaccess
and change it to your needs. For details, consult the HTTP server documentation (for Apache server: [1], [2]). In particular, the following red part needs to be configured correctly: Redirect /urlpathto/twiki/index.html http://yourdomain.com/urlpathto/twiki/bin/view
AuthUserFile /filepathto/twiki/data/.htpasswd
ErrorDocument 401 /urlpathto/twiki/bin/oops/TWiki/TWikiRegistration?template=oopsauth
.cgi
or .pl
file extension to the bin
scripts, make sure to do the same for edit
, view
, preview
, and all the other script names in .htaccess
.
.htaccess
does not have the desired effect, you need to enable it: Add "AllowOverride All" to the Directory [3] section of access.conf
for your twiki/bin
directory.
twiki/data/.htpasswd.txt
file contains several TWiki core team user accounts and a guest user account. You probably want to remove those accounts by deleting the entries in .htpasswd
. Do not remove the guest user if you want to allow guest logins.
.txt
and .txt,v
files in the twiki/data/TWiki
directory.
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.
data/.htpasswd
file. The .htpasswd
file that comes with the TWiki installation includes user accounts for TWiki core team members that are used for testing on TWiki.org. You can edit the file and delete those lines.
That's it for a basic new web set-up!
Optionally, you can also:
twiki/templates/Someweb
directory (otherwise, templates are inherited from twiki/templates
).
NOTE: User home topics are located in the TWiki.Main web - don't try to move them or create them in other webs. From any other web, user signatures have to point to TWiki.Main web, using a
Main.UserName
or %MAINWEB%.UserName
format. (The %MAINWEB%
variable is an advantage if you ever change the Main web name, but the standard Main.UserName
is easier for users to enter, which is the bottom line!
See Appendix A: TWiki File System for an installed system snapshot and descriptions of all files in the TWiki 01-Sep-2001 distribution.
-- PeterThoeny - 28 Dec 2002
-- MikeMannix - 16 May 2002
Upgrade from the previous TWiki 01-Dec-2001 production release to TWiki 01-Feb-2003
This guide describes how to upgrade from TWiki 01-Dec-2001 to TWiki 01-Feb-2003. The new version involves several new features and numerous enhancements to the previous version.
readTopicText
, saveTopicText
, setTopicEditLock
, checkTopicEditLock
registrationHandler
, beforeEditHandler
, afterEditHandler
, beforeSaveHandler
, writeHeaderHandler
, redirectCgiQueryHandler
, getSessionValueHandler
, setSessionValueHandler
%SEARCH{}%
variable, FormattedSearch and WebSearch
The following steps describe the upgrade assuming that $TWIKIROOT
is the root of your current 01-Dec-2001 release. As written this will require some downtime. A process for switching over without downtime is described at the end of this section.
$TWIKIROOT/bin
, $TWIKIROOT/pub
, $TWIKIROOT/data
, $TWIKIROOT/templates
, $TWIKIROOT/lib
.
*.html
and *.txt
files in $TWIKIROOT
with the new ones.
$TWIKIROOT/templates
with the new ones.
%WIKIHOMEURL%
with %WIKILOGOURL%
src=%PUBURLPATH%/wikiHome.gif
with src=%WIKILOGOIMG%
alt="TWiki Home"
with alt="%WIKILOGOALT%"
charset=iso-8859-1"
with charset=ISO-8859-1"
%TOPIC%
to form action of GoBox
.../view%SCRIPTSUFFIX%/%WEB%/%TOPIC%"
with .../view%SCRIPTSUFFIX%/%INTURLENCODE{"%WEB%/%TOPIC%"}%
$TWIKIROOT/bin
with the new ones.
.cgi
$TWIKIROOT/bin/setlib.cfg
and point $twikiLibPath
to the absolute file path of $TWIKIROOT/lib
$TWIKIROOT/bin/.htaccess
to include a directive for the new manage
script:<Files "manage">
require valid-user
</Files>
chmod 775 $TWIKIROOT/bin/*
TWiki.cfg
configuration file in $TWIKIROOT/lib
with the new one.
TWiki.pm
library in $TWIKIROOT/lib
with the new one.
$TWIKIROOT/lib
with the new ones. Make sure to preserve any extra Plugins you might have in $TWIKIROOT/lib/TWiki/Plugins
chmod -R 664 $TWIKIROOT/lib/*
bin/testenv
script from the browser (e.g. http://localhost/bin/testenv
) to verify if the cgi-scripts are running as user nobody
.
*,v
RCS repository files delivered with the installation package are locked by user nobody
and need to be changed to the user of your cgi-scripts, e.g. www-data
:
twiki/data/*
directories where you unzipped the installation package: A simple way to switch the locker of the RCS files is to use sed in the :
for f in *,v; do sed 's/nobody\:/www-data\:/' $f > x; mv x $f; done
twiki/data/TWiki
directory where you unzipped the installation package:
InterWikis.*
, TWikiRegistration.*
, TWikiRegistrationPub.*
, WebNotify.*
, WebPreferences.*
, WebStatistics.*
and all WebTopic*
files.
$TWIKIROOT/data/TWiki/TWikiPreferences.*
to TWikiPreferencesSave.*
.
*.txt
and *.txt,v
files from the temporary data/TWiki
directory to your $TWIKIROOT/data/TWiki
directory, overwriting the existing ones.
TWikiPreferencesSave.txt
settings into $TWIKIROOT/data/TWiki/TWikiPreferences.txt
.
data/_default
directory from the temporary location to your $TWIKIROOT/data
directory.
data/Sandbox
directory from the temporary location to your $TWIKIROOT/data
directory $TWIKIROOT/data
are writable by your cgi-script user.
TWiki
and _default
):
WebHome.txt
and WebPreferences.txt
of your other webs to make sure, you have the improvements applied also in your other webs.
pub/TWiki
from your temporary directory into your $TWIKIROOT/pub/TWiki
directory.
$TWIKIROOT/pub/TWiki
are writable by your cgi-script user.
pub/icn
directory from the temporary location to your $TWIKIROOT/pub/icn
directory.
ALLOWWEBMANAGE
to the FINALPREFERENCES
list so that nobody can overwrite the setting:
$TWIKIROOT/bin/testenv
script from your browser (e.g. http://localhost/bin/testenv
) to see if it reports any issues; fix any potential problems.
Note: These steps assume a downtime during the time of upgrade. You could install the new version in parallel to the existing one and switch over in an instant without affecting the users. As a guideline, install the new version into $TWIKIROOT/bin1
, $TWIKIROOT/lib1
, $TWIKIROOT/templates1
, $TWIKIROOT/data/TWiki1
(from data/TWiki
), $TWIKIROOT/pub/TWiki1
(from pub/TWiki
), and configure TWiki.cfg
to point to the same data and pub directory like the existing installation. Once tested and ready to go, reconfigure $TWIKIROOT/bin1/setlib.cfg
and $TWIKIROOT/lib1/TWiki.cfg
, then rename $TWIKIROOT/bin
to $TWIKIROOT/bin2
, $TWIKIROOT/bin1
to $TWIKIROOT/bin
. Do the same with the lib
, templates
and data/TWiki
directories.
-- PeterThoeny - 01 Feb 2002
-- MartinRaabe? - 15 Jan 2003
TWiki site access control and user activity tracking options
TWiki does not authenticate users internally, it depends on the REMOTE_USER
environment variable. This variable is set when you enable Basic Authentication (.htaccess) or SSL "secure server" authentication (https protocol).
TWiki uses visitor identification to keep track of who made changes to topics at what time and to manage a wide range of personal site settings. This gives a complete audit trail of changes and activity.
No special installation steps are required if the server is already authenticated. If it isn't, you have three standard options for controlling user access:
attach
, edit=
, installpasswd
, preview
, rename
, save
, upload
using the .htaccess file
. The TWikiInstallationGuide has step-by-step instructions.
Tracking by IP address is an experimental feature, enabled in lib/TWiki.cfg
. It lets you combine open access to some functions, with authentication on others, with full user activity tracking:
REMOTE_USER
environment variable is set for the scripts that are under authentication. If, for example, the edit
, save
and preview
scripts are authenticated, but not view
, you would get your WikiName in preview
for the %WIKIUSERNAME%
variable, but view
will show TWikiGuest
instead of your WikiName.
view
, will show the correct username instead of TWikiGuest.
$doRememberRemoteUser
flag in TWiki.cfg
. TWiki then persistently stores the IP address/username pairs in the file, $remoteUserFilename
, which is "$dataDir/remoteusers.txt"
by default.
Quick Authentication Test - Use the %WIKIUSERNAME% variable to return your current identity:
This section applies only if your TWiki site is installed on a server that is both authenticated and on an intranet.
TWiki internally manages two usernames: Login Username and TWiki Username.
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, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.
twiki/data
, there are two registration form topics, TWikiRegistration and TWikiRegistrationPub. The original form includes an intranet Login Username field. For Basic Authentication, the original form is replaced by the Pub version. If you started using TWiki on Basic Authentication and want to change, you have to switch back forms for future use, and manually correct the existing entries, by editing TWikiUsers, adding the Login Username for each member - PeterThoeny - pthoeny - 01 Jan 1999
- and also in the .htpasswd
file, where you can either replace the WikiNames or duplicate the entries and have both, so both usernames will work. verification and clearer rewrite to follow in a bit. also link to original installation mention.
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:This pointsMain.WikiUsername
or%MAINWEB%.WikiUsername
WikiUser
to the TWiki.Main web, where user registration pages are stored, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic? everywhere but in the Main web.
Change and reset passwords using forms on regular pages. Use TWikiAccessControl to restrict use as required.
TWiki/ChangePassword
):
Change password
Forgot your old password? Then use ResetPassword instead. Please only use ResetPassword in case you really forgot your password. Thank you.
After submitting this form your password will be changed.
TWiki/ResetPassword
):
Request for reset of password
Please only use this ResetPassword form in case you really forgot your password. Otherwise just change it using ChangePassword. Thank you.
After submitting this form you will see a page with your new password appearing encrypted.
-- MikeMannix - 19 May 2002
Restricting read and write access to topics and webs, by Users and groups
TWikiAccessControl allows you restrict access to single topics and entire webs, by individual user and by user Groups, in three areas: view; edit & attach; and rename/move/delete. Access control, combined with TWikiUserAuthentication, lets you easily create and manage an extremely flexible, fine-grained privilege system.
Open, freeform editing is the essence of WikiCulture - what makes TWiki different and often more effective than other collaboration tools. For that reason, it is strongly recommended that decisions to restrict read or write access to a web or a topic are made with care - the more restrictions, the less Wiki in the mix. Experience shows that unrestricted write access works very well because:
As a collaboration guideline:
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:
.htpasswd
if authentication is enabled.
Users can be authenticated using Basic Authentication (htaccess) or SSL (secure server). In either case, TWikiUserAuthentication is required in order to track user identities, and use User and Group access control.
The default visitor name is TWikiGuest. This is the non-authenticated user.
Groups are defined by group topics created in the Main
web, like the TWikiAdminGroup. To create a new group:
Edit
TWikiGroups by entering a new topic with a name that ends in Group
. Example:
SomeGroup
Set GROUP = < list of Users and/or Groups >
Set ALLOWTOPICCHANGE = < list of Users and/or Groups >
Set GROUP = Main.SomeUser, Main.OtherUser, Main.SomeGroup
Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup
You can define who is allowed to make changes to a web or a topic.
Denying editing of a topic also restricts file attachment; both privileges are assigned together.
Set DENYTOPICCHANGE = < list of Users and Groups >
Set ALLOWTOPICCHANGE = < list of Users and Groups >
Set DENYTOPICCHANGE = Main.SomeBadBoy, Main.SomeBadGirl, Main.SomeHackerGroup
Set ALLOWTOPICCHANGE = Main.SomeGoodGuy, Main.SomeGoodGirl, Main.TWikiAdminGroup
Restricting web-level editing blocks creating new topics, changing topics or attaching files.
Set DENYWEBCHANGE = < list of Users and Groups >
Set ALLOWWEBCHANGE = < list of Users and Groups >
The same rules apply as for restricting topics, with these additions:
You can define who is allowed to rename, move or delete a topic, or rename a web.
To allow a user to rename, move or delete a topic, they also need write (editing) permission. They also need write access to change references in referring topics.
Set DENYTOPICRENAME = < list of Users and Groups >
Set ALLOWTOPICRENAME = < list of Users and Groups >
Set DENYTOPICRENAME = Main.SomeBadBoy, Main.SomeBadGirl, Main.SomeHackerGroup
Set ALLOWTOPICRENAME = Main.SomeGoodGuy, Main.SomeGoodGirl, Main.TWikiAdminGroup
You can define restrictions of who is allowed to rename a TWiki web.
Set DENYWEBRENAME = < list of Users and Groups >
Set ALLOWWEBRENAME = < list of Users and Groups >
The same rules apply as for topics, with these additions:
You can define who is allowed to see a web.
Technically it is possible to restrict read access to an individual topic based on
DENYTOPICVIEW
/ ALLOWTOPICVIEW
preferences variables, provided that the view script is authenticated. However this setup is not recommended since all content is searchable within a web - a search will turn up view restricted topics.
You can define restrictions of who is allowed to view a TWiki web. You can restrict access to certain webs to selected Users and Groups, by:
The idea is to keep a web hidden by not publishing its URL and by preventing the all webs
search option from accessing obfuscated webs. Do so by enabling the NOSEARCHALL
variable in WebPreferences:
Set NOSEARCHALL = on
This setup can be useful to hide a new web until content its ready for deployment.
Obfuscating webs is insecure, as anyone who knows the URL can access the web.
Use the following setup to authenticate users for topic viewing in all webs and to restrict access to selected webs:
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.
NOSEARCHALL
variable in its WebPreferences topic:
Set NOSEARCHALL = on
view
to the list of authenticated scripts in the .htaccess
file.
This method only works if the
view
script is authenticated, which means that all Users have to login, even for read-only access. (An open guest account, like TWikiGuest, can get around this, allowing anyone to login to a common account with, for example, view-only access for public webs.) TWikiInstallationGuide has more on Basic Authentication, using the .htaccess
file.
Use the following setup to provide unrestricted viewing access to open webs, with authentication only on selected webs:
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.
NOSEARCHALL
variable in its WebPreferences topic:
Set NOSEARCHALL = on
$doRememberRemoteUser
flag in lib/TWiki.cfg
as described in TWikiUserAuthentication. TWiki will now remember the IP address of an authenticated user.
view
script to viewauth
(or better, create a symbolic link)
viewauth
to the list of authenticated scripts in the .htaccess
file. The view
script should not be listed in the .htaccess
file.
When a user accesses a web where you enabled view restriction, TWiki will redirect from the view
script to the viewauth
script once (this happens only if the user has never edited a topic). Doing so will ask for authentication. The viewauth
script shows the requested topic if the user could log on and if the user is authorized to see that web.
Authenticating webs is not very secure, as there is a way to circumvent the read access restriction. It can be useful in certain situations - for example, to simplify site organization and clutter, by hiding low traffic webs - but is not recommended for securing sensitive content.
To hide access control settings from normal browser viewing, place them in comment markers.
By mistyping a user or group name in the ALLOWTOPICCHANGE setting, it's possible to lock a topic so that no-one can edit it from a browser. To avoid this, you can create Web-based superusers:
$superAdminGroup
variable in lib/TWiki.cfg
to the name of a group of Users who are always allowed to edit/view topics.
$superAdminGroup = "TWikiAdminGroup";
-- PeterThoeny - 04 May 2002
-- MikeMannix - 12 May 2002
Definition of the templates used to render all HTML pages displayed in TWiki
The new modular template system offers flexible, easy control over the layout of all TWiki pages. The master template approach groups parts that are shared by several templates - like headers and footers - in a common file. Special variables allow individual layouts to include parts from a master template - variables are mixed with regular HTML markup for template-specific content. Templates are used to define page layout, and also to supply default content for new pages.
Where the old templates were each complete HTML documents, the new templates are defined using variables to include template parts from a master file. You can now change one instance of a common element to update all occurrences; previously, every affected template had to be updated. This simplifies the conversion of templates into XHTML format, and provides a more versatile solution for templates and for TWikiSkins. The new system:
&TWiki::Store::readTemplate()
so that the caller simply gets an expanded template file (the same as before).
%TMPL:<key>%
and %TMPL:<key>{"attr"}%
.
%TMPL:INCLUDE{"file"}%
: Includes a template file. The template directory of the current web is searched first, then the templates root (twiki/templates
).
%TMPL:DEF{"var"}%
: Define a variable. Text between this and the END directive is not returned, but put into a hash for later use.
%TMPL:END%
: Ends variable definition.
%TMPL:P{"var"}%
: Prints a previously defined variable.
twiki.tmpl
master template, like twiki.print.tmpl
, that redefines the header and footer.
There are three types of template:
Common parts, appearing in two or more templates, can be defined in a master template and then shared by others: twiki.tmpl
is the default master template.
Template variable: Defines: %TMPL:DEF{"sep"}% "|" separator %TMPL:DEF{"htmldoctype"}% Start of all HTML pages %TMPL:DEF{"standardheader"}% Standard header (ex: view, index, search) %TMPL:DEF{"simpleheader"}% Simple header with reduced links (ex: edit, attach, oops) %TMPL:DEF{"standardfooter"}% Footer, excluding revision and copyright parts %TMPL:DEF{"oops"}% Skeleton of oops dialog
TWiki uses HTML template files for all actions, like topic view, edit, and preview. This allows you to change the look and feel of all pages by editing just a few template files.
Templates are in the twiki/templates
directory. As an example, twiki/templates/view.tmpl
is the template file for the twiki/bin/view
script. Templates can be overloaded by individual webs. The following search order applies:
twiki/templates/$webName/$scriptName.tmpl
twiki/templates/$scriptName.tmpl
$webName
is the name of the web (ex: Main
)
$scriptName
is the script (ex: view
).
NOTE: TWikiSkins can be defined to overload the standard templates.
Special variables are used in templates, especially in view
, to display meta data.
Template topics define the default text for new topics. There are three types of template topic:
All template topics are located in the TWiki web. The WebTopicEditTemplate can be overloaded. 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%
Current date, e.g. 10 Mar 2025
%WIKIUSERNAME%
User name, e.g. Main.TWikiGuest
%URLPARAM{"name"}%
Value of a named URL parameter %NOP%
A no-operation variable that gets removed. Useful to prevent a SEARCH from hitting an edit template topic; also useful to escape a variable like %URLPARAM%NOP%{...}%
%NOP{ ... }%
A no-operation text that gets removed. Useful to write-protect an edit template topic, but not the topics based this template topic. See notes below. Example:
%NOP{
* Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup
}%
Notes:
%NOP{ ... }%
can span multiple lines.
}%
pattern is "non-greedy", that is, it stops at the first occurance. That means, you need to escape variables with parameters located inside %NOP{ ... }%
: Insert a %NOP%
between }
and %
. Silly example: %NOP{ %GMTIME{"$year"}%NOP%% }%
.
All other variables are unchanged, e.g. are carried over "as is" into the new topic.
Here is an example for creating new topics based on a specific template topic:
The above form asks for a topic name. A hidden input tag named templatetopic
specifies ExampleTopicTemplate as the template topic to use. Here is the HTML source of the form:
<form name="new" action="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%INTURLENCODE{"%WEB%"}%/"> * New example topic: <input type="text" name="topic" value="ExampleTopic%SERVERTIME{$yearx$mox$day}%" size="23" /> <input type="hidden" name="templatetopic" value="ExampleTopicTemplate" /> <input type="hidden" name="onlywikiname" value="on" /> <input type="submit" value="Create" /> (date format is <nop>YYYYxMMxDD) </form>
The onlywikiname
parameter enforces WikiWords for topic names.
TIP: You can use the
%WIKIUSERNAME%
and %DATE%
variables in your topic templates to include the signature of the person creating a new topic. The variables are expanded into fixed text when a new topic is created. The standard signature is:
-- %WIKIUSERNAME% - %DATE%
Attached is an example of an oops based template oopsbase.tmpl
and an example oops dialog oopstest.tmpl
based on the base template. %A% NOTE: This isn't the release version, just a quick, simple demo.
The first line declares a delimiter variable called "sep", used to separate multiple link items. The variable can be called anywhere by writing %TMPL:P{"sep"}%
%TMPL:DEF{"sep"}% | %TMPL:END% <html> <head> <title> %WIKITOOLNAME% . %WEB% . %TOPIC% %.TMPL:P{"titleaction"}%</title> <base href="%SCRIPTURL%/view%SCRIPTSUFFIX%/%WEB%/%TOPIC%"> <meta name="robots" content="noindex"> </head> <body bgcolor="#FFFFFF"> <table width="100%" border="0" cellpadding="3" cellspacing="0"> <tr> <td bgcolor="%WEBBGCOLOR%" rowspan="2" valign="top" width="1%"> <a href="%WIKIHOMEURL%"> <img src="%PUBURLPATH%/wikiHome.gif" border="0"></a> </td> <td> <b>%WIKITOOLNAME% . %WEB% . </b><font size="+2"> <B>%TOPIC%</b> %TMPL:P{"titleaction"}%</font> </td> </tr> <tr bgcolor="%WEBBGCOLOR%"> <td colspan="2"> %TMPL:P{"webaction"}% </td> </tr> </table> --- ++ %TMPL:P{"heading"}% %TMPL:P{"message"}% <table width="100%" border="0" cellpadding="3" cellspacing="0"> <tr bgcolor="%WEBBGCOLOR%"> <td valign="top"> Topic <b>%TOPIC%</b> . { %TMPL:P{"topicaction"}% } </td> </tr> </table> </body>
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
.tmpl
filename extension - it contained unresolved %VARIABLES%
, but could still be previewed directly in a browser.
-- PeterThoeny - 01 Feb 2003
-- MikeMannix - 14 Sep 2001
-- TWiki:Main/DavidLeBlanc - 11 Mar 2002
Skins overlay regular templates with alternate header/footer layouts; topic text is not affected
Skins are customized TWikiTemplates files. You can use skins to change the look of a TWiki topic, for example, the layout of the header and footer. Rendered text between header and footer does not change. You can also use skins to define an alternate view, like a view optimized for printing.
Skin files are located in the twiki/templates
directory and are named with the syntax: <scriptname>.<skin>.tmpl
. For example, the Printable skin for the view
template is view.print.tmpl
.
Use the existing TWikiTemplates (like view.tmpl
) or skin files as a base for your own skin, name it for example view.myskin.tmpl
.
You can use template variables, TWikiVariables, and other predefined variables to compose your skins. Some commonly used variables in skins:
Variable: | Expanded to: |
---|---|
%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 |
%SCRIPTSUFFIX% | The script suffix, ex: .pl , .cgi |
%WEB% | The name of the current web. Note: It is recommended to URL-encode the variable in form actions with %INTURLENCODE{"%WEB%"}% for proper handling in an internationalized environment |
%TOPIC% | The name of the current topic. Note: It is recommended to URL-encode the variable in form actions with %INTURLENCODE{"%TOPIC%"}% for proper handling in an internationalized environment |
%WEBTOPICLIST% | Common links of current web, defined in the WebPreferences. It includes a #GoBox |
%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 |
The %WEBTOPICLIST%
includes a "Go" box to jump to a topic. The box also understand URLs, e.g. you can type http://www.google.com/ to jump to an external web site. The feature is handy if you build a skin that has a select box of frequently used links, like Intranet home, employee database, sales database and such. A little JavaScript gets into action on the onSelect method of the select tag to fill the selected URL into the "Go" box field, then submits the form.
Here is an example form that has a select box and the "Go" box for illustration purposes. You need to have JavaScript enabled for this to work:
See TWiki:Plugins/SkinPackagingHowTo
A skin can be activated in two ways:
SKIN
Preference variable in TWikiPreferences, one of the WebPreferences, or in a user - TWikiGuest - topic.
Set SKIN = print
?skin=name
to the URL, for this example:
The ?skin=name
URL parameter overrides the SKIN Preference value.
-- PeterThoeny - 05 Jan 2003
Special text strings expand on the fly to display user data or system info
TWikiVariables are text strings - %VARIABLE%
- that expand into content whenever a page is opened. When a topic is rendered for viewing, VARIABLES
are replaced by data, either user-entered, or info automatically generated by TWiki (like the date, or the current username). There are predefined variables, and Preference variables that you configure. You can also define custom variables, with new names and values.
Most predefined variables return values that were either set in the lib/twiki.cfg
file, when TWiki was installed, or taken from server info (like current username, or date and time). Many of the variables let you format the appearance of the display results.
%INCLUDINGTOPIC%
, %INCLUDE%
, and the mighty %SEARCH%
.
This version of TWiki - 01 Feb 2003 - expands the following variables (enclosed in %
percent signs):
Variable: | Expanded to: | ||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
%WIKIHOMEURL% |
The base script URL of TWiki, is the link of the Home icon in the upper left corner, is http://your.domain.com/twiki | ||||||||||||||||||||||||||||||||||||||||||||||||
%SCRIPTURL% |
The script URL of TWiki, is http://jhydra.sourceforge.net/cgi-bin | ||||||||||||||||||||||||||||||||||||||||||||||||
%SCRIPTURLPATH% |
The path of the script URL of TWiki, is /cgi-bin | ||||||||||||||||||||||||||||||||||||||||||||||||
%SCRIPTSUFFIX% |
The script suffix, ex: .pl , .cgi is |
||||||||||||||||||||||||||||||||||||||||||||||||
%PUBURL% |
The public URL of TWiki, is http://jhydra.sourceforge.net/pub Example: You can refer to a file attached to another topic as %PUBURL%/%WEB%/OtherTopic/image.gif |
||||||||||||||||||||||||||||||||||||||||||||||||
%PUBURLPATH% |
The path of the public URL of TWiki, is /pub | ||||||||||||||||||||||||||||||||||||||||||||||||
%ATTACHURL% |
The attachment URL of the current topic, is http://jhydra.sourceforge.net/pub/TWiki/TWikiVariables Example: If you attach a file you can refer to it as %ATTACHURL%/image.gif |
||||||||||||||||||||||||||||||||||||||||||||||||
%ATTACHURLPATH% |
The path of the attachment URL of the current topic, is /pub/TWiki/TWikiVariables | ||||||||||||||||||||||||||||||||||||||||||||||||
%URLPARAM{"name"}% |
Returns the value of a URL parameter. Note that there is a low risk that this variable could be misused for cross-scripting. Ex: %URLPARAM{"skin"}% returns print for a .../view/TWiki/TWikiVariables?skin=print URL. Is |
||||||||||||||||||||||||||||||||||||||||||||||||
%URLENCODE{"string"}% |
Encodes a string for use as a URL parameter. Ex: %URLENCODE{"spaced name"}% returns spaced%20name |
||||||||||||||||||||||||||||||||||||||||||||||||
%WIKITOOLNAME% |
The name of your TWiki site - TWiki | ||||||||||||||||||||||||||||||||||||||||||||||||
%WIKIVERSION% |
Your current TWiki version - 01 Feb 2003 | ||||||||||||||||||||||||||||||||||||||||||||||||
%USERNAME% |
Your login username - guest | ||||||||||||||||||||||||||||||||||||||||||||||||
%WIKINAME% |
Your Wiki username. Same as %USERNAME% if not defined in the TWikiUsers topic. Is TWikiGuest | ||||||||||||||||||||||||||||||||||||||||||||||||
%WIKIUSERNAME% |
Your %WIKINAME% including the Main web name - always use full signatures - Main.TWikiGuest | ||||||||||||||||||||||||||||||||||||||||||||||||
%MAINWEB% |
The web containing TWikiUsers, OfficeLocations and TWikiGroups is Main | ||||||||||||||||||||||||||||||||||||||||||||||||
%TWIKIWEB% |
The web containing all documentation and site-wide preference settings for TWiki - TWiki | ||||||||||||||||||||||||||||||||||||||||||||||||
%WEB% |
The current web is TWiki | ||||||||||||||||||||||||||||||||||||||||||||||||
%BASEWEB% |
The web name where the includes started, e.g. the web of the first topic of nested includes. Same as %WEB% in case there is no include. |
||||||||||||||||||||||||||||||||||||||||||||||||
%INCLUDINGWEB% |
The web name of the topic that includes the current topic - same as %WEB% if there is no INCLUDE. |
||||||||||||||||||||||||||||||||||||||||||||||||
%HOMETOPIC% |
The home topic in each web - WebHome | ||||||||||||||||||||||||||||||||||||||||||||||||
%NOTIFYTOPIC% |
The notify topic in each web - WebNotify | ||||||||||||||||||||||||||||||||||||||||||||||||
%WIKIUSERSTOPIC% |
The index topic of all registered users - TWikiUsers | ||||||||||||||||||||||||||||||||||||||||||||||||
%WIKIPREFSTOPIC% |
The site-wide preferences topic - TWikiPreferences | ||||||||||||||||||||||||||||||||||||||||||||||||
%WEBPREFSTOPIC% |
The local web preferences topic in each web - WebPreferences | ||||||||||||||||||||||||||||||||||||||||||||||||
%STATISTICSTOPIC% |
The web statistics topic WebStatistics | ||||||||||||||||||||||||||||||||||||||||||||||||
%TOPIC% |
The current topic name - TWikiVariables | ||||||||||||||||||||||||||||||||||||||||||||||||
%BASETOPIC% |
The name of the topic where a single or nested INCLUDE started - same as %TOPIC% if there is no INCLUDE. |
||||||||||||||||||||||||||||||||||||||||||||||||
%INCLUDINGTOPIC% |
The name of the topic that includes the current topic. Same as %TOPIC% in case there is no include. |
||||||||||||||||||||||||||||||||||||||||||||||||
%SPACEDTOPIC% |
The current topic name with added spaces, for regular expression search of Ref-By, is TWiki%20*Variables | ||||||||||||||||||||||||||||||||||||||||||||||||
%TOPICLIST{"format"}% |
Topic index of a web. The "format" defines the format of one topic item. It may include variables: The $name variable gets expanded to the topic name; the $web variable gets expanded to the name of the web.
Parameters are format, separator and web:
%TOPICLIST{" * $web.$name"}% creates a bullet list of all topics.
%TOPICLIST{separator=", "}% creates a comma separated list of all topics.
%TOPICLIST{" <option>$name</option>"}% creates an option list (for drop down menus). |
||||||||||||||||||||||||||||||||||||||||||||||||
%WEBLIST{"format"}% |
Web index, ex: list of all webs. Hidden webs are excluded, e.g. webs with a NOSEARCHALL=on preference variable. The "format" defines the format of one web item. The $name variable gets expanded to the name of the web, $qname gets expanded to double quoted name, $marker to marker where web matches selection .
Parameters are format, separator and web:
%WEBLIST{" * [[$name.WebHome]]"}% creates a bullet list of all webs.
%WEBLIST{"<option $marker value=$qname>$name</option>" webs="Trash,public" selection="TWiki" separator=" "}% Dropdown of all public Webs + Trash Web, current Web highlighted.
|
||||||||||||||||||||||||||||||||||||||||||||||||
%GMTIME% |
GM time, is Mon Mar 10 12:09:32 2025 | ||||||||||||||||||||||||||||||||||||||||||||||||
%GMTIME{"format"}% |
Formatted GM time based on time variables.
%GMTIME{"$day $month, $year - $hour:$min:$sec"}% is 10 Mar, 2025 - 12:09:32 |
||||||||||||||||||||||||||||||||||||||||||||||||
%SERVERTIME% |
Server time, is Mon Mar 10 12:09:32 2025 | ||||||||||||||||||||||||||||||||||||||||||||||||
%SERVERTIME{"format"}% |
Formatted server time. Example: %SERVERTIME{"$hou:$min"}% is 12:09 |
||||||||||||||||||||||||||||||||||||||||||||||||
%HTTP_HOST% |
HTTP_HOST environment variable, is jhydra.sourceforge.net | ||||||||||||||||||||||||||||||||||||||||||||||||
%REMOTE_ADDR% |
REMOTE_ADDR environment variable, is 127.0.0.1 | ||||||||||||||||||||||||||||||||||||||||||||||||
%REMOTE_PORT% |
REMOTE_PORT environment variable, is 36450 | ||||||||||||||||||||||||||||||||||||||||||||||||
%REMOTE_USER% |
REMOTE_USER environment variable, is | ||||||||||||||||||||||||||||||||||||||||||||||||
%INCLUDE{"page" ...}% |
Server side include to IncludeTopicsAndWebPages:
|
||||||||||||||||||||||||||||||||||||||||||||||||
%STARTINCLUDE% |
If present in included topic, start to include text from this location up to the end, or up to the location of the %STOPINCLUDE% variable. A normal view of the topic shows everyting exept the %STARTINCLUDE% variable itself. |
||||||||||||||||||||||||||||||||||||||||||||||||
%STOPINCLUDE% |
If present in included topic, stop to include text at this location and ignore the remaining text. A normal view of the topic shows everyting exept the %STOPINCLUDE% variable itself. |
||||||||||||||||||||||||||||||||||||||||||||||||
%TOC% |
Table of Contents of current topic. | ||||||||||||||||||||||||||||||||||||||||||||||||
%TOC{"SomeTopic" ...}% |
Table of Contents. Shows a TOC that is generated automatically based on headings of a topic. Headings in WikiSyntax ("---++ text" ) and HTML ("<h2>text</h2>" ) are taken into account. Any heading text after "!!" is excluded from the TOC; for example, write "---+!! text" if you do not want to list a header in the TOC. Parameters are topic name, web and depth:
%TOC{depth="2"}% , %TOC{"TWikiDocumentation" web="TWiki"}%
| ||||||||||||||||||||||||||||||||||||||||||||||||
%SEARCH{"text" ...}% |
Inline search, shows a search result embedded in a topic. Parameters are the search term, web, scope, order and many more: [1]
%SEARCH{"wiki" web="Main" scope="topic"}% Formatted example: %SEARCH{"FAQ" scope="topic" nosearch="on" nototal="on" header="| *Topic: * | *Summary: * |" format="| $topic | $summary |"% (displays results in a table with header - details) ![]() %TABLE{}% variable just before the %SEARCH{}% to alter the output of a search. Example: %TABLE{ tablewidth="90%" }%
|
||||||||||||||||||||||||||||||||||||||||||||||||
%METASEARCH{...}% |
Special search of meta data
%METASEARCH{type="topicmoved" web="%WEB%" topic="%TOPIC%" title="This topic used to exist and was moved to: "}% , you may want to use this in WebTopicViewTemplate and WebTopicNonWikiTemplate%METASEARCH{type="parent" web="%WEB%" topic="%TOPIC%" title="Children: "}%
| ||||||||||||||||||||||||||||||||||||||||||||||||
%VAR{"NAME" web="Web"}% |
Get a preference value from a web other then the current one. Example: To get %WEBBGCOLOR% of the Main web write %VAR{"WEBBGCOLOR" web="Main"}% , is #FFFFC0 |
[1] Note: The search form uses identical names for input fields.[2] Note: A web can be excluded from a
web="all"
search if you define aNOSEARCHALL=on
variable in its WebPreferences.
Additional variables are defined in the preferences ( site-level ( SL ) in TWikiPreferences, web-level ( WL ) in WebPreferences of each web, and user level ( UL ) preferences in individual user topics):
Variable: | Level: | What: |
---|---|---|
%WIKIWEBMASTER% |
SL | Webmaster email address (sender of email notifications) , is fanamin@hotmail.com |
%WIKIWEBLIST% |
SL | List of TWiki webs (in upper right corner of topics) |
%WEBTOPICLIST% |
WL | Common links of web (second line of topics) |
%WEBCOPYRIGHT% |
SL , WL | Copyright notice (bottom right corner of topics) |
%WEBBGCOLOR% |
WL | Background color of web |
%NOSEARCHALL% |
WL | Exclude web from a web="all" search (set variable to on for hidden webs) |
%NEWTOPICBGCOLOR% |
SL , UL | Background color of non existing topic. ( UL needs authentication for topic views ) |
%NEWTOPICFONTCOLOR% |
SL , UL | Font color of non existing topic. ( UL needs authentication for topic views ) |
%EDITBOXWIDTH% |
SL , UL | Horizontal size of edit box, is 70 |
%EDITBOXHEIGHT% |
SL , UL | Vertical size of edit box, is 17 |
%RELEASEEDITLOCKCHECKBOX% |
SL , UL | Default state of the "Release edit lock" (UnlockTopic) check box in preview. Checkbox is initially checked if Set RELEASEEDITLOCKCHECKBOX = checked="checked" , or unchecked if empty. If checked, make sure to click on Edit to do more changes; do not go back in your browser to the edit page, or you risk that someone else will edit the topic at the same time! Value is: checked="checked" |
%DONTNOTIFYCHECKBOX% |
SL , UL | Default state of the "Minor Changes, Don't Notify" (DontNotify) check box in preview. Check box is initially checked if Set DONTNOTIFYCHECKBOX = checked="checked" , or unchecked if empty. Value is: |
%ATTACHLINKBOX% |
SL , UL | Default state of the link check box in the attach file page. Check box is initially checked if value is set to CHECKED , unchecked if empty. If checked, a link is created to the attached file at the end of the topic. Value is: |
%HTTP_EQUIV_ON_VIEW% |
SL | http-equiv meta tags for view, rdiff, attach, search* scripts. |
%HTTP_EQUIV_ON_EDIT% |
SL , UL | http-equiv meta tags for edit script. |
%HTTP_EQUIV_ON_PREVIEW% |
SL , UL | http-equiv meta tags for preview script. |
%DENYWEBCHANGE% |
WL | List of users and groups who are not allowed to change topics in the TWiki web. (More in TWikiAccessControl) |
%ALLOWWEBCHANGE% |
WL | List of users and groups who are allowed to change topics in the TWiki web. (More in TWikiAccessControl) |
%DENYTOPICCHANGE% |
(any topic) | List of users and groups who are not allowed to change the current topic. (More in TWikiAccessControl) |
%ALLOWTOPICCHANGE% |
(any topic) | List of users and groups who are allowed to change the current topic. (More in TWikiAccessControl) |
%DENYWEBRENAME% |
WL | List of users and groups who are not allowed to rename topics in the TWiki web. (More in TWikiAccessControl) |
%ALLOWWEBRENAME% |
WL | List of users and groups who are allowed to rename topics in the TWiki web. (More in TWikiAccessControl) |
%DENYTOPICRENAME% |
(any topic) | List of users and groups who are not allowed to rename the current topic. (More in TWikiAccessControl) |
%ALLOWTOPICRENAME% |
(any topic) | List of users and groups who are allowed to rename the current topic. (More in TWikiAccessControl) |
%FINALPREFERENCES% |
SL , WL | List of preferences that are not allowed to be overridden by next level preferences |
Note: There are some more useful variables defined in the TWikiPreferences like%BR%
for line break, colors like%RED%
for colored text and small icons like%H%
for aHelp icon.
Set VARIABLENAME = value
Set VARIABLENAME = value
Example: Create a custom logo variable the TWiki web
- To place a logo anywhere in a web by typing
%MYLOGO%
, define the Variable on the web's WebPreferences page, and upload a logo file, ex:mylogo.gif
. You can upload by attaching the file to WebPreferences, or, to avoid clutter, to any other topic in the same web, ex:LogoTopic
:
Set MYLOGO = %PUBURL%/TWiki/LogoTopic/mylogo.gif
-- PeterThoeny - 19 Jan 2003
-- MikeMannix - 12 May 2002
Plug-in enhanced feature add-ons, with a Plugin API for developers
You can add Plugins to extend TWiki's functionality, without altering the core program 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 comes with three Plugins as part of the standard installation.
TWiki:Plugins
expands to TWiki:Plugins on TWiki.org. You can edit the predefined set of of Wiki-related sites, and add your own.
Each TWikiPlugin comes with full documentation: step-by-step installation instructions, a detailed description of any special requirements, version details, and a working example for testing.
Most Plugins can be installed in three easy steps, with no programming skills required:
Special Requests: Some Plugins need certain Perl modules to be preinstalled on the host system. Plugins may also use other resources, like graphics, other modules, applications, templates. In these cases, detailed instructions are in the Plugin documentation.
Each Plugin has a standard release page, located in the TWiki:Plugins web at TWiki.org. In addition to the documentation topic (SomePlugin
), there's a separate development page.
Dev
(SomePluginDev
).
To test new Plugins on your installation before making them public, you may want to use one of these two approaches:
twiki/bin
and twiki/lib
directories for the Test version, adjusting the paths in the new lib/TWiki.cfg
, the twiki/data
; the twiki/templates
and twiki/pub
directories are shared.
DISABLEDPLUGINS
variable in TWikiPreferences. Redefine the DISABLEDPLUGINS
variable in the Sandbox
web and do the testing there.
When you finish installing a Plugin, you should be able to read the user instructions and go. In fact, some Plugins require additional settings or offer extra options that you have to select. Also, you may want to make a Plugin available only in certain webs, or temporarily disable it. And may want to list all available Plugins in certain topics. You can handle all of these management tasks with simple procedures.
Installed Plugins can be toggled on or off, site-wide or by web, through TWikiPreferences and individual WebPreferences:
lib/TWiki/Plugins
directory are activated automatically unless disabled by the DISABLEDPLUGINS
Preferences variable in TWikiPreferences. You can optionally list the installed Plugins in the INSTALLEDPLUGINS
Preferences variable. This is useful to define the sequence of Plugin execution, or to specify other webs than the TWiki web for the Plugin topics. Settings in TWikiPreferences are:
Set INSTALLEDPLUGINS = DefaultPlugin, ...
Set DISABLEDPLUGINS = EmptyPlugin, ...
Plugin execution order in TWiki is determined by searching Plugin topics in a specific sequence: First, full web.topicname
name, if specified in INSTALLEDPLUGINS
; next, the TWiki web is searched; and finally, the current web.
Plugin-specific settings are done in individual Plugin topics. Two settings are standard for each Plugin:
Set SHORTDESCRIPTION = Blah blah woof woof.
data/debug.txt
. Set to 0=off or 1=on:
Set DEBUG = 0
%<pluginname>_<var>%
, ex: %DEFAULTPLUGIN_SHORTDESCRIPTION%
shows the description of the DefaultPlugin.
Plugin status variables let you list all active Plugins wherever needed. There are two list formats:
%ACTIVATEDPLUGINS%
variable lists activated Plugins by name. (This variable is displayed in TWikiPreferences for debugging use.)
%PLUGINDESCRIPTIONS%
variable displays a bullet list with a one-line description of each active Plugins. This variable is based on the %<plugin>_SHORTDESCRIPTION%
Preferences variables of individual topics and is shown in TextFormattingRules.
DEMO: Automatically List Active Plugins Using VariablesUsing
%ACTIVATEDPLUGINS%
:
On this TWiki site, the active Plugins are: DefaultPlugin, InterwikiPlugin.Using
%
:PLUGINDESCRIPTIONS%
You can use any of these active TWiki Plugins:
- DefaultPlugin: This plugin can be used to specify some simple custom rendering rules. It also renders deprecated
*_text_*
as bold italic text.- InterwikiPlugin: Link
ExternalSite:Page
text to external sites based on aliases defined in the InterWikis topic.
The Application Programming Interface (API) for TWikiPlugins provides the specifications for hooking into the core TWiki code from your external Perl Plugin module. The Plugin API is new to the Production version of TWiki with the 01-Sep-2001 release.
The TWikiFuncModule (lib/TWiki/Func.pm
) implements ALL official Plugin functions. Plugins should ONLY use functions published in this module.
If you use functions not in
Func.pm
, you run the risk of creating security holes. Also, your Plugin will likely break and require updating when you upgrade to a new version of TWiki.
In addition to TWiki core functions, Plugins can use predefined hooks, or call backs, listed in the lib/TWiki/Plugins/EmptyPlugin.pm
module.
DISABLE_
from the function name.
outsidePREHandler
and insidePREHandler
are particularly expensive.
To eliminate the incompatibility problems bound to arise from active open Plugin development, a Plugin versioning system and an API GetVersion
detection routine are provided for automatic compatibility checking.
$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).
$VERSION='1.000'
is the current setting in TWiki::Plugins.pm
and in the preinstalled system Plugins (DefaultPlugin, EmptyPlugin, InterwikiPlugin).
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();
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 Global Settings: <Description and settings for custom Plugin %VARIABLES%, and those required by TWiki.>"
- Plugins Preferences <If user settings are needed, explain... Entering values works exactly like TWikiPreferences and WebPreferences: six (6) spaces and then:>"
- Set <EXAMPLE = value added>
Plugin Installation Instructions: <Step-by-step set-up guide, user help, whatever it takes to install and run, goes here.>"
Plugin Info: <Version, credits, history, requirements - entered in a form, displayed as a table. Both are automatically generated when you create or edit a page in the TWiki:Plugins web.>"
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. Publish your Plugin in three steps:
MyFirstPlugin.txt
MyFirstPlugin.zip
Dev
, ex: MyFirstPluginDev
. This is the discussion page for future development. (User support for Plugins is handled in TWiki:Support.)
-- AndreaSterbini - 29 May 2001
-- PeterThoeny - 29 Jan 2003
-- MikeMannix - 03 Dec 2001
Topic TWikiDocumentation . { |
Revision r1.27 - 01 Sep 2001 - 04:47 GMT - MikeMannix |
Copyright © 1999-2004 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback. |