jEdit Community home jEdit Community Wiki > TWiki > TWikiDocumentation jEdit Community Wiki webs:
Main | Plugins | Know | TWiki | Sandbox?
TWiki . { Readme? | Changes | Index | Search | Go }

TWiki Reference Manual (01 Feb 2003)

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

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

Related Topics: TWiki Site, TWiki History?, TWiki Planned Features, TWiki Enhancement Requests

Windows Install Cookbook

Introduction

This cookbook is intended to get you up and running with TWiki on Windows quickly, with as few problems as possible. The 'cookbook' approach is simply to restrict the many choices that someone installing TWiki must make, so that a reasonably well-defined procedure can be followed - new users can simply follow the steps, while experts can use this as more of a guideline. Please read TWiki:Codev.WindowsModPerlInstallCookbook in case you use mod_perl.

There is a huge volume of existing material on TWiki about installing on Windows, and I'm indebted to the many contributors for this - the aim of this cookbook is to synthesise the many tips into a recipe that works.

-- Richard Donkin - 24 Feb 2002

Recent updates

Scope

This document covers installation of the TWiki -1-Feb-2003 production release in the following environment - if you want to use a different environment, feel free to use this as a guideline only.

Component Name, version Comment
Operating System Windows 2000 Should also work for Windows NT
Web Server Apache 1.3.26 Windows-specific security holes fixed in this build
(check latest version at http://httpd.apache.org, but don't use Apache 2.0 yet)
Unix tools Cygwin 1.3.9 Simplest way to get a whole set of required tools
Perl Cygwin perl-5.6.1-2 Comes with Cygwin
RCS Cygwin rcs-5.7-2 Comes with Cygwin, includes a file corruption bugfix

Why this choice of packages? Because I've tried them, and they work well, without requiring a complicated setup... In particular, Apache is the commonest choice for TWiki on Unix/Linux, Cygwin Perl is very close to Unix Perl, and the Cygwin RCS is regularly updated, with a recent TWiki-relevant bug fix in Feb 2002. Cygwin also lets you install the Unix tools, Perl and RCS in a single step, saving quite a lot of time.

More recent minor versions should be OK, but they can introduce bugs.

NEW Major version upgrades, such as Apache 2.0 and Perl 5.8, are very likely to cause problems - for example, Apache 2.0 is unable to authenticate (see TWiki:Support.FailedAuthenticationWithApache2OnWinNT) users created by the current TWiki user registration script (due to a feature being removed in 2.0), and Perl 5.8 may introduce issues due to its Unicode features. Even though the Apache group says that Apache 2.0 is the best version, that's not true for TWiki.

Alternatives

There are doubtless other combinations of components that may work - in particular:

Covering the whole range of additional possibilities, particularly web servers, would make this cookbook too complex, and is best handled as a separate activity.

Checking versions

If you already have some of these add-ons installed, here's how to check the versions - this assumes you have TWiki:Codev.CygWin already installed: 

   $ : Cygwin DLL version is the number in 1.3.x format
   $ uname -r
   $ less c:/your-apache-dir/Announcement
   $ perl -v
   $ rcs -V

If you have an older version of any component, do yourself a favour and upgrade it as part of the install process.

Pre-requisites and upgrades

You will need to have local administrator rights and to be comfortable with Windows administration.

This cookbook is intended for a clean install, i.e. none of these components are already installed. However, since Cygwin and Apache's installation process is fairly upgrade-friendly, upgrades should work as well - take backups of all your data and config files first, though!

Text editing

Editing Cygwin files is best done with an editor that can handle Unix file format (see the Cygwin binary mode section below) - the installation process includes nano, a non-GUI editor, but if you prefer to use a GUI editor, you should first install PFE, a freeware editor that supports Unix format files. PFE is available on download.com and Simtel.

Another good TWiki:Codev.OpenSource editor is SciTE (aka WSciTE), available at http://www.scintilla.org/SciTE.html.

The Unix/Windows Environment

It's a little known fact that you can use pathnames such as c:/apache almost everywhere in Windows - try it in a File Open dialogue box. The main exception is the Win2000 cmd.exe command line shell - here, you must use double quotes around forward slashes, e.g. dir "c:/apache" will work fine.

The reason this matters is that '\' is a special character to Perl and other tools, so it's much easier to use '/' everywhere.

The Cygwin environment

TWiki:Codev.CygWin is a Unix-like environment for Windows - many of its tools support the c:/apache format, but it also provides a more Unixlike syntax, e.g. /usr/bin/rcs.exe, because some Unix tools ported onto Cygwin only support the Unix format.

When you launch a Cygwin shell, your existing PATH variable is translated from the Windows format to the Unix format, and the ';' separators in the Windows PATH are changed into ':' separators as required by Unix. A Cygwin tool (e.g. Cygwin Perl or Cygwin RCS) will always use the Unix PATH format, and will accept Unix format pathnames.

The Apache environment

Apache runs as a native Windows process and has nothing to do with Cygwin (at least the version used in this cookbook doesn't). Hence it supports c:/ pathnames in its config files and the first line of Perl CGI scripts.

If you need to use spaces in file names (not recommended), put double quotes around the file name in the httpd.conf file. There have been some security-related bugs in Apache with long pathnames, which are a bit more likely if you use spaces, so it's best to just avoid long names and using spaces.

The Perl environment

Once Perl has been launched by Apache, it is in Cygwin mode, and so is everything it launches, including ls, egrep, and RCS tools that it (typically) launches with the bash shell.

If you need to use spaces in file names (not recommended), you may be able to put double quotes around the file name in the TWiki.cfg file - however, it's not clear whether all the TWiki code would work with this.

Installing Components

Enough background, let's get on with the installation.

TWiki (part 1)

Head to http://twiki.org, click the download link, and fill in the form to request a URL for download. You'll get an automated email, which should arrive by the time you need it.

Apache

1. Download Apache

2. Install Apache

3. Test Apache

Congratulations, you now have a working web server!

To restart Apache after changing its config, type:

Another useful command is apache -k stop.

Cygwin, Unix tools, Perl and RCS

4. Install Cygwin

Head to http://cygwin.com, and click the Install Cygwin Now link. Save the setup.exe in a directory, e.g. c:\download\cygwin-dist.

Now run the Cygwin setup.exe file - this will also install Perl and RCS in one fell swoop.

5. Test Cygwin

The Cygwin User Guide is well worth reading for some background on how Cygwin works.

6. Configure Cygwin for binary mode 

   $ mkdir /twiki /c c:/twiki
   $ mount -b -s c:/twiki /twiki
   $ mount -b -s c:/ /c
   $ mount -b -c /cygdrive
   $ mount
   Device              Directory           Type         Flags
   C:\cygwin\bin       /usr/bin            system       binmode
   C:\cygwin\lib       /usr/lib            system       binmode
   C:\cygwin           /                   system       binmode
   c:\twiki            /twiki              system       binmode
   c:                  /c                  system       binmode

This setup is written to the Windows registry, so there's no need to put these commands into a .profile file. For more information on binary vs text mode, see this User Guide section and this FAQ entry.

TWiki (part 2)

7. Download TWiki

Download the latest TWiki release from the URL that Peter Thoeny sent you, and save it in the c:/twiki directory.

8. Install TWiki

Unzip the ZIP file under c:/twiki using WinZip, or by going into Cygwin and doing the following - you can hit the TAB key to complete filenames after you've typed the first part: 

   $ cd /twiki
   $ unzip TWiki20011201.zip

Configuring components

Now that all the components are installed, you need to configure them.

Configuring Apache

The setup given here is fairly simple, in that it allows only TWiki to be served by the web server. For more complex setups, you can investigate the Alias and ScriptAlias commands that are left commented out in this configuration.

1. Configure Apache (part 1)

Using a suitable text editor (e.g. Cygwin's 'nano', or the Windows PFE editor, unless you already know 'vi'), edit c:/apache/conf/httpd.conf as follows - this tells Apache where TWiki lives, and removes the need to tinker with the Windows 2000 environment settings. 

# Change this to point to the Apache administrator (e.g. you)
ServerAdmin you@yourdomain.com

# Replaces DocumentRoot "C:/apache/htdocs"
DocumentRoot "C:/twiki"

# Replaces <Directory "C:/apache/htdocs">
<Directory "C:/twiki">



# Alias /twiki/ "C:/twiki/"
# ScriptAlias /twiki/bin/ "C:/twiki/bin/"
<Directory  "C:/twiki/bin/">
    # RD: Changed None to All in next line, to enable .htaccess
    AllowOverride All
    Allow From All
    Options  ExecCGI
    SetHandler cgi-script
</Directory>

# Environment setup required to run Apache as service or as a
# standalone process.
<IfModule mod_env.c>
   # Adjust TZ for your server timezone, e.g. EST5EDT - put the non-daylight-savings
   # timezone code first (e.g. EST or GMT), followed by the number of hours that it's behind GMT 
   # during non-daylight-savings time (use '-5' for timezones in advance of GMT).
   SetEnv TZ GMT0BST
   SetEnv RCSINIT -x,v/
   # Adjust TEMP and TMP for your server and create directories if necessary
   SetEnv TEMP c:/temp
   SetEnv TMP c:/temp
   SetEnv LOGNAME system
   SetEnv HOME c:/twiki
</IfModule>

2. Configure Apache (part 2)

Add an AddHandler line to the <IfModule mod_mime.c> section of httpd.conf - this removes the need to rename all the TWiki CGI scripts later in the installation. 

#
# Document types
#
<IfModule mod_mime.c>
    # TWiki setup - avoid renaming scripts
    AddHandler cgi-script .
</IfModule>

Configuring TWiki

3. Configure TWiki

Edit the TWiki config file, c:/twiki/lib/TWiki.cfg (or in Cygwin terms, /twiki/lib/TWiki.cfg) as follows: 

# variables that need to be changed when installing on a new server:
# ==================================================================
#                   http://community.jedit.org/wiki : link of TWiki icon in upper left corner :
$wikiHomeUrl      = "http://yourdomain.com/bin/view";
#                   Host of TWiki URL :    (Example "http://myhost.com:123")
$defaultUrlHost   = "http://yourdomain.com";
#                   /cgi-bin/TWiki : cgi-bin path of TWiki URL:
$scriptUrlPath    = "/bin";
#                   /wiki/pub : Public data path of TWiki URL (root of attachments) :
$pubUrlPath       = "/pub";

# NOTE: Next three settings should be valid absolute pathnames using Cygwin; if using
# TWiki:Codev.ActiveState Perl, use z:/twiki format pathnames if your TWiki directory is not on C:.

#                   Public data directory, must match $pubUrlPath :
$pubDir           = "/twiki/pub";
#                   Template directory :
$templateDir      = "/twiki/templates";
#                   Data (topic files) root directory :
$dataDir          = "/twiki/data";

....

#                   Set ENV{'PATH'} explicitly for taint checks ( #!perl -T option ) :
#                   (Note: PATH environment variable is not changed if set to "")

# On Windows, $safeEnvPath needs only one component, the directory where RCS is installed
# - used by 'rcsdiff' to run 'co' program, so PATH must be correct.

# Unix/Linux setting:
# $safeEnvPath      = "/bin:/usr/bin";

# Using Cygwin perl, so can use Unix-like paths, with ':' as separator.
# Note that /usr/bin and /bin are identical due to default /usr/bin mount
# in Cygwin.  Must NOT use 'c:/foo' type paths, as ':' is taken as separator
# meaning that 'c' is interpreted as a pathname, giving Perl taint error.
$safeEnvPath      = "/bin";

# If using ActiveState perl, use Windows paths instead
# $safeEnvPath      = "c:/cygwin/bin";

...

#                   RCS directory (find out by 'which rcs') :
$rcsDir           = "c:/cygwin/bin";

...

#                   Unix egrep command :
$egrepCmd         = "/bin/grep -E";
#                   Unix fgrep command :
$fgrepCmd         = "/bin/grep -F";

For the cookbook install using Cygwin Perl, there's no more TWiki.cfg editing to be done, so you can get onto the next section. 

#                   NOTE: When using ActiveState Perl, you must specify
#                   a full Windows-style pathname, using '\\' for backslashes,
#                   for the ls, egrep and fgrep commands, because Cygwin's shell
#                   is not used - forward slashes are OK in Windows everywhere
#                   except in the cmd.exe shell. Drive letters are OK - e.g.
#                   'c:\\foo\\ls' will work.  When using Cygwin perl, just
#                   use the default '/bin/ls' type settings.
#
#                   Unix ls command :
$lsCmd            = "c:\\cygwin\\bin\\ls";
#                   Unix egrep command :
$egrepCmd         = "c:\\cygwin\\bin\\grep";
#                   Unix fgrep command :
$fgrepCmd         = "c:\\cygwin\\bin\\grep";

Editing the CGI scripts

4. Editing the Shebang lines

Now to edit the curiously named 'shebang lines' at the top of the TWiki CGI scripts... 

$ cd /twiki/bin

$ ls
attach   geturl         oops     rdiff     save        testenv  viewfile
changes  installpasswd  passwd   register  search      upload
edit     mailnotify     preview  rename    statistics  view

$ mkdir .backup 
$ cp * .backup

$ head -1 view
#!/usr/bin/perl -wT

$ perl -pi~ -e 's;#!/usr/bin/perl;#!c:/cygwin/bin/perl;' *[a-z]

$ head -1 view
#!c:/cygwin/bin/perl -wT

$ ls
attach    geturl          oops      rdiff      save         testenv   viewfile~
attach~   geturl~         oops~     rdiff~     save~        testenv~  view~
changes   installpasswd   passwd    register   search       upload
changes~  installpasswd~  passwd~   register~  search~      upload~
edit      mailnotify      preview   rename     statistics   view
edit~     mailnotify~     preview~  rename~    statistics~  viewfile

If for some reason the edit goes wrong, just type cp .backup/* . (while within the bin directory) to restore the original distribution files. Use ls -a to see the .backup directory, and ls -a .backup to view its contents.

Optional step: you can do 'rm *~' to clean out the backups made by Perl, but that's not essential as all the original files cannot be executed. If you do this, type the command very carefully, as a space after the '*' will wipe out all files in this directory!

5. Minor changes to TWiki scripts

As an interlude, you now need to make some minor edits to files in the c:/twiki/bin directory, using a suitable editor (remember to use nano -w filename if you prefer nano to vi - or just use the Windows PFE editor). 

         return $user . ':{SHA}' . MIME::Base64::encode_base64(Digest::SHA1::sha1($passwd));

Perl module installation

6. Installing required Perl modules

Some additional Perl modules are needed for the register script to work properly. Fortunately, there is an automated tool that makes it easy to do this - it's called cpan, and goes to the Perl module archive site, http://www.cpan.org/, to download all required modules, and then build and install them. Here's what you need to do:

First of all, you need to get the cpan tool configured and working - this is only necessary once. From the Cygwin shell, type the following (putting the export command in ~/.profile is recommended to make this setting persistent). Without the TEMP variable, some modules may fail to install on Windows 2000 and higher. 

$ export TEMP=/c/temp
$ cpan
Lots of questions about configuration and preferences - just hit Enter until you 
get to the questions about mirror sites, but answer the questions about FTP proxies etc
 if you are behind a proxy-based firewall.  The CPAN tool will fetch a series of files, 
some quite large, as part of this setup process, so be patient...

NOTE: If you are behind a non-proxy-based firewall that requires the use of passive FTP, the initial downloads of files using Net::FTP may appear to hang - just wait 5 or more minutes, however, and the CPAN tool should eventually hit on ncftpget, which is part of Cygwin and does work OK. If this doesn't work and you are behind a typical NAT-based firewall, try doing the following at the Cygwin shell before running cpan - this forces Net::FTP to use passive FTP, letting it get through such firewalls: 

$ export FTP_PASSIVE=1
If this works, add this line to your ~/.profile file for future use.

Once some initial files are downloaded, you are asked to select your continent and country, and then mirror sites - just type the number of the mirror sites you want to use (pick a few in case one is down): 

...
(28) Turkey
(29) Ukraine
(30) United Kingdom

Select your country (or several nearby countries) [] 30

(1) ftp://cpan.teleglobe.net/pub/CPAN
(2) ftp://ftp.clockerz.net/pub/CPAN/
(3) ftp://ftp.demon.co.uk/pub/CPAN/
(4) ftp://ftp.flirble.org/pub/languages/perl/CPAN/
(5) ftp://ftp.mirror.ac.uk/sites/ftp.funet.fi/pub/languages/perl/CPAN/
(6) ftp://ftp.plig.org/pub/CPAN/
(7) ftp://mirror.uklinux.net/pub/CPAN/
(8) ftp://sunsite.doc.ic.ac.uk/packages/CPAN/
(9) ftp://usit.shef.ac.uk/pub/packages/CPAN/
Select as many URLs as you like,
put them on one line, separated by blanks [] 4 7 8

Enter another URL or RETURN to quit: []
New set of picks:
  ftp://ftp.flirble.org/pub/languages/perl/CPAN/
  ftp://mirror.uklinux.net/pub/CPAN/
  ftp://sunsite.doc.ic.ac.uk/packages/CPAN/

Eventually, you'll get to the CPAN tool's shell prompt, where you need to install a few modules - the tool will do all the work for you. 

cpan shell -- CPAN exploration and modules installation (v1.59_54)
cpan> install Net::SMTP
May already be installed - if it is, try 'force install', since it's useful to be able to set
firewall and passive FTP configuration when using Net::FTP.  Make sure you answer 'Y' to the question 
about whether you want to configure this package.
cpan> install Digest::SHA1
Lots of output about how CPAN finds, builds and installs the module - watch for 
any errors, though it should work fine if you have installed the Cygwin packages listed above (particularly 'gcc' and 'make').
cpan> install MIME::Base64
May already be installed.

Re-locking RCS files

7. Re-locking files

First, some testing: in your browser, go to http://yourdomain.com/bin/testenv - this provides a lot of detail, including warnings. Write down the Apache server's userid that is given by this script - typically either 'system' or 'administrator' - I'll assume 'system' from now on.

This 'system' user must own the locks on the RCS files, which are shipped with the lock held by 'nobody'. The reason this matters is that no revisions will be tracked by RCS unless the Apache userid matches that of the RCS file locks.

You can re-lock files using rcs -u and rcs -l, but it's a painfully manual process. Instead, just use Perl again to mass-edit all the RCS files, as follows: 

$ cd /twiki/data

$ : Make a backup of all files
$ tar czvf all-files.tar.gz */*

$ : Test edit a single file to check your typing
$ perl -pi~~~ -e 'NR <= 10 && s/nobody:/system:/ ' Main/WebIndex.txt,v

$ diff Main/WebIndex.txt,v Main/WebIndex.txt,v~~~
5c5
<       system:1.2; strict;
---
>       nobody:1.2; strict;

$ : Now edit all the RCS files at once - use cursor-up to recall previous command
$ perl -pi~~~ -e 'NR <= 10 && s/nobody:/system:/ ' */*,v

$ : Check for any remaining files not edited
$ grep 'strict;$' */*,v | grep -v system

$ : Clean up - type this very carefully 
$ rm */*~~~

You have now re-locked all the RCS files and are almost ready to start using TWiki!

Email setup

8. Email setup for notification and registration

You need to set the SMTPMAILHOST to an SMTP email host that is reachable and currently working. Otherwise you'll get a confusing message from TWiki when registering new users or running mailnotify (for Web Notify), along the lines of: 

   Software Error: Can't call method "mail" on an undefined value at ../lib/TWiki/Net.pm line 187.

There are other settings to be made in TWiki Preferences, e.g. the WIKIWEBMASTER and (probably) the SMTPSENDERHOST (normally your mail server or TWiki server). See the TWiki Installation Guide? for more details, what's listed here is just enough to let you run the basic tests.

Testing your TWiki installation

It is important to test your TWiki installation before you release it to other users or put any significant data into it.

Here are the main things to test:

Troubleshooting

If anything doesn't work, go back and check the configuration of the Apache httpd.conf file, and TWiki.cfg. Have a look at the Apache error log, c:/apache/logs/error_log, and the TWiki error log, /twiki/data/log*.txt, and if necessary enable debugging on selected scripts (the commands are right at the top of each script) - the results go into /twiki/data/debug.txt. There is also a /twiki/data/warning.txt file that contains less serious messages.

See TWiki:Codev.TWikiPatches in case there are patches (i.e. specific code changes) for particular problems that may affect you (e.g. TWiki:Codev.ChangePasswordOnWin2K).

If you find that the Index feature doesn't work, or topic name searches fail, you should check you have set $egrepCmd and $fgrepCmd correctly, as mentioned above.

Permissions

TWiki:Codev.CygWin has several models for how it does security:

I have not had any problems with TWiki permissions on Windows, unlike Linux/Unix, which is probably because I'm using the default security model for Cygwin. If you use the other models, you may still be OK if you have local admin rights, and Apache is running as the SYSTEM user (which it uses if started as a service). If you do have trouble in this area, see the TWiki Installation Guide?'s advice, some of which will apply to TWiki:Codev.CygWin, and log any issues in TWiki:Codev.WindowsInstallCookbookComments.

Next Steps

See the TWiki Installation Guide? for other setup. In particular, you'll probably want to refer to the section on basic authentication? - remember to use c:/twiki type filenames (i.e. Windows format) since you are using Apache for Windows.

Improved authentication

You may want to investigate TWiki:Codev.WindowsInstallModNTLM, which describes how to add an Apache module so that TWiki:Codev.InternetExplorer users are automatically authenticated based on their Windows domain login - this avoids TWiki:Codev.GettingTheUsernameWrong and TWiki:Codev.ForgettingPasswords, which are usually very common among TWiki users.

Improved performance

See TWiki:Codev.WindowsModPerlInstallCookbook and TWiki:Codev.ModPerl for information on installing TWiki under Apache's mod_perl - this is somewhat more complex and follows a different model, so it's best to get some experience with TWiki, Apache and Perl first.

Format of filenames

In your TWiki on Windows installation, it's worth remembering that:

Credits

Material in this cookbook is heavily based on the enormous number of contributions in TWiki:Codev.TWikiOnWindowsArchive and related topics - too many people to thank, but have a look at the contributor list to TWiki:Codev.TWikiOnWindowsArchive to get an idea!

People who've tested or reviewed this document and provided valuable feedback include:

ALERT! Comments welcome at TWiki:Codev.WindowsInstallCookbookComments

-- Peter Thoeny - 30 Jan 2003

TWiki Formatted Search Results

Inline search feature allows flexible formatting of search result

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

Syntax

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

1. header="..." parameter

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

2. format="..." parameter

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

Variables that can be used in the format string:

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
$text Formatted topic text
$locked LOCKED flag (if any)
$date Time stamp of last topic update, like 18 May 2013 - 05:29
$isodate Time stamp of last topic update, like 2013-05-18T05:29Z
$rev Number of last topic revision, like 1.4
$wikiusername Wiki user name of last topic update, like Main.JohnSmith
$username User name of last topic update, like JohnSmith
$summary Topic summary
$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 TWiki Form?
$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. For example, $pattern(.*?\*.*?Email\:\s*([^\n\r]+).*) extracts the email address from a bullet of format * Email: ....
$n or $n() New line
$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 ($)

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

Examples

Bullet list showing topic name and summary

Write this:

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

To get this:

Table showing form field values of topics with a form

Write this in the Know web:

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

To get this:

Topic: OperatingSystem: OsVersion:
IncorrectDllVersionW32PTH10DLL OsWin 95/98
WinDoze95Crash OsWin 95

Extract some text from a topic using regular expression

Write this:

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

To get this:

TWiki FAQs:

Nested Search

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

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

Write this:

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

To get this:

-- Peter Thoeny - 16 May 2002

TWiki Meta Data

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

Overview

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

Meta Data Syntax

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

Meta Data Specifications

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

META:TOPICINFO

Key Comment
version Same as RCS version
date integer, unx 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

META:TOPICMOVED

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

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

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, unx time, seconds since start 1970

Notes:

META:TOPICPARENT

Key Comment
name The topic from which this was created, Plugins.Plugins.WebHome if done from Go, othewise topic where ? or form used. Normally just topic, but is full web.topic format if parent is in a different Web. Renaming a Web will then only break a few of these references or they can be scanned and fixed.

META:FILEATTACHMENT

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, unx 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, unx time, seconds since start 1970

META:FORM

Key Comment
name A topic name - the topic represents one of the TWiki Forms?. Can optionally include the web name (i.e., web.topic), but doesn't normally

META:FIELD

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

Key Name
name Ties to entry in TWiki Forms? template, is title with all bar alphanumerics and . removed
title Full text from TWiki Forms? template
value Value user has supplied via form

Recommended Sequence

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

The recommended sequence is:

Viewing Meta Data in Page Source

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

Rendering Meta Data

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

Current support covers:

Variable usage: Comment:
%META{"form"}% Show form data, see TWiki Forms?.
%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 " > ".

Known Issues

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

-- John Talintyre - 29 Aug 2001
-- Mike Mannix - 03 Dec 2001
-- Peter Thoeny - 10 Jan 2002

TWiki Plugins

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

Overview

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

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

Preinstalled Plugins

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

Installing Plugins

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

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

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

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

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

On-Site Pretesting

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

Managing Plugins

When you finish installing a Plugin, you should be able to read the user instructions and go. In fact, some Plugins require additional settings or offer extra options that you have to select. Also, you may want to make a Plugin available only in certain webs, or temporarily disable it. And may want to list all available Plugins in certain topics. You can handle all of these management tasks with simple procedures.

Setting Preferences

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

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

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

  1. One line description, used to form the bullets describing the Plugins in the Text Formatting Rules? topic:
  2. Debug Plugin, output can be seen in data/debug.txt. Set to 0=off or 1=on:

Listing Active Plugins

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

DEMO: Automatically List Active Plugins Using Variables

Using %ACTIVATEDPLUGINS%:
On this TWiki site, the active Plugins are: Default Plugin, Find Elsewhere Plugin, Singleton Wiki Word Plugin, Beautifier Plugin, Headlines Plugin, Redirect Plugin, Smilies Plugin, Spread Sheet Plugin.

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

The TWiki Plugin API

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

Available Core Functions

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

ALERT! If you use functions not in Func.pm, you run the risk of creating security holes. Also, your Plugin will likely break and require updating when you upgrade to a new version of TWiki.

Predefined Hooks

In addition to TWiki core functions, Plugins can use predefined hooks, or call backs, listed in the lib/TWiki/Plugins/EmptyPlugin.pm module.

Plugin Version Detection

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

Creating Plugins

With a reasonable knowledge of the Perl scripting language, you can create new Plugins or modify and extend existing ones. Basic plug-in architecture uses an Application Programming Interface (API), a set of software instructions that allow external code to interact with the main program. The TWiki Plugin API Plugins by providing a programming interface for TWiki.

The DefaultPlugin Alternative

Anatomy of a Plugin

A basic TWiki Plugin consists of two elements:

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

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

Creating the Perl Module

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

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

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

Writing the Documentation Topic

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

  1. Copy the Plugin topic template from TWiki.org. To copy the text, go to TWiki:Plugins/PluginPackage and:
  2. Customize your Plugin topic.
  3. Save your topic, for use in packaging and publishing your Plugin.

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

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

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

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

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

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

Packaging for Distribution

A minimum Plugin release consists of a Perl module with a Wiki Name that ends in Plugin, ex: MyFirstPlugin.pm, and a documentation page with the same name(MyFirstPlugin.txt).

  1. Distribute the Plugin files in a directory structure that mirrors TWiki. If your Plugin uses additional files, include them ALL:
  2. Create a zip archive with the Plugin name (MyFirstPlugin.zip) and add the entire directory structure from Step 1. The archive should look like this:

Publishing for Public Use

You can release your tested, packaged Plugin to the TWiki community through the TWiki:Plugins web. All Plugins submitted to TWiki.org are available for download and further development in TWiki:Plugins. Publish your Plugin in three steps:

  1. Post the Plugin documentation topic in the TWiki:Plugins web:
  2. Attach the distribution zip file to the topic, ex: MyFirstPlugin.zip
  3. Link from the doc page to a new, blank page named after the Plugin, and ending in Dev, ex: MyFirstPluginDev. This is the discussion page for future development. (User support for Plugins is handled in TWiki:Support.)

-- Andrea Sterbini - 29 May 2001
-- Peter Thoeny - 29 Jan 2003
-- Mike Mannix - 03 Dec 2001

TWiki::Func Module Documentation

Official list of stable TWiki functions for Plugin developers

Description

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

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

Functions: CGI Environment

getSessionValue( $key ) ==> $value

Description: Get a session value from the Session Plugin (if installed)
Parameter: $key Session key
Return: $value Value associated with key; empty string if not set; undef if session plugin is not installed

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

Description: Set a session value via the Session Plugin (if installed)
Parameter: $key Session key
Parameter: $value Value associated with key
Return: $result "1" if success; undef if session plugin is not installed

getSkin( ) ==> $skin

Description: Get the name of the skin, set by the SKIN preferences variable or the skin CGI parameter
Return: $skin Name of skin, e.g. "gnu". Empty string if none

getUrlHost( ) ==> $host

Description: Get protocol, domain and optional port of script URL
Return: $host URL host, e.g. "http://example.com:80"

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

Description: Compose fully qualified URL
Parameter: $web Web name, e.g. "Main"
Parameter: $topic Topic name, e.g. "WebNotify"
Parameter: $script Script name, e.g. "view"
Return: $url URL, e.g. "http://example.com:80/cgi-bin/view.pl/Main/WebNotify"

getScriptUrlPath( ) ==> $path

Description: Get script URL path
Return: $path URL path of TWiki scripts, e.g. "/cgi-bin"

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

Description: Compose fully qualified view URL
Parameter: $web Web name, e.g. "Main". The current web is taken if empty
Parameter: $topic Topic name, e.g. "WebNotify"
Return: $url URL, e.g. "http://example.com:80/cgi-bin/view.pl/Main/WebNotify"

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

Description: Compose fully qualified "oops" dialog URL
Parameter: $web Web name, e.g. "Main". The current web is taken if empty
Parameter: $topic Topic name, e.g. "WebNotify"
Parameter: $template Oops template name, e.g. "oopslocked"
Parameter: $param1 ... $param4 Parameter values for %PARAM1% ... %PARAM4% variables in template, optional
Return: $url URL, e.g. "http://example.com:80/cgi-bin/oops.pl/ Main/WebNotify?template=oopslocked&param1=joe"

getPubUrlPath( ) ==> $path

Description: Get pub URL path
Return: $path URL path of pub directory, e.g. "/pub"

getCgiQuery( ) ==> $query

Description: Get CGI query object. Important: Plugins cannot assume that scripts run under CGI, Plugins must always test if the CGI query object is set
Return: $query CGI query object; or 0 if script is called as a shell script

writeHeader( $query )

Description: Prints a basic content-type HTML header for text/html to standard out
Parameter: $query CGI query object
Return: none

redirectCgiQuery( $query, $url )

Description: Redirect to URL
Parameter: $query CGI query object
Parameter: $url URL to redirect to
Return: none, never returns

Functions: Preferences

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

Description: Extract a named or unnamed value from a variable parameter string
Parameter: $attr Attribute string
Parameter: $name Name, optional
Return: $value Extracted value

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

Description: Get a preferences value from TWiki or from a Plugin
Parameter: $key Preferences key
Parameter: $web Name of web, optional. Current web if not specified; does not apply to settings of Plugin topics
Return: $value Preferences value; empty string if not set

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

Description: Get a preferences flag from TWiki or from a Plugin
Parameter: $key Preferences key
Parameter: $web Name of web, optional. Current web if not specified; does not apply to settings of Plugin topics
Return: $value Preferences flag "1" (if set), or "0" (for preferences values "off", "no" and "0")

getWikiToolName( ) ==> $name

Description: Get toolname as defined in TWiki.cfg
Return: $name Name of tool, e.g. "TWiki"

getMainWebname( ) ==> $name

Description: Get name of Main web as defined in TWiki.cfg
Return: $name Name, e.g. "Main"

getTwikiWebname( ) ==> $name

Description: Get name of TWiki documentation web as defined in TWiki.cfg
Return: $name Name, e.g. "TWiki"

Functions: User Handling and Access Control

getDefaultUserName( ) ==> $loginName

Description: Get default user name as defined in TWiki.cfg's $defaultUserName
Return: $loginName Default user name, e.g. "guest"

getWikiName( ) ==> $wikiName

Description: Get Wiki name of logged in user
Return: $wikiName Wiki Name, e.g. "JohnDoe"

getWikiUserName( $text ) ==> $wikiName

Description: Get Wiki name of logged in user with web prefix
Return: $wikiName Wiki Name, e.g. "Main.JohnDoe"

wikiToUserName( $wikiName ) ==> $loginName

Description: Translate a Wiki name to a login name based on Main.TWiki Users? topic
Parameter: $wikiName Wiki name, e.g. "Main.JohnDoe" or "JohnDoe"
Return: $loginName Login name of user, e.g. "jdoe"

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

Description: Translate a login name to a Wiki name based on Main.TWiki Users? topic
Parameter: $loginName Login name, e.g. "jdoe"
Parameter: $dontAddWeb Do not add web prefix if "1"
Return: $wikiName Wiki name of user, e.g. "Main.JohnDoe" or "JohnDoe"

isGuest( ) ==> $flag

Description: Test if logged in user is a guest
Return: $flag "1" if yes, "0" if not

permissionsSet( $web ) ==> $flag

Description: Test if any access restrictions are set for this web, ignoring settings on individual pages
Parameter: $web Web name, required, e.g. "Sandbox"
Return: $flag "1" if yes, "0" if no

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

Description: Check access permission for a topic based on the TWiki.TWiki Access Control? rules
Parameter: $type Access type, e.g. "VIEW", "CHANGE", "CREATE"
Parameter: $wikiName WikiName of remote user, i.e. "Main.PeterThoeny"
Parameter: $text Topic text, optional. If empty, topic $web.$topic is consulted
Parameter: $topic Topic name, required, e.g. "PrivateStuff"
Parameter: $web Web name, required, e.g. "Sandbox"
Return: $flag "1" if access may be granted, "0" if not

Functions: Content Handling

webExists( $web ) ==> $flag

Description: Test if web exists
Parameter: $web Web name, required, e.g. "Sandbox"
Return: $flag "1" if web exists, "0" if not

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

Description: Test if topic exists
Parameter: $web Web name, optional, e.g. "Main"
Parameter: $topic Topic name, required, e.g. "TokyoOffice", or "Main.TokyoOffice"
Return: $flag "1" if topic exists, "0" if not

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

Description: Get revision info of a topic
Parameter: $web Web name, optional, e.g. "Main"
Parameter: $topic Topic name, required, e.g. "TokyoOffice"
Return: ( $date, $loginName, $rev ) List with: ( last update date, login name of last user, minor part of top revision number ), e.g. ( "01 Jan 2003", "phoeny", "5" )

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

Description: Check if topic has an edit lock by a user
Parameter: $web Web name, e.g. "Main", or empty
Parameter: $topic Topic name, e.g. "MyTopic", or "Main.MyTopic"
Return: ( $oopsUrl, $loginName, $unlockTime ) The $oopsUrl for calling redirectCgiQuery(), user's $loginName, and estimated $unlockTime in minutes. The $oopsUrl and $loginName is empty if topic has no edit lock.

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

Description: Lock topic for editing, or unlock when done
Parameter: $web Web name, e.g. "Main", or empty
Parameter: $topic Topic name, e.g. "MyTopic", or "Main.MyTopic"
Parameter: $lock Set to 1 to lock topic, 0 to unlock
Return: $oopsUrl Empty string if OK; the $oopsUrl for calling redirectCgiQuery() in case lock is already taken when trying to lock topic

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

Description: Read topic text, including meta data
Parameter: $web Web name, e.g. "Main", or empty
Parameter: $topic Topic name, e.g. "MyTopic", or "Main.MyTopic"
Parameter: $rev Topic revision to read, optional. Specify the minor part of the revision, e.g. "5", not "1.5"; the top revision is returned if omitted or empty.
Parameter: $ignorePermissions Set to "1" if checkAccessPermission() is already performed and OK; an oops URL is returned if user has no permission
Return: $text Topic text with embedded meta data; an oops URL for calling redirectCgiQuery() is returned in case of an error

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

Description: Save topic text, typically obtained by readTopicText(). Topic data usually includes meta data; the file attachment meta data is replaced by the meta data from the topic file if it exists.
Parameter: $web Web name, e.g. "Main", or empty
Parameter: $topic Topic name, e.g. "MyTopic", or "Main.MyTopic"
Parameter: $text Topic text to save, assumed to include meta data
Parameter: $ignorePermissions Set to "1" if checkAccessPermission() is already performed and OK
Parameter: $dontNotify Set to "1" if not to notify users of the change
Return: $oopsUrl Empty string if OK; the $oopsUrl for calling redirectCgiQuery() in case of error

getPublicWebList( ) ==> @webs

Description: Get list of all public webs, e.g. all webs that do not have the NOSEARCHALL flag set in the WebPreferences
Return: @webs List of all public webs, e.g. ( "Main",  "Know", "TWiki" )

getTopicList( $web ) ==> @topics

Description: Get list of all topics in a web
Parameter: $web Web name, required, e.g. "Sandbox"
Return: @topics Topic list, e.g. ( "WebChanges",  "WebHome", "WebIndex", "WebNotify" )

Functions: Rendering

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

Description: Expand all common %VARIABLES%
Parameter: $text Text with variables to expand, e.g. "Current user is %WIKIUSER%"
Parameter: $topic Current topic name, e.g. "WebNotify"
Parameter: $web Web name, optional, e.g. "Main". The current web is taken if missing
Return: $text Expanded text, e.g. "Current user is TWikiGuest"

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

Description: Render text from TWiki markup into XHTML as defined in TWiki.Text Formatting Rules?
Parameter: $text Text to render, e.g. "*bold* text and =fixed font="
Parameter: $web Web name, optional, e.g. "Main". The current web is taken if missing
Return: $text XHTML text, e.g. "<b>bold</b> and <code>fixed font</code>"

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

Description: Render topic name and link label into an XHTML link. Normally you do not need to call this funtion, it is called internally by renderText()
Parameter: $pre Text occuring before the TWiki link syntax, optional
Parameter: $web Web name, required, e.g. "Main"
Parameter: $topic Topic name to link to, required, e.g. "WebNotify"
Parameter: $label Link label, required. Usually the same as $topic, e.g. "notify"
Parameter: $anchor Anchor, optional, e.g. "#Jump"
Parameter: $createLink Set to "1" to add question linked mark after topic name if topic does not exist;
set to "0" to suppress link for non-existing topics
Return: $text XHTML anchor, e.g. "<a href="/cgi-bin/view/Main/WebNotify#Jump">notify</a>"

search text( $text ) ==> $text

Description: This is not a function, just a how-to note. Use: expandCommonVariables("%SEARCH{...}%" );
Parameter: $text Search variable
Return: "$text" Search result in TWiki.Formatted Search format

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

Description: Format the time to GM time
Parameter: $time Time in epoc seconds
Parameter: $format Format type, optional. Default e.g. "31 Dec 2002 - 19:30", can be "iso" (e.g. "2002-12-31T19:30Z"), "rcs" (e.g. "2001/12/31 23:59:59", "http" for HTTP header format (e.g. "Thu, 23 Jul 1998 07:21:56 GMT")
Return: $text Formatted time string

Functions: File I/O

getDataDir( ) ==> $dir

Description: Get data directory (topic file root)
Return: $dir Data directory, e.g. "/twiki/data"

getPubDir( ) ==> $dir

Description: Get pub directory (file attachment root). Attachments are in $dir/Web/TopicName
Return: $dir Pub directory, e.g. "/htdocs/twiki/pub"

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

Description: Read a template or skin file. Embedded template directives? get expanded
Parameter: $name Template name, e.g. "view"
Parameter: $skin Skin name, optional, e.g. "print"
Return: $text Template text

readFile( $filename ) ==> $text

Description: Read text file, low level. NOTE: For topics use readTopicText()
Parameter: $filename Full path name of file
Return: $text Content of file

saveFile( $filename, $text )

Description: Save text file, low level. NOTE: For topics use saveTopicText()
Parameter: $filename Full path name of file
Parameter: $text Text to save
Return: none

writeWarning( $text )

Description: Log Warning that may require admin intervention to data/warning.txt
Parameter: $text Text to write; timestamp gets added
Return: none

writeDebug( $text )

Description: Log debug message to data/debug.txt
Parameter: $text Text to write; timestamp gets added
Return: none

Copyright and License

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

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

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

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

-- Peter Thoeny - 31 Dec 2002

TWiki Site Tools

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 email alerts when topics are edited, and WebStats, to generate detailed activity reports.

WebNotify Recent Changes Alert

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

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

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

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

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

Configuring Outgoing Mail

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

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

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

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

Setting the Automatic Email Schedule

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

% crontab -e
15,45 * * * * (cd ~twiki/public_html/bin; ./mailnotify -q)
The above line will call mailnotify at 15 minutes and 45 minutes past every hour. 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 NT/2000: You can use a scheduled task if you have administrative privileges. Note: AT on an NT machine is pretty limited. Microsoft lists several third-party replacements (as of 2001-11-20, none of them free).

WebStatistics Site Usage Log

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

Configuring for Automatic Operation

Generating Statistics Manually by URL

WebSearch

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

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

WebChanges

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

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

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

WebIndex

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

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

-- Mike Mannix - 01 Dec 2001
-- Peter Thoeny - 30 Jan 2003

Managing Webs

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

Overview

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

Choose Web Template

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

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

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

Adding a New Web

Create a new web by filling out this form. Note: It is not recommended to create a new web for each little project. You can organize content within a web using TWiki Forms? and Formatted Search. Cross-linking topics and search is easier if there are only a few larger webs.
Name of new web: Enter a short name of up to 10 characters. The name must start with one or more upper case letters, followed by optional lower case letters or numbers; it cannot be a Wiki Word?
Based on web: Select a Template Web
Web color: Enter a Standard Colors code for the web
Description:
 
 
Enter a short description of the web. Write Web.TopicName instead of just TopicName if you include links. This will list the web in the Site Map? (leave field empty if you prefer not to update the directory.)
Use to...
 
Continue the sentence describing the intended use. This is also for the Site Map?
Exclude web from "search all": No   Yes Specify if you want to exclude the web from a "search all webs" search. Note that the Site Map? will not list the web if you select Yes.
 

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

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

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

Renaming or Deleting a Web

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

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

  1. Prepare your site: Search each web for links to the target web, searching topic text for Oldwebname., including the dot so you'll find references like Oldwebname.SomeTopic.
  2. Edit the TWiki Preferences topic: Rename or delete the web from the WIKIWEBLIST variable.
  3. Login to the jEdit Community Wiki server, via Telnet or FTP.
  4. Go to twiki/data and rename or remove the web directory.
  5. Go to twiki/templates and rename or remove the web directory if present.
  6. Go to twiki/pub and rename or remove the web directory if present.

-- Mike Mannix - 14 Sep 2001
-- Peter Thoeny - 07 Apr 2002
-- Grant Bow - 16 Jan 2003

Topic TWikiDocumentation . { Edit | Attach | Ref-By | Printable | Diffs | r1.43 | > | r1.42 | > | r1.41 | More }
Revision r1.43 - 31 Jan 2003 - 07:15 GMT - Peter Thoeny Copyright © 1999-2011 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding jEdit Community Wiki? Send feedback. Get jEdit at !SourceForge.net. Fast, secure and Free Open Source software downloads