Reference Manual (v1.1.9)

This page contains all documentation topics as one long, complete reference sheet.

Related Topics: UserDocumentationCategory, AdminDocumentationCategory

---

Low client and server base requirements are core features that keep Foswiki widely deployable, particularly across a range of browser platforms and versions. Many extensions exist which enhance and expand Foswiki's capabilities; they may have additional requirements.

Server Requirements

Foswiki is written in Perl 5, which is supported on Microsoft Windows as well as Unix and Unix-like systems (including Linux and OSX), on which it uses a number of shell commands and RCS (Revision Control System), a GNU Free Software package. It should be able to run on any server platform that meets the following requirements.

Resource	Required Server Environment
Perl	5.8.8 or higher
RCS (Revision Control System)	5.7 or higher (including GNU diff) Optional. Foswiki includes a pure Perl implementation of RCS (RcsLite) that can be used instead, at the cost of performance
GNU diff	GNU diff 2.7 or higher is required when not using the all-Perl RcsLite. Install within the PATH if not included with RCS (check version with diff -v) Must be the version used by RCS, to avoid problems with binary attachments - RCS may have hard-coded path to diff
Other external programs	fgrep, egrep
Cron/scheduler	• Unix: cron • Windows: cron equivalents
Web server	Apache is well supported; for information on other servers, see Foswiki:Support.InstallingOnSpecificPlatforms.

Perl Modules

A complete list of the required and optional Perl modules can be found in lib/DEPENDENCIES.

The following CPAN modules are not shipped with Foswiki. Note that Foswiki extensions may add additional requirements. Modules marked as Required may still be optional if certain default core features are not used.

Module	Required/Optional	Description
CPAN:HTML::Entities	Required	Used for WYSIWYG Editing
CPAN:HTML::Parser	Required	Used for WYSIWYG Editing
CPAN:HTML::Tree	Required	Used by CompareRevisionsAddOn.
CPAN:URI	Required	Used by MailerContrib for email notifications of topic changes.
CPAN:LWP	Required	Used by the Configure Extensions Installer, and for external URL based INCLUDEs
CPAN:version	Required	version >= 0.77 required for module version checks
CPAN:Digest::SHA	Optional	Required to use SHA1 password encoding, since Perl 5.9.3 part of core
CPAN:Digest::SHA1	Optional	Required by the Foswiki PageCaching feature
CPAN:Win32::Console	Optional	May be required for Internationalization on Windows
CPAN:Archive::Tar	Optional	Required by the Extensions Installer in configure if command line tar or unzip is not available, since Perl 5.9.3 part of core.
CPAN:Archive::Zip	Optional	Alternative to Archive::Tar, used by the Extensions Installer if Archive::Tar and command line tar and unzip also unavailable
CPAN:Net::SMTP::SSL	Optional	Required by Net::SMPT to send email over SSL to providers such as gmail.
CPAN:Authen::SASL	Optional	Required by Net::SMTP if email server requires authentication.

Most of them will probably already be available in your installation. You can check version numbers with the configure script, or if you're still trying to get to that point, check from the command line like this:

perl -e 'use FileHandle; print $FileHandle::VERSION."\n"'

For more detailed dependency information, try the script dependencies_installer.pl located in the tools directory, which makes perl module installation easier. Run it with option -h to understand basics. This script requires confirmation before it actually does something.

Specific distribution details

Ubuntu and other Debian derived distributions

RedHat, SuSE, CentOS and other RPM based distributions

Client Requirements

The standard installation has relatively low browser requirements:

• XHTML 1.0 Transitional compliant
• Cookies, if persistent sessions are required
• Javascript, for edit/save/upload functionality

  Change {ValidationMethod}{Method} from strikeone to embedded in configure to allow non-javascript browsers to edit/save/upload

CSS and Javascript are used in most skins. Some skins will require more recent releases of browsers. The default skin is tested on IE 6+, Safari, Chrome and Firefox.

You can easily select a balance of browser capability versus look and feel. Try the installed skins at SkinBrowser and more at Foswiki:Extensions.SkinPackage.

Back to top

---

Installation Guide

This guide describes the steps for manually installing Foswiki, with specific steps for installations on Linux with the Apache web server.

• If you are using one of the automated installers or operating system-specific packages at Foswiki:Download.OtherFoswikiInstallers, refer to the instructions specific to those installers/packages in the first instance;
• Are you manually installing on a different web server or operating system? Would you like more information about performance tuning, security hardening or shared webhosting environments? This guide contains information relevant to most installation scenarios. For topics not covered here please consult Foswiki:Support.SupplementalDocuments

This guide is divided into two parts - included here as a single complete reference. Installation Guide Part 1 documents the preparation steps used to make Foswiki initially operational. It is included in the root of your Foswiki distribution as a static HTML document - INSTALL.html Installation Guide Part 2 continues with steps for tailoring and enhancing your site.

These installation instructions are also available online at Foswiki:System.InstallationGuide, and are available within your Foswiki installation at System.InstallationGuide (the InstallationGuide topic in the System web).

For information on upgrades, please also refer to Foswiki:System.UpgradeGuide. A static HTML version of this document, UpgradeGuide.html, is included in the root of your Foswiki distribution.

Initial Installation

System Requirements

Please see the section "Foswiki system requirements" for the server and client requirements to run Foswiki, including the Perl modules required on the server. If you need to install any Perl libraries from CPAN for use by Foswiki, see Foswiki:Support.HowToInstallCpanModules for more information.

Preparing to install

Before attempting to install Foswiki, you are encouraged to review the Foswiki:System.AdminSkillsAssumptions. This guide assumes the person installing Foswiki has a basic knowledge of server administration on the system on which Foswiki is to be installed. While it is possible to install Foswiki with FTP access alone (for example, on a hosted site), it is tricky and may require additional support from your hosting service (for example, in setting file ownership and installing missing perl CPAN libraries).

If you are upgrading from a previous Foswiki version or from a TWiki installation, please refer to Foswiki:System.UpgradeGuide. A static HTML version of this document, UpgradeGuide.html, is included in the root of your Foswiki distribution.

Verify that your server meets the Foswiki system requirements, including having the minimum required Perl version and all required Perl modules installed. If you need to install any Perl libraries from CPAN for use by Foswiki, see Foswiki:Support.HowToInstallCpanModules for more information.

If you need help, feel free to ask a question in the Foswiki:Support web or on Foswiki:Community.InternetRelayChat (irc.freenode.net, channel #foswiki).

Basic installation: getting Foswiki up and running

To install Foswiki, complete the following steps:

1. Download and unpack the Foswiki distribution.
2. Set the file and directory permissions for the installation.
3. Configure the locations of the Perl executable and the Foswiki modules.
4. Configure the web server.
5. Configure Foswiki.
6. Enable authentication of users (if desired).
7. Define the administrator users.

Download and unpack the Foswiki distribution

Download the Foswiki distribution from http://foswiki.org/Download

Unpack the distribution file: Change to the directory where you want to place the Foswiki directory. Unzip or untar and gunzip the distribution; a new subdirectory called Foswiki-VERSION will be created. You can rename this subdirectory to a shorter name. For the rest of this document, this subdirectory is assumed to be at /path/to/foswiki.

• Note: Foswiki does not support directory paths that contain spaces, so ensure that all of its directory paths do not contain any spaces (particularly on Windows).

If you do not have shell access to your web server host, see the section "Uploading the Foswiki distribution to your web server host".

(Not applicable on Windows) Set the file and directory permissions for the installation

Set up access file and directory rights, as well as file ownership, as required by your web server configuration so that the web server user (the user used by the web server to run CGI programs) can read and write within the foswiki directory tree.

Note: for more information on the appropriate permissions to ensure security for your Foswiki data, see Foswiki:Support.SecuringYourSite.

The default file and directory access permissions as set by the distribution define a reasonable security level that will work for many types of installations, including shared hosting. Nonetheless, you should verify that the web server user has read access to all files and directories beneath the foswiki directory, and execute access for all directories. Also verify that the data and pub directories and all the subdirectories and files beneath them allow write access for the web server user.

• Warning: Do not just run a chmod -R 770 foswiki. Providing execute access to all files is potentially dangerous. This is a common mistake made by Foswiki installers. See Foswiki:Support.SettingFileAccessRightsLinuxUnix for a sample set of Unix commands to set the file and directory permissions.

It is possible to define tighter access permissions than the default ones; how tight they should be depends on your web server environment and local needs. Typically you should limit all access from others if the web server machine has login access for users other than root and the web server administrator. For a dedicated web server that just runs Foswiki and has limited login access, the default access permissions have a good safety level.

If you have root user permissions, then for additional security, you can change the ownership of the foswiki directory tree to the web server user, using the command chown -R user:group /path/to/foswiki. The web server username varies in different installations; here are some sample commands for various Linux distributions:

• RedHat, Fedora, CentOS, Gentoo, Mandriva : chown -R apache:apache /path/to/foswiki
• debian/Ubuntu/Kubuntu : chown -R www-data:www-data /path/to/foswiki
• Suse : chown -R wwwrun:www /path/to/foswiki

If Foswiki stops working after you applied a change in access permissions and you wish to restore the original permissions, run the Unix commands located at Foswiki:Support.SettingFileAccessRightsLinuxUnix.

(optional - required on Windows ) Configure the locations of the Perl executable and the Foswiki modules

If you are running on a Linux system with Perl found in /usr/bin/perl then this step is not required. This step is required on Windows installations.

The easiest way to fix up the bin scripts is to run the tools/rewriteshebang.pl script. If the Perl interpreter is in the default execution path, follow these steps:

cd /path/to/foswiki/tools
perl -I ../lib rewriteshebang.pl

or for Windows users:

cd C:\path\to\foswiki\tools
perl -I ..\lib  rewriteshebang.pl

The script will determine the location of the Perl interpreter and will prompt to update both the bin and tools scripts in a single step. The changed files will be reported, and it is safe to rerun the script.

If the perl command does not work from the command line, then you need to find the location of your system's Perl interpreter. Insert the path to Perl in the first line of the rewriteshebang script. For example:

cd C:\path\to\foswiki\tools
C:\path\to\perl -I ..\lib  rewriteshebang.pl

(optional) Configuration of a script suffix for the perl scripts

Some web servers require a special extension on perl script files (e.g. .cgi or .pl). This is not normally required with the Apache web server, though some hosted web servers are configured to require it. If the documentation for your web server indicates that a special extension is necessary, rename all the executable scripts in bin; that is, rename bin/view to bin/view.pl, and so on. When configuring Foswiki (see the section "Configure Foswiki"), set the ScriptSuffix option to the special extension.

(optional) Configuration for non-standard library locations

A standard Foswiki install has the directories bin/ and lib/ located under the Foswiki installation directory. If you have moved these directories, or if your system requires changes to the default Perl libraries, then this step is required.

Create the file LocalLib.cfg located at bin/LocalLib.cfg

• In the bin directory, copy the template file LocalLib.cfg.txt to LocalLib.cfg. Make sure the ownership and access rights of the copy are the same as LocalLib.cfg.txt.
• Edit bin/LocalLib.cfg so that $foswikiLibPath is set to the absolute file path of your lib directory. For example: /path/to/foswiki/lib.
• If you need to install additional CPAN modules, but can't update the main Perl installation files on the server, you can set $CPANBASE to point to your personal CPAN install. Don't forget that the web server user has to be able to read those files as well.

Configure the web server

First choose the best configuration method for your web server. With Apache, there are two ways to configure it: a config file included from httpd.conf or .htaccess files.

• Apache config file: The recommended method is using a config file. With a config file you can put the entire Foswiki configuration in ONE file (typically named foswiki.conf). Performance is much better with a config file, and one file gives the best overview and ensures that you get a safe installation . However to use a config file you need root or sudo access to stop and start Apache. The Foswiki apache config file can be included from the main Apache config file. (Typically httpd.conf or apache.conf depending on your distribution). However most distributions have a directory from which any file that ends with .conf gets included when you restart Apache (Example RedHat/Fedora/Centos: /etc/httpd/conf.d, Gentoo: /etc/apache2/vhost.d ). If you use a virtual host setup in Apache you should include the foswiki.conf file from inside the desired virtual host config in your Apache configuration.
• .htaccess files: This method should only be used when you cannot use a config file. Performance is slower as Apache must search through all applicable directories for any .htaccess files on each page access. Normally this is the only way to control Apache in a shared host environment where you have no root or sudo privileges.

If you are using a config file:

• The easiest and best way is to use the Foswiki:Support.ApacheConfigGenerator tool to generate a safe, working config file for your Foswiki installation, based on the options you choose in the tool.
• If you can't use the online configuration generator, a sample config file called foswiki_httpd_conf.txt can be found in the root of the foswiki installation.
• Ensure that web access is denied to all Foswiki subdirectories other than bin and pub.
  • The Foswiki:Support.ApacheConfigGenerator tool will generate the appropriate settings;
  • the foswiki_httpd_conf.txt file also has examples of configuring Apache appropriately.
• Ensure there is either a ScriptAlias directive for the bin subdirectory, or an Alias directive with SetHandler cgi-script and Options ExecCGI directives for the bin subdirectory, so that the bin scripts will be executed by Apache.
• Note: you must restart Apache after making changes to your config files for the changes to take effect.

If you are using a .htaccess file:

• In the root of the foswiki installation, there are sample .htaccess files for various subdirectories in your installation. Each file has help text explaining how to modify it for your configuration. For more information, see Foswiki:Support.SupplementalDocuments.

  location and name of sample .htaccess file	copy sample file to the following location
  foswiki/root-htaccess.txt	foswiki/.htaccess
  foswiki/bin-htaccess.txt	foswiki/bin/.htaccess
  foswiki/pub-htaccess.txt	foswiki/pub/.htaccess
  foswiki/subdir-htaccess.txt	foswiki/<subdir>/.htaccess Copy to all other subdirectories below foswiki, including data, lib, locale, templates, tools, working. Copy to any other directories except for bin and pub addressed above.

• Ensure that web access is denied to all Foswiki subdirectories other than bin and pub. The sample .htaccess files show how to configure Apache appropriately. It is important to verify that none of these directories can be directly accessed.
• Ensure that the foswiki/bin/.htaccess files contains the line SetHandler cgi-script so that all scripts in the bin directory will be executed by Apache.
• Note: On Linux systems, files named with the leading "." like .htaccess are hidden files and will not be listed unless using the -a option, ex. ls -la

Turn off any kind of PHP, Perl, Python, Server Side Includes, or other software execution mechanisms supported by your web server in the pub directory. For example, most Linux distributions have a default Apache installation with PHP and server side include (SSI) enabled. This would allow PHP scripts uploaded as attachments to be executed, which is a security risk, so it should be disabled in the Apache configuration with php_admin_flag engine off.

Different script execution mechanisms are disabled in different ways; see your web server configuration and documentation for more details.

Protect the configure script!

You should never leave the configure script open to the public. Limit access to the bin/configure script to either localhost, an IP address or a specific user using basic Apache authentication. The Foswiki:Support.ApacheConfigGenerator lets you setup who has access to the configure script. Also see the foswiki-httpd-conf.txt or bin/.htaccess.txt file for an example of the setting required to protect the configure script.

To limit access to a particular user, set up a .htpasswd file that contains the user name and password that Apache will use to authenticate the user:

• Caution! Do not follow these steps on an existing Foswiki .htpasswd file. It will destroy the email addresses stored in that file! If the file already exists, you can choose an existing user for access to configure.
• Change to the foswiki/data directory.
• Issue the command htpasswd -c .htpasswd <username>, where <username> is the name of the user you will use to access the configure script. Choose the username with care: the username cannot be an existing login name for your Foswiki installation, nor can it be used later on to register in Foswiki. Enter a password when prompted.

All of the above methods - Sample configuration files, Foswiki:Support.ApacheConfigGenerator and sample .htaccess files, all include example settings to protect the configure script with a password. The critical section looks something like:

<FilesMatch "configure.*">
    SetHandler cgi-script
    Order Deny,Allow
    Deny from all
    # List of IP addresses allowed to access configure
    Allow from 127.0.0.1 192.168.1.10
    # specify username used on the "htpasswd" command above
    Require user someuserid
    # Set to "Any" to allow IP -or- userid,  set to "All" to require both match
    Satisfy Any
    ErrorDocument 401 default
</FilesMatch>

Note: In addition to any web server security protection that you have set up, when saving any configuration settings for the first time on the configure web page, you will be prompted to set a configuration password. This password must be entered on all subsequent configuration changes, and is also used to log in via the internal admin link (see the section "Define the administrator user(s)"). Even after a configure password has been set, access to the configure page should still be restricted by the web server, in order to avoid revealing internal information to potential attackers.

Tip: You do not have to use the same password file for both Configure and for Foswiki user registration. If you use a separate file, you can create it using the htpasswd commmand and complete segregate configure access from Foswiki access. This is probably safer, but does not allow users to change their configure password using Foswiki services. The password file has to be manually maintained..

1. Generate an alternate password file to protect configure. htpasswd -c -s /path/to/data/.htpasswd-admin configuserid
2. Add / modify and delete this alternate file using the htpasswd command. Don't mix them up and use htpasswd on the Foswiki .htpasswd file!
3. Edit the foswiki apache configuration and modify the block (shown above) that protects the configuration command. Add or modify the following statements in the block. Don't remove the other statements!

<FilesMatch "configure.*">
        AuthType Basic
        AuthName "admins only"
        AuthUserFile /path/to/data/.htpasswd-admin
        # Changing the Require user to Require valid-user allows any ID in the
        # file access to configure!
        Require valid-user
</FilesMatch>

For more information, refer to Foswiki:Support.ProtectingYourConfiguration.

Configure Foswiki

Run the configure script from your browser: enter http://yourdomain/url/to/foswiki/bin/configure into your browser address bar.

• When you access the configure web page for the first time, you can only edit the section General Path Settings. Make any required changes, and save the settings, whether or not you needed to make any changes. You will be prompted to set a password for the configure page: this password must be entered for all subsequent configuration changes, and is also used to log in via the internal admin link (see the section "Define the administrator user(s)").

  Note: The configure password is remembered by configure, separate to web server access controls mentioned in "Protect the configure script".

• After saving the General Path Settings, continue configuring Foswiki. Configuration items which may require further attention will be highlighted.
• If the Foswiki installation can be accessed by more than one protocol://domain, ensure the additional alternative URLs are set in {PermittedRedirectHostUrls}.

  Example: if {DefaultUrlHost} is set to https://wiki.company.com, an example {PermittedRedirectHostUrls} might contain:

  https://company.com, http://111.222.123.234

• Setup the Mail and Proxies section. Email must be available so Foswiki can send registration emails.
  • Under the "Email General" tab, If you do not want to enable sending registration emails or want to enable it later you can uncheck {EnableEmail}. Otherwise the {WebMasterEmail} parameter must be configured.
  • Under the "Email Server" tab, you can choose 3 methods of sending email. This is explained in detail under the help text for this tab.
    • MailProgram is typically suitable on most Linux systems, and no further configuration is required.
    • If you chose either of the Net::SMPT methods, you must also configure {SMTP}{MAILHOST}. Many ISPs have introduced authentication when sending emails to fight spam so you may also have to set {SMTP}{Username} and {SMTP}{Password}.
    • Net::SMTP::SSL will encrypt the connection to the e-mail server and is required for some email services like Google's GMail.
  • Under the "Proxy" tab, if your server is behind a firewall with a proxy, and you wish to install extensions via configure, you may have to set {PROXY}{HOST} and {PROXY}{PORT}.

    Note: A standard Foswiki installation will not allow any new registrations unless there is a working SMTP configuration

    SMTP authentication requires additional perl modules including Authen::SASL and MIME::Base64,

If there is a problem with your setup that prevents you from accessing the configure page, you can configure Foswiki manually.

Authentication

Authentication of users means their activity can be tracked, and access to your site can be controlled. This is particularly important for sites that are publicly accessible on the web. You are strongly encouraged to read System.UserAuthentication and Foswiki:Support.UserAuthenticationSupplement for further information about managing users and access controls for your Foswiki site.

The most common authentication methods used for public Foswiki installations are Template Login and Apache Login. They have the following relative advantages:

• Template Login can be set up without any web server configuration, and users can log off without restarting the browser. As the login page is just a Wiki page, you can customize it to suit your needs.
• Apache Login allows you to use any Apache-module based authentication scheme, such as mod_auth_ldap or mod_auth_mysql. However, as your browser is caching your login, you must restart the browser to log out.

Note that the password databases for both of these authentication mechanisms are compatible, so you can switch between them at a later date.

To make it easier to follow the instructions in this section, you can view this installation guide using your Foswiki site by entering System.InstallationGuide into the "Jump" text box. By doing this instead of using the INSTALL.html file from the distribution, you will be able to use the embedded hyperlinks to jump directly to the referenced pages.

Template Login authentication

Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out. Client Sessions are used to remember users. Users can choose to have their session remembered so they will automatically be logged in the next time they start their browser.

Enabling Template Login

By default, your Foswiki installation is probably already using TemplateLogin, HtPasswdUser and TopicUserMappingContrib as the default Login, Password and user mapping options.

1. Using configure:
   1. Navigate to the Login tab on the Security and Authentication panel. Select the Foswiki::LoginManager::TemplateLogin login manager.
   2. Navigate to the Passwords tab. Select the appropriate PasswordManager for your system - the default is Foswiki::Users::HtPasswdUser.

      There is also an EXPERT configure setting {TemplateLogin}{PreventBrowserRememberingPassword} that you can set to prevent Browsers from remembering username and passwords if you are concerned about public terminal usage.

2. Verify that registration works by registering yourself with the System.UserRegistration topic. If there are problems, try these troubleshooting tips:
   1. If you are reading this from the INSTALL.html file, you can enter System.UserRegistration into the 'Jump' box in the top right of any Foswiki page.
   2. Note: A standard Foswiki installation will not allow any new registrations unless there is a working SMTP configuration
   3. If your PasswordManager is HtPasswdUser (the default), check the .htpasswd file is being updated correctly with a new entry. If not, check {Htpasswd}{FileName} is correct (under Security and Authentication on the Password tab in configure), and that the webserver user has write permission.
3. Create a new topic (in Sandbox web for example) to confirm that authentication works.
4. Add users to the Main.AdminGroup. Edit the Main.AdminGroup topic in the Main web to include users that should have administrator status. Read defining adminstrator user(s) for more information.

   This is a very important step, as users in this group can access all topics, independent of BACCHUS Wiki access controls.

AccessControl has more information on setting up access controls.

Foswiki AccessControls do not protect topic attachments unless the web server has been configured to do so using the viewfile script. Visit Foswiki:Support.ApacheConfigGenerator for examples using Apache.

As Template Login uses a wiki page for its login prompt, there is a great deal of flexibility in customizing the login page for your purposes.

The default new user template page is in System.NewUserTemplate. The same macros get expanded as in the template topics. You can create a custom new user topic by creating the NewUserTemplate topic in Main web, which will then override the default in System web. See System.UserForm for copy instructions.

Custom registration page

You can customize the default System.UserRegistration topic by first copying System.DefaultUserRegistration to UserRegistration in Main web. This will ensure that your changes will remain intact next time you upgrade.

A couple of common fields are hidden from normal view to make the registration page as lean as possible. You can unhide those fields on the page by removing EXCLUDED_ from the INCLUDE tags) or add new ones.

New fields may also be added. The name="" parameter of the <input> tags must start with: "Fwk0..." (if this is an optional entry), or "Fwk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.

Automatic Group Membership

The TopicUserMappingContrib can also enroll users into groups during registration. (Other mappers might not support this feature). Options include:

• Automatically enrolling users in one or more groups during registration
• Allow the user to select multiple groups from a list of eligible groups
• Allow the user to choose only one group from a list of eligible groups
• Don't do any group enrollment during registration.

The list of eligible groups can be generated in one of two ways:

• Manually by configuration. This fixed list of groups will always be listed.
• Automatically based upon CHANGE permission on the group topics.

There are two registration scenarios that apply:

Self-registration by Guest users

The actual registration will be processed by the special internal user Main.RegistrationAgent. Group topics must include an ALLOWTOPICCHANGE = Main.RegistrationAgent to be eligible for enrollment.

Registration by logged-in users

The registration form is filled out by some other logged-in user. In this case, the Main.RegistrationAgent is not used for Group updates. The current user must have ALLOWTOPICCHANGE permission for groups for them to be eligible for enrollment.

• Caution: If an administrator registers a user with automatic group membership enabled, the new user could potentially be added to All groups. Use caution with this feature!

Note: During registration, if it turns out that the current user or Main.RegistrationAgent doesn't have permission to update the group topic, the group update will be silently skipped. The user will still be albe to register.

See DefaultPreferences#RegistrationOptions for further details. Copy the settings into Main.SitePreferences to make them active.

Apache Login authentication

With Apache Login enabled, when Foswiki needs to authenticate the user, the standard HTTP authentication mechanism is used: the browser itself will prompt for a user name and password.

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

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

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

The same private .htpasswd file used in BACCHUS Wiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support.

Do not use the Apache htpasswd program with .htpasswd files generated by BACCHUS Wiki! htpasswd wipes out email addresses that BACCHUS Wiki plants in the info fields of this file.

Apache Login is required for Apache-based login methods such as mod_ldap

You can use any Apache authentication module that sets the REMOTE_USER environment variable.

To setup Apache Login, perform the following steps:

1. Configure Apache Login. Under the Security and Authentication pane on the Login tab in configure:
   1. Select Foswiki::LoginManager::ApacheLogin for {LoginManager}.
   2. Select Foswiki::Users::HtPasswdUser for {PasswordManager}.
   3. Select Foswiki::Users::TopicUserMapping for {UserMappingManager}.
   4. Save your settings.
   5. Configure your Apache settings for HTTP authentication. Use the Foswiki:Support.ApacheConfigGenerator tool or the foswiki/bin-htaccess.txt file to set the following Apache directives on the bin scripts:

       <FilesMatch "(attach|edit|manage|rename|save|upload|mail|logon|rest|.*auth).*">
       require valid-user
       </FilesMatch>

      You can also refer to the sample foswiki_httpd_conf.txt and bin-htaccess.txt files to see how the appropriate Apache directives are specified.
2. Verify that registration works by registering yourself with the System.UserRegistration topic. If there are problems, try these troubleshooting tips:
   1. If you are reading this from the INSTALL.html file, you can enter System.UserRegistration into the 'Jump' box in the top right of any Foswiki page.
   2. Note: A standard Foswiki installation will not allow any new registrations unless there is a working SMTP configuration
   3. If your PasswordManager is HtPasswdUser (the default), check the .htpasswd file is being updated correctly with a new entry. If not, check {Htpasswd}{FileName} is correct (under Security and Authentication on the Password tab in configure), and that the webserver user has write permission.
3. Create a new topic (in Sandbox web for example) to confirm that authentication works.
4. Add users to the Main.AdminGroup. Edit the Main.AdminGroup topic in the Main web to include users that should have administrator status. Read defining adminstrator user(s) for more information.

   This is a very important step, as users in this group can access all topics, independent of BACCHUS Wiki access controls.

Choose an appropriate search algorithm for your Operating System

On the Store pane in configure you will find the setting {RCS}{SearchAlgorithm}.

By default it is set to Foswiki::Store::SearchAlgorithms::Forking which is what you should keep if you install Foswiki in Linux or any other Unix type operating system.

If you install Foswiki on a Windows server, using an external grep program can create problems because of limitations in the length of command lines. You may be able to run with Forking in Windows if your directory path to Foswiki is kept short (short directory names and few levels), however the recommended (safe) setting for Windows is Foswiki::Store::SearchAlgorithms::PurePerl.

Define the administrator user(s)

About Administrators

Administrators have read and write access to any topic, regardless of any access controls that have been applied to the topic or its web. The special user Main.AdminUser ships with Foswiki and is accessed using by logging in with user admin and the password established when initially saving the configuration. Don't log in with the wikiname AdminUser.

After installing Foswiki, you can also register other users that you will use to administer Foswiki. To make a user an administrator, add the WikiName for the user to the AdminGroup, defined in the Main.AdminGroup topic in your Foswiki installation.

Note that with the sudo or internal admin login, it is not necessary to add other users to the AdminGroup. However if you have more than one administrator, you may still want to do this to ensure that topic changes are attributed to a specific user instead of the default Main.AdminUser.

By adding users to Main.AdminGroup:

• Users with Admin rights will have routine access to topics that might normally be denied.
• These users will be unable to test or demonstrate access controls.
• Changes made are always attributed to a unique logged in user.
• Password sharing of the bin/configure password is not required

By using the internal admin login:

• You don't need to grant admin rights to individual users
• All users will be subject to access controls.
• Changes made while using the internal admin login are attributed to Main.AdminUser
• The "save" password for bin/configure will need to be shared among administrators

Adding users to the Main.AdminGroup

To make it easier to follow the instructions in this section, you can view this installation guide using your Foswiki site by entering System.InstallationGuide into the "Jump" text box. By doing this instead of using the INSTALL.html file from the distribution, you will be able to use the embedded hyperlinks to jump directly to the referenced pages.

To add an initial administrator to the AdminGroup, perform the following steps:

• If you are not already logged in with your WikiName, then login.
• Go to the Main.AdminGroup topic and select the "internal admin login" link. Login using the password you set on the configure page.
• After logging as the internal admin, view the Main.AdminGroup topic. Follow the instructions on the page to add users to the AdminGroup. You do not need to edit the topic.

Any member of the Main.AdminGroup can add subsequent members — you do not have to use the internal admin login.

To more easily debug access control issues, you may want to have a regular Foswiki user account for daily use, and a special one that belongs to the AdminGroup that you use only for administering your Foswiki site. See System.AccessControls for more information on access controls and user groups.

Congratulations!

You now have a basic installation running. At this point you can just point your Web browser at http://yourdomain.com/url/to/foswiki/bin/view/System/InstallationGuidePart2 to proceed with further tailoring your site..

In order to keep your user, group, and site configuration information separate from the actual content of your site, it is recommended that you create a new web in which your site's pages will reside. See System.ManagingWebs for more information on Wiki webs and how to create one.

Troubleshooting

• Re-run the configure script and make sure you have resolved all errors and are satisfied that you understand any warnings.
• Follow the steps detailed in FAQTroubleshootingExtensions
• Failing that, consult the topics at Foswiki:Support.SupplementalDocuments and Foswiki:Support.AskedQuestions.
• If you need help, ask a question in the Foswiki:Support web or on Foswiki:Community.InternetRelayChat (irc.freenode.net, channel #foswiki).

Foswiki system requirements

Low client and server base requirements are core features that keep Foswiki widely deployable, particularly across a range of browser platforms and versions. Many extensions exist which enhance and expand Foswiki's capabilities; they may have additional requirements.

Server Requirements

Foswiki is written in Perl 5, which is supported on Microsoft Windows as well as Unix and Unix-like systems (including Linux and OSX), on which it uses a number of shell commands and RCS (Revision Control System), a GNU Free Software package. It should be able to run on any server platform that meets the following requirements.

Resource	Required Server Environment
Perl	5.8.8 or higher
RCS (Revision Control System)	5.7 or higher (including GNU diff) Optional. Foswiki includes a pure Perl implementation of RCS (RcsLite) that can be used instead, at the cost of performance
GNU diff	GNU diff 2.7 or higher is required when not using the all-Perl RcsLite. Install within the PATH if not included with RCS (check version with diff -v) Must be the version used by RCS, to avoid problems with binary attachments - RCS may have hard-coded path to diff
Other external programs	fgrep, egrep
Cron/scheduler	• Unix: cron • Windows: cron equivalents
Web server	Apache is well supported; for information on other servers, see Foswiki:Support.InstallingOnSpecificPlatforms.

Perl Modules

A complete list of the required and optional Perl modules can be found in lib/DEPENDENCIES.

The following CPAN modules are not shipped with Foswiki. Note that Foswiki extensions may add additional requirements. Modules marked as Required may still be optional if certain default core features are not used.

Module	Required/Optional	Description
CPAN:HTML::Entities	Required	Used for WYSIWYG Editing
CPAN:HTML::Parser	Required	Used for WYSIWYG Editing
CPAN:HTML::Tree	Required	Used by CompareRevisionsAddOn.
CPAN:URI	Required	Used by MailerContrib for email notifications of topic changes.
CPAN:LWP	Required	Used by the Configure Extensions Installer, and for external URL based INCLUDEs
CPAN:version	Required	version >= 0.77 required for module version checks
CPAN:Digest::SHA	Optional	Required to use SHA1 password encoding, since Perl 5.9.3 part of core
CPAN:Digest::SHA1	Optional	Required by the Foswiki PageCaching feature
CPAN:Win32::Console	Optional	May be required for Internationalization on Windows
CPAN:Archive::Tar	Optional	Required by the Extensions Installer in configure if command line tar or unzip is not available, since Perl 5.9.3 part of core.
CPAN:Archive::Zip	Optional	Alternative to Archive::Tar, used by the Extensions Installer if Archive::Tar and command line tar and unzip also unavailable
CPAN:Net::SMTP::SSL	Optional	Required by Net::SMPT to send email over SSL to providers such as gmail.
CPAN:Authen::SASL	Optional	Required by Net::SMTP if email server requires authentication.

Most of them will probably already be available in your installation. You can check version numbers with the configure script, or if you're still trying to get to that point, check from the command line like this:

perl -e 'use FileHandle; print $FileHandle::VERSION."\n"'

For more detailed dependency information, try the script dependencies_installer.pl located in the tools directory, which makes perl module installation easier. Run it with option -h to understand basics. This script requires confirmation before it actually does something.

Specific distribution details

Ubuntu and other Debian derived distributions

RedHat, SuSE, CentOS and other RPM based distributions

Client Requirements

The standard installation has relatively low browser requirements:

• XHTML 1.0 Transitional compliant
• Cookies, if persistent sessions are required
• Javascript, for edit/save/upload functionality

  Change {ValidationMethod}{Method} from strikeone to embedded in configure to allow non-javascript browsers to edit/save/upload

CSS and Javascript are used in most skins. Some skins will require more recent releases of browsers. The default skin is tested on IE 6+, Safari, Chrome and Firefox.

You can easily select a balance of browser capability versus look and feel. Try the installed skins at System.SkinBrowser and more at Foswiki:Extensions.SkinPackage.

Uploading the Foswiki distribution to your web server host

If you cannot unpack the Foswiki distribution directly in your installation directory, you can unpack the distribution on your local computer, manually create the directory structure on your host server and upload the files as follows:

• Using the table below, create a directory structure on your host server
• Upload the Foswiki files by FTP (transfer as text except for the image files in pub directory.)
• Note: Don't worry if you are not able to put the lib directory at the same level as the bin directory. You can create this directory elsewhere and configure the bin/setlib.cfg file.

  Foswiki dir:	What it is:	Where to copy:	Example:
  foswiki	start-up pages	root Foswiki dir	/home/smith/public_html/foswiki/
  foswiki/bin	CGI bin	CGI-enabled dir	/home/smith/public_html/foswiki/bin
  foswiki/lib	library files	same level as bin	/home/smith/public_html/foswiki/lib
  foswiki/locale	language files	dir secure from public access	/home/smith/public_html/foswiki/locale
  foswiki/pub	public files	htdoc enabled dir	/home/smith/public_html/foswiki/pub
  foswiki/data	topic data	dir secure from public access	/home/smith/public_html/foswiki/data
  foswiki/templates	web templates	dir secure from public access	/home/smith/public_html/foswiki/templates
  foswiki/tools	Foswiki utlilities	dir secure from public access	/home/smith/public_html/foswiki/tools
  foswiki/working	Temporary and internal files	dir secure from public access	/home/smith/public_html/foswiki/working

Configuring Foswiki manually (without using the configure page)

It is highly recommended that you configure Foswiki by using your browser to access the configure page. However, if you are unable to get the configure page to display (for example, if a dependency is missing), or for some reason you do not wish to use the configure page, then you can configure Foswiki manually

Perform the following steps to manually configure Foswiki:

• Copy the file lib/Foswiki.spec to lib/LocalSite.cfg
• Remove the # in front of the following settings, and ensure that they are set to the correct values: Note: The settings must not reference other $Foswiki::cfg variables.

     $Foswiki::cfg{DefaultUrlHost}
     $Foswiki::cfg{ScriptUrlPath}
     $Foswiki::cfg{ScriptDir}
     $Foswiki::cfg{PubUrlPath}
     $Foswiki::cfg{PubDir}
     $Foswiki::cfg{DataDir}
     $Foswiki::cfg{ToolsDir}
     $Foswiki::cfg{TemplateDir}
     $Foswiki::cfg{LocalesDir}
     $Foswiki::cfg{WorkingDir}
     $Foswiki::cfg{OS}

• Make sure the following settings are defined:

     $Foswiki::cfg{LoginManager}
     $Foswiki::cfg{WebMasterEmail}
     $Foswiki::cfg{SMTP}{MAILHOST}
     $Foswiki::cfg{SMTP}{SENDERHOST}

• Remove the line containing __END__ and everything following it.

Beyond the basic installation

Once you have Foswiki installed and running, you can perform one or more of the following steps to tailor your installation to your needs. Many of the references in this section refer to topics within your Foswiki installation. For example, System.Skins refers to the Skins topic in your System web. To go directly to a topic, enter the full topic name, such as System.Skins, into the "Jump" text box at the top right of any Foswiki page.

To make it easier to follow the instructions in this section, you can view this installation guide using your Foswiki site by entering System.InstallationGuide into the "Jump" text box. By doing this instead of using the INSTALL.html file from the distribution, you will be able to use the embedded hyperlinks to jump directly to the referenced pages.

All of the Foswiki documentation can also be found online in the Foswiki documentation section (the "System" web) of the Foswiki web site.

Note the configure page mentioned in this section is accessed by visiting https://wiki.bacchus-env.eu/bin/configure your web browser.

Site configuration and maintenance

Set Foswiki Preferences

Preferences for customizing many aspects of Foswiki are set by editing Main.SitePreferences. If a given preference is not set in Main.SitePreferences, then a default value is picked up from System.DefaultPreferences, if present, or, for extensions, from the extension topics.

To simplify your upgrades, do not modify System.DefaultPreferences. Instead, copy any settings you want to change from System.DefaultPreferences to Main.SitePreferences.

To see the available preferences that can be set, look through System.DefaultPreferences.

If, for some reason, you wish to pick up default preferences from a different topic, you can set the location in the Miscellaneous settings pane of the configure page, in the {SitePrefsTopicName} setting (visible when Expert mode is enabled). It is recommended that you leave this setting to its default value, DefaultPreferences.

Select the desired security level

Foswiki has a many security features that can be enabled/disabled and adjusted to suit your needs.

In many cases enabling a security feature prevents other features. It is a balance that the administrator has to choose depending on the purpose of the Foswiki installation (confidential vs public knowledge), the type of installation (intranet vs internet), and your type of business.

A new administrator is encouraged to read Foswiki:Support.SecurityFeatures which gives a walkthrough of the different security aspects and how to set the appropriate configuration settings. Note that that some security settings are only visible in configure in "expert mode" which you enter by clicking the "Yes, I've read all the documentation" button at the top of the configure screen.

Enable Email Notification

Each web has an automatic email notification service that sends you an email with links to all of the topics modified since the last alert. To enable this service:

1. Confirm the Mail and Proxies settings on the configure page.
2. Setup a cron job (or equivalent) to call the tools/mailnotify script, as described in the System.MailerContrib topic.

Enable Signed Email Notification

Foswiki administrative emails are an attractive target for SPAM generators and phishing attacks. One good way to protect against this possibility to enable S/MIME signatures on all administrative e-mails. To do this, you need an an X.509 certificate and private key for the the {WebMasterEmail} email account. Obtain these as you would for any other S/MIME e-mail user.

To enable Foswiki to sign administrative e-mails:

1. Enable e-mail as described above
2. Ensure that the system has the CPAN module Crypt::SMIME installed.
3. If necessary, convert your certificate and key files to PEM format ( openssl has all the necessary utilities)
4. Place the certificate anyplace convenient that the webserver can read. It should be protected against write. The conventional place under linux is /etc/pki/tls/certs
5. Place the key file in a secure location that only the webserver (or CGI user) can read. It must not be readable by anyone else, and must not be served by the webserver.
6. Using the configure script, change the following settings under Mail and Proxies:
   1. "Email Server" tab. Follow the directions under {MailMethod} and {MailProgram} to enable an external mail program such as sendmail. Net::SMTP is not supported.
      • {SMTP}{MAILHOST}, {SMTP}{SENDERHOST}, {SMTP}{Username} and {SMTP}{Password} are not used an may be deleted.
      • If Foswiki variable SMTPMAILHOST is defined in Main.SitePreferences it should be removed.
   2. "S/MIME" tab:
      • Enable the S/MIME checkbox
      • Enter the full path to the certificate file in the {SmimeCertificateFile} configuration variable
      • Enter the full path to the private key file in the {SmimeKeyFile} configuration variable
   3. Save the configuration
7. Re-run the configure script an resolve any errors that it identifies

All out-going administrative e-mails will now be signed.

Automate removal of expired sessions and lease files

By default Foswiki cleans out expired session and lease files each time any topic is viewed, but this has a performance cost. Instead you may wish to schedule a cron job (or equivalent) to run the tools/tick_foswiki.pl script, and set a negative value on the configure page for {Sessions}{ExpireAfter}. For more details, read System.CommandAndCGIScripts#tick_foswiki_pl.

Enable WebStatistics

You can manually or automatically generate a listing of the most popular pages for each web, based on number of visits. For information on setting up this feature, see the System.SiteTools#WebStatistics topic.

Enable Localisation

Foswiki supports displaying national (non-ASCII) characters, and using different languages for its basic interface elements. To configure localisation, modify the Localisation section of the configure page. For more information, see Foswiki:Support.InternationalizationSupplement.

Customizing your site

Customize pages for managing personal information

If you are not using Foswiki to manage your users' passwords or email addresses, or would just like to enhance the default pages, then modify the following topics accordingly with information appropriate for your site:

• System.ChangePassword
• System.ResetPassword
• System.ChangeEmailAddress

Customize the user topic for new users

When a new user registers on your Foswiki site, a topic with a name corresponding to the user's WikiName is created in the Main web: this topic is the user's user topic. The user topic is based on the Main.NewUserTemplate topic; if it is not present, then System.NewUserTemplate (and its associated System.UserForm) is used as a default. If you want to customize the user topic for your users, copy System.NewUserTemplate to Main.NewUserTemplate, and System.UserForm to Main.UserForm, and make your changes to Main.NewUserTemplate and Main.UserForm. (See System.ManagingTopics#CopyTopic for instructions on copying a topic.)

You can edit these topics to suit your needs, such as the following:

• Customize the user topic for your site.
• Add an ALLOWTOPICCHANGE preference setting to Main.NewUserTemplate so only the user can edit their own user topic. In particular, on a public Foswiki site, restricting edit access will avoid vandalism and spam.
• Add and remove fields defined in the Main.UserForm.

If you added or removed fields from the user form you may also need to tailor Main.UserRegistration to match (copy over the contents from System.UserRegistration to Main.UserRegistration when creating it).

Customize the appearance of your Foswiki site

The real power of Foswiki lies in its flexibility to be customized to meet your needs. To change the look of the default skin, PatternSkin, please refer to System.PatternSkin and System.PatternSkinCustomization.

At the Foswiki website you can find more resources. A good place to start exploring is Foswiki:Support.BestPracticeTips and Foswiki:Support.FAQ which offer tips and tricks for customizing your Foswiki site. Many of these are best done before any content has been added to your site, so immediately after installation is a good time to consider the possibilities.

Left, Top and Bottom Bars with PatternSkin

The top bar and bottom bar are common across all webs.

To customize the top bar, copy System.WebTopBarExample to System.WebTopBar, and make your desired changes to System.WebTopBar.

To customize the bottom bar, copy System.WebBottomBarExample to System.WebBottomBar, and make your desired changes to System.WebBottomBar.

The side bar can be customized on a per web basis. To customize the side bar, copy the WebLeftBarExample topic in the given web to WebLeftBar, and make your desired changes to WebLeftBar. If you would like to move the side bar to the right of the page, see System.PatternSkin for more details.

Copyright, License and Classification Statements

At the bottom of each topic, there is a copyright statement that is set in the WEBCOPYRIGHT preference. Its default is the following: Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.

If your Foswiki site is used in an environment without public access you should replace this with your normal copyright notice. You should also consider adding a security classification (e.g., For Internal Use Only) so people do not have to add this manually to every new topic.

If your Foswiki site is publicly accessible, you need to decide which copyright and license you wish to apply to all contributions. For open source applications, licenses such as the GNU Free Documentation License, FreeBSD Documentation License, and one of the various Creative Commons licenses are possible licenses to consider. Remember that once people have started contributing, you cannot retroactively change the license (unless it has a provision for this).

To change the copyright statement, perform the following steps:

• Copy the WEBCOPYRIGHT preference setting from System.DefaultPreferences to Main.SitePreferences. Change the value to your desired text. This value will be your new default across all webs.
• You can create a unique message for a specific web by setting the WEBCOPYRIGHT preference in the WebPreferences topic for the given web. For example, you could add a confidential classification to a web that has restricted access.
• The WEBCOPYRIGHT preference setting in System.WebPreferences covers the documentation that comes with Foswiki, and should not be changed.

WYSIWYG vs Raw Edit

In Foswiki, the WYSIWYG editor is used by default in edit mode. An Edit Raw link is available for those who prefer to edit the raw topic text.

If you prefer to use the raw text editor by default and have a separate WYSIWYG button, as in TWiki 4.1, then you can modify the templates that define the edit screen as described in Foswiki:Support.FaqHowToMakeRawEditDefault.

Extensions

Foswiki:Extensions is an extensive library of plugins for Foswiki that enhance functionality in a huge number of ways. A few plugins are pre-installed in the Foswiki distribution. There are several types of Extensions available:

• Plugins extend Foswiki functionality without altering the core code.
• Skins Skins overlay regular templates to give different looks and feels to Foswiki screens.
• Contribs and AddOns are any other Extension that provides added functionality beyond Plugins and Skins

Installing extensions

Extensions can be installed using any of several different methods:

• the configure web interface
• the generic shell installer tools/extension_installer
• by manually downloading the extension zip or tar file

Caution: Users of the debian .deb packages should only use the debian tools when installing extensions.

The simplest way is to visit configure:Extensions. Use the Find More Extensions button to download and install additional extensions from the foswiki.org website. If you are behind a firewall or your server has no access to the Internet, you can also install plugins manually. Installation instructions for each plugin are located in its corresponding topic on http://foswiki.org/. Additional documentation on Foswiki plugins can be found at Foswiki:Support.PluginsSupplement.

When installing an extension from the configure interface:

• Even if available, local Extension installers and archives are not used
• The extension is downloaded from the configured archive
  • The latest version of the Extension is always downloaded. There is no automatic means of downloading older versions.
• If the extension is already installed, a backup is taken to the working/configure/backup directory
• Dependencies on other Extensions are automatically resolved and installed
  • Dependencies are downloaded from the same archive where the Extension was found. No additional searching is performed.
• The Extension is installed.
  • By default, unless a collsion occurrs with an existing file, the Extension's topics will not be checked in to the revision control system.
  • If previous topics or attachments are found, then the topic will be checked in under the Administrators user id.
  • If the topics or attachments are flagged as !noci, disabling checkin, they will still be checked in if existing revision control files are found, suggesting that local modifications have occurred.
• CPAN dependencies and other external packages are not resolved and should be resolved manually

When installing extensions from the command line:

• The _installer package must be run from the root directory of the Foswiki installation.
• The Extension _installer module must be downloaded from the Extension repository. The extension archive will be downloaded if required.
• When the _installer is run, it will install the Extension and dependencies similar to the configure interface except:
  • You will be given the option to use local archives if available in the root of the Foswiki installation
  • You will be given the option to resolve CPAN dependencies after the Extensions and dependencies are installed.
  • Any other dependencies still need to be manually resolved.

When using either the web or shell instalation tools:

• After installation, the Extension _installer module is saved in working/configure/pkgdata
• A complete log of the actions taken by the installer is saved in working/logs/configure/[NameOfExtension]-yyyymmdd-hhmmss-[Action].log

Plugins must be manually enabled in the Plugins section of the configure page. In addition, some extensions also require configuration in this section.

The instructions for using the extensions installer from the shell are retrieved by using the "usage" command: tools/extension_installer usage or ./SomePlugin_installer usage

perl working/configure/pkgdata/X509UserPlugin_installer usage

Usage as a custom installer:

       X509UserPlugin_installer -a -n -d -r -u -c install
       X509UserPlugin_installer -a -n uninstall
       X509UserPlugin_installer manifest
       X509UserPlugin_installer dependencies

Usage as a generic installer:

       tools/extension_installer X509UserPlugin -a -n -d -r -u -c install
       tools/extension_installer X509UserPlugin -a -n uninstall
       tools/extension_installer X509UserPlugin manifest
       tools/extension_installer X509UserPlugin dependencies

If command (install, uninstall ..) is not provided, default is to 
install the extension.

Operates on the directory tree below where it is run from,
so should be run from the top level of your Foswiki installation.

Depending upon your installation, you may need to execute perl directly
  perl tools/extension_installer ...   or
  perl X509UserPlugin_installer ...

"install" will check dependencies and perform any required
post-install steps.

"uninstall" will remove all files that were installed for
X509UserPlugin even if they have been locally modified.

-a means don't prompt for confirmation before resolving
   dependencies
-d means auto-download if -a (no effect if not -a)
-r means reuse packages on disc if -a (no effect if not -a)
-u means the archive has already been downloaded and unpacked
-n means don't write any files into my current install, just
   tell me what you would have done
-c means don't try to use CPAN to install missing libraries

"manifest" will generate a list of the files in the package on
standard output. The list is generated in the same format as
the MANIFEST files used by BuildContrib.

"dependencies" will generate a list of dependencies on standard
output.

Removing (uninstalling) extensions

Caution: When removing an extension, no dependency checking is performed.

• Dependencies are not removed
• Other Extensions dependent on the removed extension may become non-operational.

The web and command line interfaces can be used to uninstall extensions. When an extension is remove, the following occurs:

• The _installer package is used to recover the manifest. If it cannot be found locally, it will be downloaded from the configured extension repository
• A backup of the previously installed files per the manifest will be taken to the configure/working/backup directory
  • Note: If download of the _uninstaller was required, the backup will be made per the current installer's manifest. It is preferable to always save the _installer modules.
• The Extension files along with any ,v revision control files will be removed, including the _installer.
  • Any additional files saved locally are not removed.
• A complete log of the steps taken is saved in working/logs/configure/[NameOfExtension]-yyyymmdd-hhmmss-[Action].log

• Plugin modules are not automatically disabled in the configuration - they must be disabled manually.

Run the uninstall from the "root" of the Foswiki installation: working/configure/pkgdata/SomeExtension_installer uninstall

Restoring a removed, or previous version of an extension

The backup can be extracted from the root directory of the Foswiki installation. The archive is taken "relative" to the root of the installation, so an unzip or tar -xzf of the backup file should be all that is required:

cd /root/of/foswiki
tar -zxvf * working/configure/backup/[Extension}-backup-[yyyymmdd]-[hhmmss].tgz
# or
unzip working/configure/backup/[Extension}-backup-[yyyymmdd]-[hhmmss].zip

TWiki Compatibility

Foswiki is 100% backwards compatible with TWiki^® markup up to and including TWiki 4.2.4. Existing TWiki webs, topics and attachments can be used with Foswiki without requiring any changes.

To support a seamless upgrade from TWiki, Foswiki ships with a plugin called TWikiCompatibilityPlugin. This plugin enables most TWiki extensions to work with Foswiki, without modifications. It also maps requests for legacy TWiki web topics to their Foswiki equivalents, as defined in Foswiki:Development.TopicNameMappingTable. The TWIKIWEB and MAINWEB TWiki variables are also mapped to the new Foswiki macros SYSTEMWEB and USERSWEB.

If you are not upgrading an existing TWiki installation and do not plan to install plugins from the TWiki web site, it is recommended that you disable the TWikiCompatibilityPlugin in the Plugins Section on the configure page.

If a plugin exists both in a TWiki version and a Foswiki version, it is strongly recommended that you use the Foswiki version, as this is coded to work optimally with Foswiki. As part of the Foswiki project, the Foswiki community is evaluating all of the extensions that are available for TWiki, and porting them over to the Foswiki name space. Many of them are being enhanced through the removal of bugs and security vulnerabilities, resulting in better, more functional extensions for Foswiki.

Web Acceleration (mod_perl, FastCGI, ...)

Foswiki is installed by default supporting standard CGI scripts as well as CLI access. For best performance, Foswiki can be accelerated using one of the several accelerators, however, you must install the required Foswiki extension and host modules before enabling accelereation! See the listed extensions for more information.

Fast CGI	FastCGIEngineContrib	Supports the mod_fastcgi and mod_fcgid extensions
mod_perl	ModPerlEngineContrib	supports the apache mod_perl extension

Caution

• Ensure your site is fully configured and working before enabling either of these extensions. They can be challenging to configure.
• The ApacheConfigGenerator will help creating a valid configuration for these accelerators.
• Enabling the apache configuration without installing the pre-req modules and extensions will break your site!
• The core default extensions are well tested with web acceleration, other extensions can exhibit inconsistent behaviour when accelerated.

TWiki is a registered trademark of Peter Thoeny.

Back to top

---

Foswiki Upgrade Guide

This guide covers upgrading from a previous version of Foswiki or TWiki (such as Cairo or TWiki4.0) to Foswiki 1.1 (References to Cairo are for TWiki versions older than TWiki 4.0, such as TWikiRelease04Sep2004)

Overview

Foswiki is a fork from TWiki 4.2.3. Upgrades from all TWiki versions and earlier Foswiki versions are supported. Foswiki is designed to be 100% compatible with the content of TWiki sites, using the same markup language and supporting the same plugin API (through the use of a TWikiCompatibilityPlugin), thereby enabling a smooth transition from TWiki to Foswiki.

Upgrade requirements

• Please review the Foswiki:System.AdminSkillsAssumptions before you upgrade your site.
• To upgrade from an old TWiki Release to the latest Foswiki production release, follow the instructions below.
• Before upgrading, you may wish to make a backup of your topics.
• Once the upgrade has been applied, an existing earlier installation will still be able to read all the topics, but should not be used to write.
• Some TWiki plugins are not compatible with Foswiki (usually ones that use a private API or execute helper scripts); you may need to migrate to the equivalent extension in the Foswiki:Extensions repository.

Upgrading from TWiki to Foswiki

You are strongly advised to read the Foswiki:System.ReleaseNotes01x00 (also available in an HTML file in the root of your installation), which contains a list of changes from TWiki 4.2.3 to Foswiki 1.0. A number of system topics and macros (formerly known as TWiki variables) have been renamed, to better describe their purpose and, where appropriate, to rebrand to the Foswiki name.

Upgrading to a new patch release

To upgrade to a new patch release — for example, from Foswiki 1.1.0 to 1.1.2 — an upgrade package can be used that will not overwrite any of your customizations.

For patch releases you will find a brief upgrade procedure on the download page for the release. Follow this procedure to upgrade to the patch release. It may contain important steps that are unique to each patch release (for example, some configure settings may need to be changed).

If you use the Foswiki PageCaching feature, be sure to refresh the cache after upgrading to a new Foswiki version.

Upgrade procedure: upgrading to a new major or minor version, or upgrading from TWiki

The following is a high level view of the upgrade procedure:

1. Prepare for all upgrade steps.
2. Install the new Foswiki version and configure it with the same settings as the old version.
3. Install any additional extensions (Plugins) used by your old installation. Make sure to use the latest Foswiki versions.
4. Copy all the non-default webs from the old installation to the new one.
5. Copy the users, groups, and site customizations from the old installation to the Main web in the new installation, including all user topics.
6. Apply preferences from the old installation.
7. Apply your site customizations: skin, logos, menu bars, forms for personal information, and so forth.
8. Validate your Wiki applications and other key functionality.
9. Switch your production site from the old installation to the new installation.

   Managing caches of static .js, .css files: some parts of Foswiki use URI versioning to help web browsers obtain a current version of these files when they change, but currently other parts do not. You may need to get your users to clear their browser's cache after upgrading your site to a new major or minor release (usually not necessary for patch upgrades). An alternative approach is to manage your web server configuration to strategically set appropriate expiry times for static files (see performance supplement)

More details for each step appear in the following sections. The steps may need to be modified or otherwise tailored with specifics for your installation. In particular, you must take care to preserve any special configuration or customizations you have made, especially if you have modified any of the default software files or system topics that are contained within the installation package.

For purposes of discussion, the following conventions are used:

• <oldwiki> refers to the directory in which the old installation is located
• <newwiki> refers to the directory in which the new installation is located; it is assumed to be immediately below the root directory of your web server
• <old_users_web> refers to the web in which the user topics are located in the old installation. The default value is the Main web. The web is specified in the Store settings pane of the configure page, in the {UsersWebName} setting (visible when Expert mode is enabled).
• <old_system_web> refers to the web used for documentation and default preferences in the old installation. In Foswiki, the default value is the System web; in TWiki, the default value is the TWiki web. The web is specified in the Store settings pane of the configure page, in the {SystemWebName} setting (visible when Expert mode is enabled).

After the upgrade, in the new installation, the Main web is used for user topics and site preferences, and the System web is used to hold documentation and default preferences.

The configure page mentioned in this document is accessible via your web browser at http://yourdomain/<newwiki>/bin/configure .

Prepare for all upgrade steps

Read the Foswiki:System.ReleaseNotes01x00 and learn about the differences between your old installation and the new release to which you are upgrading. Take note of any areas that affect your site and what special steps you may need to take.

Check that all the extensions (plugins, contribs, skins) used by your old installation are available with the new release. Familiarize yourself with any new behaviour that you will have to adapt to or any configuration changes you will have to perform.

If you are using authentication, prepare a test plan to verify that your authentication mechanism is working correctly. Make sure you are able to test logins by a sufficient sample of users to cover all categories of users of your site. For example, users of various groups may need to be tested. In particular, ensure you test that non-admin users cannot access topics restricted to admins.

Identify all essential Wiki topics and Wiki applications that must be fully functional upon completion of the upgrade. Prepare a test plan to verify their functionality. If you are using access controls, ensure that the test plan will adequately test all categories and groups of users of your site.

If your testing will require a test environment to be set up, ensure that it is ready, with any required support infrastructure (for example, testbed authentication servers). If you need to be able to login with different users in different categories and groups, ensure that you have the required login information ready, or you have testers from those groups available to perform the required test cases.

Download the Foswiki distribution from the following location: http://foswiki.org/Download — if you are installing your extensions manually, also download them from the repository where they are stored.

Installation

Follow the installation instructions in INSTALL.html, located in the root of the new installation. Install the new release in a new directory. Do not install on top of the old release.

• For public or otherwise sensitive installations, ensure that your web server configuration is set to deny access to the new Foswiki installation for anyone except you.
• Configure Foswiki using the configure page.
  • If you are upgrading from an older Foswiki release, first copy your <oldwiki>/lib/LocalSite.cfg file to <newwiki>/lib/LocalSite.cfg in order to preserve your existing configuration settings. Alternatively, you can reconfigure the new installation from scratch (you can use your old LocalSite.cfg file as a reference).
  • If you are upgrading from a TWiki site, you must reconfigure your Foswiki installation from scratch. You cannot copy over your old LocalSite.cfg file (though you can use it as a reference). Run configure and set the configuration values in the new installation to match those of the old installation.
  • Verify all of the configuration settings on the configure page, including any new settings added in the new version. Save the configuration after you have completed your changes.
  • To wipe out all your settings and start configuring from a fresh installation, just delete the <newwiki>/lib/LocalSite.cfg file and run configure.
• Additional resources
  • Foswiki:System.InstallationGuide
  • Foswiki:Support.InstallingOnSpecificPlatforms
  • Foswiki:Support.ApacheConfigGenerator
  • Foswiki:Support.SettingFileAccessRightsLinuxUnix

Test your newly-installed Foswiki site and ensure that its basic functionality works: viewing and editing topics (you can try creating and editing a topic in the Sandbox web).

To make it easier to follow the subsequent steps, you can view this upgrade guide using your new Foswiki site by entering System.UpgradeGuide into the "Jump" text box on the top right of any topic. By doing this instead of using the UpgradeGuide.html file from the distribution, you will be able to use the embedded hyperlinks to jump directly to the referenced pages.

Install extensions

Install all of the extensions that were installed in your old site. In particular, start with any extensions required for the authentication and authorization methods you use (if any). You can use the Find more extensions button in the Extensions section of the configure page to install and configure extensions from the Foswiki:Extensions repository. You can also install extensions manually; see the instructions on the extension's web page from where you obtained the extension (for Foswiki extensions, on foswiki.org).

• Note: some TWiki extensions may not work with Foswiki. By default, the TWikiCompatibilityPlugin is installed to provide backwards compatible support for TWiki plugins. However if the TWiki plugin calls private APIs or invokes helper scripts, it may still not work correctly. Check for an upgraded Foswiki version of the extension in the Foswiki:Extensions repository and install it instead.

Check the plugin topics from your old TWiki/Foswiki installation and transfer the plugin settings to the Main.SitePreferences topic in your new Foswiki site, prefixing each setting with the name of the plugin in uppercase followed by an underscore. For example, to copy over the DEFAULT_TYPE setting from the CommentPlugin topic in the old site to the new site, copy the value to a COMMENTPLUGIN_DEFAULT_TYPE setting in the Main.SitePreferences topic in the new site.

Commonly-customized plugin settings include the following:

• CommentPlugin - DEFAULT_TYPE
• EditTablePlugin - CHANGEROWS, QUIETSAVE, EDITBUTTON
• InterwikiPlugin - RULESTOPIC
• InterWikis - If you added your own rules, make sure you copy over the rules to the new installation.
• SlideShowPlugin - If you changed the embedded 'Default Slide Template', then copy your customed template to the topic in the new installation. You should prefer creating your own slide show template in a separate topic, so you will not have to take special steps over upgrades to preserve your modifications to the default slide template.
• SmiliesPlugin - If you added your own smileys, make sure you copy over your customizations to the topic in the new installatin.
• TablePlugin - TABLEATTRIBUTES

Activate, and if required, configure the installed extensions in configure.

Copy content from non-default webs in old installation to the new installation

If you are upgrading from TWiki Cairo or earlier, it may be necessary to unlock the rcs files in data and pub directories from the old installation using the following shell commands:

• find data -name '*,v' -exec rcs -u -M '{}' \;
• find pub -name '*,v' -exec rcs -u -M '{}' \;

Copy your local webs over to the data and pub directories of the new installation. Do not copy the default webs: <old_system_web> (by default, either System or TWiki), Main, Trash, Sandbox, _default, and _empty.

• Make sure the data and pub directories, as well as the files within them, are readable and writeable by the web server user.
• Note: Foswiki's WebChanges topics depend on the file timestamp. If you touch the .txt files make sure to preserve the timestamp, or change them in the same chronological order as the old file timestamps.

Copy users, user topics, and site customizations to Main web

Copy all topics and attachments from <old_users_web>: copy all files from <oldwiki>/data/<old_users_web>/ to <newwiki>/data/Main/, and copy all files from <oldwiki>/pub/<old_users_web>/ to <newwiki>/pub/Main/ . Do not overwrite any topics already present in the <newwiki>/data/Main/ directory.

• In addition to all the user topics, if you have created <old_users_web>.NewUserTemplate in the old installation, this step will copy over your template for user topics to the new installation.
• Ensure that the topic defining the admin group in your old installation is copied over. The admin group is defined in the Security setup pane of the configure page, in the {SuperAdminGroup} setting (visible when Expert mode is enabled). You can do either of the following:
  • Set the {SuperAdminGroup} setting in your new installation to the old admin group.
  • Move the contents of the old admin group to the new admin group. To avoid having to change all references to the old admin group, you must still keep the old admin group defined: set it so its only member is the new admin group, and the new admin group is the only user who can change or rename the old admin group topic.
    • The default admin group with Foswiki is AdminGroup and the default admin group with TWiki is TWikiAdminGroup. So if you are upgrading from TWiki and are using the default admin groups, then in the new installation, you must copy all members from TWikiAdminGroup to AdminGroup, and change TWikiAdminGroup so its only member is AdminGroup and so it can only be modified or renamed by AdminGroup.
• If your old installation did not customize {LocalSitePreferences} on the configure page, or if you did customize {LocalSitePreferences} but kept your site preferences within the <old_users_web> web, then this step will also copy over your site preferences to the new installation.

For upgrades from an older Foswiki installation:

• Manually merge all users from the <old_users_web>.WikiUsers topic in the old installation to the Main.WikiUsers topic in the new installation. If the new installation does not yet have an initial Main.WikiUsers topic, then copy <oldwiki>/data/<old_users_web>/WikiUsers.txt to <newwiki>/data/Main/WikiUsers.txt.
• Verify that the following default users are present in the Main.WikiUsers topic:
  • ProjectContributor - the Foswiki documentation is attributed to this user
  • RegistrationAgent - special user used during the new user registration process
  • UnknownUser - used where the author of a previously stored piece of data can't be determined
  • WikiGuest - guest user; used as a fallback if the user can't be identified
• If any of the default users are missing, then add them in manually to Main.WikiUsers, using the corresponding entries in Foswiki:System.UsersTemplate as an example.
• If you use data/.htpasswd for authentication, copy this file from the old installation to the new one.
• If you have customized <old_system_web>.UserRegistration, then either copy over <oldwiki>/data/<old_system_web>/UserRegistration.txt and <oldwiki>/data/<old_system_web>/UserRegistration.txt,v to the <newwiki>/data/System/ directory, or modify System.UserRegistration in the new installation to contain your customizations.

For upgrades from a TWiki installation:

• Manually merge all users from the <old_users_web>.TWikiUsers topic in the old installation to the Main.WikiUsers topic in the new installation. If the new installation does not yet have an initial Main.WikiUsers topic, then copy <oldwiki>/data/<old_users_web>/TWikiUsers.txt to <newwiki>/data/Main/WikiUsers.txt, and manually add the required default users (see the next steps).
• Verify that the following default users are present in the Main.WikiUsers topic:
  • ProjectContributor - the Foswiki documentation is attributed to this user
  • RegistrationAgent - special user used during the new user registration process
  • UnknownUser - used where the author of a previously stored piece of data can't be determined
  • WikiGuest - guest user; used as a fallback if the user can't be identified
• If any of the default users are missing, then add them in manually to Main.WikiUsers, using the corresponding entries in Foswiki:System.UsersTemplate as an example.
• If you use data/.htpasswd for authentication, copy this file from the old installation to the new one.
• If you are upgrading from Cairo and are using the Htpasswd login manager, run the tools/upgrade_emails.pl script to move the user emails out of the user topics and into the password file.
• If you have customized <old_system_web>.TWikiRegistration, then modify System.UserRegistration in the new installation to contain your customizations.

Copy over any topics and attachments you want to preserve from the Sandbox web in the old installation: copy the desired files from <oldwiki>/data/Sandbox/ to <newwiki>/data/Sandbox and from <oldwiki>/pub/Sandbox/ to <newwiki>/pub/Sandbox . Some pages you may wish to preserve are the WebHome topic and the WebLeftBar topic (if you had created it in the old wiki installation). The Sandbox web often contains work-in-progress topics that users will want to keep.

Make sure the data and pub directories, as well as the files within them, are readable and writeable by the web server user.

Execute your test plans for authentication and authorization. Test that users that you have transferred from the old installation can login with any problems, and that access controls work appropriately: check that users are able to view and edit pages for which they have access, and are denied permission to view or edit pages for which they do not have access. Also check that pages restricted to the admin group are not accessible by non-admin users, and that administrators continue to have access.

Apply preferences from old installation

If you have not already set your desired site-wide preferences, as described in the section "Set Foswiki Preferences" in the System.InstallationGuide, then set your preferences. The location of your site preferences is specified in the Miscellaneous settings pane of the configure page, in the {LocalSitePreferences} setting (visible when Expert mode is enabled) — the default location is Main.SitePreferences. Copy any customized preferences from the site preferences topic in your old installation to the site preferences topic in the new installation. (Note you may have already copied over your customized preferences when you transfered the contents of the <old_users_web> web.)

If, in your old installation, you customized the default preferences in <old_system_web>.DefaultPreferences, then transfer your customizations from this topic to the site preferences topic instead (i.e. the topic specified in your {LocalSitePreferences} setting), so that your customizations will not get overwritten on the next upgrade.

If you are upgrading from TWiki, note that the default location of the default preferences in TWiki is <old_system_web>.TWikiPreferences, and the default location of the site preferences is Main.TWikiPreferences. Transfer any customized preferences from these topics to the site preferences topic in your new installation.

Apply additional site customizations

Modify skin with customizations for your site

If you did not already customize the appearance of your new installation, as described in the section "Customize the appearance of your Foswiki site" in the System.InstallationGuide, then reapply the customizations from your old installation to the new one. Ensure you transfer over any skin templates — .tmpl files, or topics referred to using VIEW_TEMPLATE or EDIT_TEMPLATE preferences — you need. Also ensure you transfer any style sheets or Javascript files required.

If you are upgrading from the Cairo version of TWiki: note that the skins from this release do not work well with Foswiki. Starting from TWiki 4.0.2, the default PatternSkin has been fairly stable and so your customizations should continue to work.

Customize pages for managing personal information

In your new installation, default copies of the following topics were installed:

• System.ChangePassword
• System.ResetPassword
• System.ChangeEmailAddress

If you customized these topics in your old installation, transfer the changes to these topics in the new installation. Use the corresponding files in the <oldwiki>/<old_system_web>/ directory as a reference.

Validate your Wiki applications and other key functionality

Execute your test plan to validate the Wiki applications and other key functionality that need to be up and running after the upgrade.

Switch your production site from the old installation to the new installation

If you had been running your old installation in parallel with the new one during a test phase, then disable your old installation, and repeat the step "Copy content from non-default webs in old installation to the new installation".

Change your web server configuration so that the new installation is accessible to all of your users, and so the old installation is no longer accessible.

Change your web server configuration so that the new installation is accessible using the same URL prefix as your old installation. For purposes of discussion, assume that your old installation is accessible from http://yourdomain/wiki/. You can use one of the following approaches to make the new installation accessible using the same URL prefix:

• You can rename your <newwiki>/ directory to wiki/ (renaming the directory of your old installation if necessary).
• If your operating system supports links to other directories and your web server is configured to follow links, then you can create a link called wiki/ that points to <newwiki>/ (renaming the directory of your old installation if necessary).
• You can configure your web server so that requests to /wiki/ are served from your <newwiki>/ directory.

Re-execute your test plan to verify that your newly-upgraded site is accessible to your users, and that all authentication and authorization mechanisms work as expected (including denying access to those who are not authorized).

Re-execute your test plan to verify that your Wiki applications and other key functionality work as intended.

Additional steps when upgrading from TWiki Cairo

Favicon

The favicon is now configurable as a site preference or per-web preference. See System.DefaultPreferences for a description of the FAVICON preference. To set it for your site, add the FAVICON preference to your site preferences topic, Main.SitePreferences (or the topic you configured in your {LocalSitePreferences} setting in the Miscellaneous settings pane on the configure page). To set it for a web, add the FAVICON preference to the WebPreferences topic for that web.

Important changes since TWiki 4.0.5

Supported Perl version

To use Foswiki, you must use Perl 5.8 or higher. Foswiki no longer supports Perl version 5.6.x (the minimum version required for TWiki 4.0.5).

Template spec changed

Until TWiki 4.0.5, any text inside template definition blocks for SkinTemplates (formerly called TWikiTemplates) — that is, between %TMPL:DEF{"block"}% and %TMPL:END% — was stripped of leading and trailing white space, including newlines. This made it difficult for skin developers to include a newline before or after a block of text.

From TWiki 4.1.0 onwards, and in Foswiki 1.0, this has changed so that white space is no longer stripped. Skins like PatternSkin and NatSkin have been updated so that they work with the new behavior. If you use an older skin or have written your own you will most likely need to make some adjustments.

In general, if you get mysterious blank lines in your skin, the newline after the %TMPL:DEF{"block"}% needs to be removed: the content of the block must follow on the same line as the TMPL:DEF.

CommentPlugin templates also must be modified to remove extraneous newlines — in particular, any newline immediately after the TMPL:DEF. See the System.CommentPluginTemplate for examples of how comment template definitions should look like in TWiki 4.1.x.

Example: a CommentPlugin template that adds a row to a table. With versions of TWiki prior to 4.1, the following syntax can be used:

%TMPL:DEF{OUTPUT:tabletest}%%POS:BEFORE%
|%URLPARAM{"comment"}%| -- %WIKIUSERNAME% - %DATE% |
%TMPL:END%

Starting in TWiki 4.1 and continuing with Foswiki 1.0, the newline before the start of the table row must be removed:

%TMPL:DEF{OUTPUT:tabletest}%%POS:BEFORE%|%URLPARAM{"comment"}%| -- %WIKIUSERNAME% - %DATE% |
%TMPL:END%

Important changes for the upgrader - since TWiki 4.1.0

New location for session and other temporary files

The directory for passthrough and session files have been replaced by a common directory for temporary files used by Foswiki. Previously the two configure settings {PassthroughDir} and {Sessions}{Dir} were set by default to /tmp. These config settings have been eliminated: Foswiki creates a tmp directory and other temporary directories under the directory defined by the configure setting {WorkingDir}.

Important changes for the upgrader - since TWiki 4.1.2

New WYSIWYG editor

Foswiki now ships with a new WYSIWYG editor based on TinyMCE that replaces the Kupu-based editor. When TinyMCEPlugin is enabled, the Edit button will initiate WYSIWYG editing mode. A Raw Edit link has been added for users to edit the topic markup directly.

The WYSIWYG button has been removed.

NEWTOPICLINKSYMBOL removed

The NEWTOPICLINKSYMBOL preference that was deprecated in TWiki 4.1 is no longer supported. To control the appearance of new links, set the NEWLINKFORMAT preference in Main.SitePreferences (see System.DefaultPreferences for more information on NEWLINKFORMAT).

UserForm and NewUserTemplate customization

When a new user registers on Foswiki his user topic is created based on the NewUserTemplate and UserForm in the Main web, if they exist. If the topic does not exist in the Main web, then the default version from System is used. Thus on upgrades, any customizations you made to NewUserTemplate or UserForm in the Main web will be preserved.

In previous TWiki versions, only System.NewUserTemplate and System.UserForm are used; you cannot override them by creating your own version in the Main web.

WikiUsers no longer distributed

The Main.WikiUsers topic contains all the registered users. It is not included in the Foswiki distribution, so that your list of users will not be overwritten on upgrades. When the first user is registered in Foswiki, the Main.WikiUsers topic is created on demand.

New working directory

The configuration setting {WorkingDir} in the General path settings pane on the configure page defines the location of a working directory for various subdirectories for use by Foswiki. The default value for this setting is the working subdirectory within the installation root directory for the Foswiki installation.

The subdirectories within the working directory include the following:

• registration_approvals — previously located in the data/ directory
• tmp — avoids security issues with using the /tmp directory
• work_areas — previously located in the pub/ directory.

Note: Remember to restrict access to this new directory when you upgrade.

If you have your own scheduled task to delete obsolete session files, note they are now located in the working/tmp/ subdirectory.

New internal admin login

Foswiki has a new internal admin login feature that lets you login as a temporary administrator, using "admin" as your user name and the password for the configure page. The internal admin username can be configured in the {AdminUserLogin} setting in the Security setup pane on the configure page.

In order to add an initial user to the default {SuperAdminGroup}, Main.AdminGroup, you must login as the internal admin user using the link on the Main.AdminGroup page.

Important changes for the upgrader - since Foswiki 1.0.4

An additional security feature has been added to Foswiki 1.0.5 so that saving data now requires the http method POST. This means that it is no longer possible to store data via an "<a href=..." link or img tag. It also means that if you have an application with an HTML form that creates new topics you must specify in the form tag method="post". This change is done to further tighten the security of Foswiki.

<form name="new" action="%SCRIPTURLPATH{"save"}%/Sandbox/" method="post">
    ...
</form>

The template webs _default and _empty are frequent targets for spammers because these webs are normally not monitored very carefully by the community around a Foswiki installation. These webs are now write protected so on an administrator can edit topics in these webs. When an administrator creates a new web it is important to remember to remove the access restriction from the WebPreferences in the new web.

Important changes for the upgrader - since Foswiki 1.0.5

Foswiki 1.0.6 introduces a major security enhancement, protecting against Cross-Site Request Forgery. The extra safe "double submit" algorithm, as recommended by the Open Web Application Security Project (OWASP) project has been used. This is the same algorithm used by several major banks and other security-conscious institutions, and requires that users have Javascript enabled.

See Foswiki:Support.SecurityFeatures for more information on these, and other, Foswiki security features. This is recommended reading for all Foswiki administrators.

If these new countermeasures against CSRF creates problems for your users and your applications, you can alter the way the protection works or disable it. These are the configure parameters you need to visit (note that some are expert settings).

• {Validation}{Method} is by default "strikeone" which is the highest level of security and requires that users have Javascript enabled. You can lower this setting to "embedded" which uses a less safe validation method but does not require javascript. If you want to disable CSRF protection set it to "none". It is highly recommended to keep it at "strikeone".
• {Validation}{ValidForTime} is the time the validation key is valid. It is by default 1 hour. If your users often edit pages longer you can increase this time. Your users can still save pages with an expired validation key but they will be asked to confirm the saving.
• {Validation}{MaxKeysPerSession} is the maximum number of validation keys to store in a session. There is one key stored for each page rendered. If the number of keys exceeds this number, the oldest keys will be force-expired to bring the number down. If you have users that are very fast at editing pages and experience expired keys, you can increase this number. The default is 1000 and should be much higher than any normal person will experience.
• {Validation}{ExpireKeyOnUse} defines if validation keys expire when they are used for storing data. This prevents an attacker from evesdropping communication between server and browser and reuse keys. Unfortunately it also means that if a user edits a page, saves it, uses the back button of the browser, corrects his previous editing, and then saves again, he is asked to confirm that he intended to save the topic. Another use case is if you create an application with multiple forms and multiple submit buttons on a topic and you submit multiple times from this topic without navigating away from it, you will be asked to confirm the submission each time. If this is not acceptable to your use of Foswiki, you can turn off {Validation}{ExpireKeyOnUse}.

Back to top

---

User Authentication

Controlling who can access your site

Overview

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

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

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

Quick Authentication Test - Use the %USERINFO% macro to return your current identity:

• You are guest, Main.WikiGuest,

BACCHUS Wiki user authentication is split into four sections; password management, user mapping, user registration, and login management. Password management deals with how users personal data is stored. Registration deals with how new users are added to the wiki. Login management deals with how users log in.

Once a user is logged on, they can be remembered using a Client Session stored in a cookie in the browser (or by other less elegant means if the user has disabled cookies). This avoids them having to log on again and again.

BACCHUS Wiki user authentication is configured through the Security Settings pane in the configure interface.

Please note FileAttachments are not protected by BACCHUS Wiki User Authentication.

Password Management

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

You can easily plug in alternate password management modules to support interfaces to other third-party authentication databases.

The password manager is selected using the {PasswordManager} setting in configure.

User Mapping

Usually when you are using an external authentication method, you want to map from an unfriendly "login name" to a more friendly WikiName. Also, an external authentication database may well have user information you want to import to BACCHUS Wiki, such as user groups.

By default, BACCHUS Wiki supports mapping of usernames to wikinames, and supports BACCHUS Wiki groups internal to BACCHUS Wiki. If you want, you can plug in an alternate user mapping module to support import of groups etc.

The user mapping manager is selected using the {UserMappingManager} setting in configure.

User Registration

New user registration uses the password manager to set and change passwords and store email addresses. It is also responsible for the new user verification process. the registration process supports single user registration via the UserRegistration page, and bulk user registration via the BulkRegistration page (for admins only).

The registration process is also responsible for creating user topics, and setting up the mapping information used by the User Mapping support.

See Custom registration page for changing the user registration page.

Login Management

Login management controls the way users have to log in. There are three basic options; no login, login via a BACCHUS Wiki login page, and login using the webserver authentication support. the login manager is selected using the {LoginManager} setting in configure.

No Login (select none)

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

Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to administrators.

Template Login (select Foswiki::LoginManager::TemplateLogin)

Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out. Client Sessions are used to remember users. Users can choose to have their session remembered so they will automatically be logged in the next time they start their browser.

Enabling Template Login

By default, your Foswiki installation is probably already using TemplateLogin, HtPasswdUser and TopicUserMappingContrib as the default Login, Password and user mapping options.

1. Using configure:
   1. Navigate to the Login tab on the Security and Authentication panel. Select the Foswiki::LoginManager::TemplateLogin login manager.
   2. Navigate to the Passwords tab. Select the appropriate PasswordManager for your system - the default is Foswiki::Users::HtPasswdUser.

      There is also an EXPERT configure setting {TemplateLogin}{PreventBrowserRememberingPassword} that you can set to prevent Browsers from remembering username and passwords if you are concerned about public terminal usage.

2. Verify that registration works by registering yourself with the System.UserRegistration topic. If there are problems, try these troubleshooting tips:
   1. Note: A standard Foswiki installation will not allow any new registrations unless there is a working SMTP configuration
   2. If your PasswordManager is HtPasswdUser (the default), check the .htpasswd file is being updated correctly with a new entry. If not, check {Htpasswd}{FileName} is correct (under Security and Authentication on the Password tab in configure), and that the webserver user has write permission.
3. Create a new topic (in Sandbox web for example) to confirm that authentication works.
4. Add users to the Main.AdminGroup. Edit the Main.AdminGroup topic in the Main web to include users that should have administrator status. Read defining adminstrator user(s) for more information.

   This is a very important step, as users in this group can access all topics, independent of BACCHUS Wiki access controls.

AccessControl has more information on setting up access controls.

Foswiki AccessControls do not protect topic attachments unless the web server has been configured to do so using the viewfile script. Visit Foswiki:Support.ApacheConfigGenerator for examples using Apache.

As Template Login uses a wiki page for its login prompt, there is a great deal of flexibility in customizing the login page for your purposes.

The default new user template page is in System.NewUserTemplate. The same macros get expanded as in the template topics. You can create a custom new user topic by creating the NewUserTemplate topic in Main web, which will then override the default in System web. See System.UserForm for copy instructions.

Custom registration page

You can customize the default System.UserRegistration topic by first copying System.DefaultUserRegistration to UserRegistration in Main web. This will ensure that your changes will remain intact next time you upgrade.

A couple of common fields are hidden from normal view to make the registration page as lean as possible. You can unhide those fields on the page by removing EXCLUDED_ from the INCLUDE tags) or add new ones.

New fields may also be added. The name="" parameter of the <input> tags must start with: "Fwk0..." (if this is an optional entry), or "Fwk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.

Automatic Group Membership

The TopicUserMappingContrib can also enroll users into groups during registration. (Other mappers might not support this feature). Options include:

• Automatically enrolling users in one or more groups during registration
• Allow the user to select multiple groups from a list of eligible groups
• Allow the user to choose only one group from a list of eligible groups
• Don't do any group enrollment during registration.

The list of eligible groups can be generated in one of two ways:

• Manually by configuration. This fixed list of groups will always be listed.
• Automatically based upon CHANGE permission on the group topics.

There are two registration scenarios that apply:

Self-registration by Guest users

The actual registration will be processed by the special internal user Main.RegistrationAgent. Group topics must include an ALLOWTOPICCHANGE = Main.RegistrationAgent to be eligible for enrollment.

Registration by logged-in users

The registration form is filled out by some other logged-in user. In this case, the Main.RegistrationAgent is not used for Group updates. The current user must have ALLOWTOPICCHANGE permission for groups for them to be eligible for enrollment.

• Caution: If an administrator registers a user with automatic group membership enabled, the new user could potentially be added to All groups. Use caution with this feature!

Note: During registration, if it turns out that the current user or Main.RegistrationAgent doesn't have permission to update the group topic, the group update will be silently skipped. The user will still be albe to register.

See DefaultPreferences#RegistrationOptions for further details. Copy the settings into Main.SitePreferences to make them active.

Enabling Apache Login

With Apache Login enabled, when Foswiki needs to authenticate the user, the standard HTTP authentication mechanism is used: the browser itself will prompt for a user name and password.

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

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

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

The same private .htpasswd file used in BACCHUS Wiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support.

Do not use the Apache htpasswd program with .htpasswd files generated by BACCHUS Wiki! htpasswd wipes out email addresses that BACCHUS Wiki plants in the info fields of this file.

Apache Login is required for Apache-based login methods such as mod_ldap

You can use any Apache authentication module that sets the REMOTE_USER environment variable.

To setup Apache Login, perform the following steps:

1. Configure Apache Login. Under the Security and Authentication pane on the Login tab in configure:
   1. Select Foswiki::LoginManager::ApacheLogin for {LoginManager}.
   2. Select Foswiki::Users::HtPasswdUser for {PasswordManager}.
   3. Select Foswiki::Users::TopicUserMapping for {UserMappingManager}.
   4. Save your settings.
   5. Configure your Apache settings for HTTP authentication. Use the Foswiki:Support.ApacheConfigGenerator tool or the foswiki/bin-htaccess.txt file to set the following Apache directives on the bin scripts:

       <FilesMatch "(attach|edit|manage|rename|save|upload|mail|logon|rest|.*auth).*">
       require valid-user
       </FilesMatch>

      You can also refer to the sample foswiki_httpd_conf.txt and bin-htaccess.txt files to see how the appropriate Apache directives are specified.
2. Verify that registration works by registering yourself with the System.UserRegistration topic. If there are problems, try these troubleshooting tips:
   1. Note: A standard Foswiki installation will not allow any new registrations unless there is a working SMTP configuration
   2. If your PasswordManager is HtPasswdUser (the default), check the .htpasswd file is being updated correctly with a new entry. If not, check {Htpasswd}{FileName} is correct (under Security and Authentication on the Password tab in configure), and that the webserver user has write permission.
3. Create a new topic (in Sandbox web for example) to confirm that authentication works.
4. Add users to the Main.AdminGroup. Edit the Main.AdminGroup topic in the Main web to include users that should have administrator status. Read defining adminstrator user(s) for more information.

   This is a very important step, as users in this group can access all topics, independent of BACCHUS Wiki access controls.

Logons via bin/logon

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

The bin/logon script enables this. If you are using Apache Login, the bin/logon script must be setup in the Apache configuration or bin/.htaccess file to be a script which requires a valid user. Once authenticated, it will redirect the user to the view URL for the page from which the logon script was linked.

Sessions

BACCHUS Wiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address.

You don't have to enable sessions to support logins in BACCHUS Wiki. However it is strongly recommended. BACCHUS Wiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don;t enable sessions, BACCHUS Wiki will try hard to remember you, but due to limitations in the browsers it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.

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

Getting, Setting, and Clearing Session Variables

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

To make use of these features, use the tags:

%SESSION_VARIABLE{ "varName" }%
%SESSION_VARIABLE{ "varName" set="varValue" }%
%SESSION_VARIABLE{ "varName" clear="" }%

Access controls cannot be modified in this way

Cookies and Transparent Session IDs

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

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

Username vs. Login Username

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

BACCHUS Wiki internally manages two usernames: Login Username and Foswiki Username.

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

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

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

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

Changing Passwords

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

• The ChangePassword form ( Foswiki/ChangePassword )
• The ResetPassword form ( Foswiki/ResetPassword )

If the {PasswordManager} does not support password changing, the ChangePassword and ResetPassword will show a simple message. This message is defined iby the setting CHANGEPASSWORDDISABLEDMESSAGE in System.DefaultPreferences. You can redefine this setting by copying it to Main.SitePreferences and change it to include a link to the password management website of your organisation.

Changing E-mail Addresses

If the active {PasswordManager} supports storage and retrieval of user e-mail addresses, you can change your e-mail using a regular page. As shipped, this is true only for the Apache 'htpasswd' password manager.

• The ChangeEmailAddress form ( Foswiki/ChangeEmailAddress )

If the {PasswordManager} does not support password changing, ChangeEmailAddress will guide the user to define the email address in the user topic.

Controlling access to individual scripts

You may want to add or remove scripts from the list of scripts that require authentication. The method for doing this is different for each of Template Login and Apache Login. Any scripts listed as requiring authentication will not be usable by the Guest user. If you require that Main.WikiGuest be allowed to edit topics on your site, edit and save must be removed from the list of scripts requiring authentication.

• For Template Login, update the {AuthScripts} list using configure
• For Apache Login, add/remove the script from bin/.htaccess, or from the FilesMatch line in the Apache configuration.

How to choose an authentication method

One of the key features of Foswiki is that it is possible to add HTML to topics. No authentication method is 100% secure on a website where end users can add HTML, as there is always a risk that a malicious user can add code to a topic that gathers user information, such as session IDs. The Foswiki developers have been forced to make certain tradeoffs, in the pursuit of efficiency, that may be exploited by a hacker.

This section discusses some of the known risks. You can be sure that any potential hackers have read this section as well!

At one extreme, the most secure method is to use Foswiki via SSL (Secure Sockets Layer), with a login manager installed and Client Sessions turned off.

Using Foswiki with sessions turned off is a pain, though, as with all the login managers there are occasions where Foswiki will forget who you are. The best user experience is achieved with sessions turned on.

As soon as you allow the server to maintain information about a logged-in user, you open a door to potential attacks. There are a variety of ways a malicious user can pervert Foswiki to obtain another users session ID, the most common of which is known as a cross-site scripting attack. Once a hacker has an SID they can pretend to be that user.

To help prevent these sorts of attacks, Foswiki supports IP matching, which ensures that the IP address of the user requesting a specific session is the same as the IP address of the user who created the session. This works well as long as IP addresses are unique to each client, and as long as the IP address of the client can't be faked.

Session IDs are usually stored by Foswiki in cookies, which are stored in the client browser. Cookies work well, but not all environments or users permit cookies to be stored in browsers. So Foswiki also supports two other methods of determining the session ID. The first method uses the client IP address to determine the session ID. The second uses a rewriting method that rewrites local URLs in Foswiki pages to include the session ID in the URL.

The first method works well as long as IP addresses are unique to each individual client, and client IP addresses can't be faked by a hacker. If IP addresses are unique and can't be faked, it is almost as secure as cookies + IP matching, so it ranks as the fourth most secure method.

If you have to turn IP matching off, and cookies can't be relied on, then you may have to rely on the second method, URL rewriting. This method exposes the session IDs very publicly, so should be regarded as "rather dodgy".

Most Foswiki sites don't use SSL, so, as is the case with most sites that don't use SSL, there is always a possibility that a password could be picked out of the aether. Browsers do not encrypt passwords sent over non-SSL links, so using Apache Login is no more secure than Template Login.

Of the two shipped login managers, Apache Login is probably the most useful. It lets you do this sort of thing: wget --http-user=RogerRabbit --http-password=i'mnottelling http://www.example.com/bin/save/Sandbox/StuffAUTOINC0?text=hohoho,%20this%20is%20interesting i.e. pass in a user and password to a request from the command-line. However it doesn't let you log out.

Template Login degrades to url re-writing when you use a client like dillo that does not support cookies. However, you can log out and back in as a different user.

Finally, it would be really neat if someone was to work out how to use certificates to identify users.....

See Foswiki:Support.SupplementalDocuments for more information.

Back to top

---

Access Control

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

Access Control allows you restrict access to single topics and entire webs, by individual user and by user Groups. Access control, combined with UserAuthentication, lets you easily create and manage an extremely flexible, fine-grained privilege system.

An important consideration

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

• Peer influence is enough to ensure that only relevant content is posted.
• Peer editing - the ability for anyone to rearrange all content on a page - keeps topics focused.
• In Foswiki, content is transparently preserved under revision control:
  • Edits can be undone by the administrator (per default a member of Main.AdminGroup; see #ManagingGroups).
  • Users are encouraged to edit and refactor (condense a long topic), since there's a safety net.

As a collaboration guideline, create broad-based Groups (for more and varied input), and avoid creating view-only Users (if you can read it, you should be able to contribute to it).

Permissions settings of the webs on this Foswiki site

The topic SitePermissions gives you an overview of the access control settings for all your webs.

Authentication vs. Access Control

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

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

Users and groups

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

Managing Users

In standard Foswiki a user can create an account in UserRegistration. The following actions are performed:

• WikiName, encrypted password and email address are recorded using the password manager if authentication is enabled.
• A confirmation e-mail is sent to the user.
• A user home page with the WikiName of the user is created in the Main web.
• The user is added to the Main.WikiUsers topic.
• Optionally the user is added to one or more groups.

The default visitor name is Main.WikiGuest. This is the non-authenticated user. By default the non-authenticated user is not permitted to edit topics. If you require anonymous editing, see UserAuthentication#IndividualScripts.

Your local Foswiki may have an alternate user mapping manager installed which doesn't support user registration. Check with your Wiki administrator if you are in doubt.

Managing Groups

The following describes the standard Foswiki support for groups. Your local Foswiki may have an alternate group mapping manager installed. Check with your Wiki administrator if you are in doubt.

Groups are defined by group topics located in the Main web. To create a new group, visit Main.WikiGroups. You will find a "Create a new group" link at the top which reveals a form to create a new group. Enter the name of the new group ending in Group into the "Group Name" form field and the initial members in the "Members" field. This creates a new group topic.

By default any member of a group has access rights to both adding and removing users from the group through the nice user interface. If you need to limit this access further, change the ALLOWTOPICCHANGE setting through "More Topic Action" -> "Edit topic preference settings".

The ALLOWTOPICCHANGE setting defines who is allowed to change the group topic; it is a comma delimited list of users and groups. You typically want to restrict that to the members of the group itself, so it should contain the name of the topic. This prevents users not in the group from editing the topic to give themselves or others access. For example, for the KasabianGroup topic write:

• Set ALLOWTOPICCHANGE = Main.KasabianGroup
  • Caution This is set in the "Topic Settings" and not inline in the topic text!

Foswiki has strict formatting rules. Make sure you have three spaces, an asterisk, and an extra space in front of any access control rule. See below for more information about ALLOWTOPICCHANGE.

Background: A group topic is an empty topic with 3 hidden preference settings.

• GROUP: Comma separated list of users and/or groups
• ALLOWTOPICCHANGE: Comma separated list of users and groups that are allowed to add and remove users from the group
• VIEW_TEMPLATE: Always set to the value GroupView. This alters the way the topic is presented to include a nice user interface for adding and removing users.

Foswiki 1.1 introduced the smart user interface for adding and removing members of a group. Group topics from prior versions of Foswiki will still work. These have the GROUP setting visible in the topic text itself and you edit it by editing the topic. Foswiki 1.1 Main.WikiGroups will show these old group topics with an "Upgrade Group Topic button". The administrator can upgrade an old group topic to the nice new user interface with one easy click.

The Super Admin Group

A number of Foswiki functions (for example, renaming webs) are only available to administrators. Administrators are simply users who belong to the SuperAdminGroup. This is a standard user group, the name of which is defined by {SuperAdminGroup} setting in configure. The default name of this group is the AdminGroup. The system administrator may have chosen a different name for this group if your local Foswiki uses an alternate group mapping manager, but for simplicity we will use the default name AdminGroup in the rest of this topic.

You can create new administrators simply by adding them to the Main.AdminGroup topic. For example,

• Set GROUP = Main.ElizabethWindsor, Main.TonyBlair

A member of the Super Admin Group has unrestricted access throughout the wiki, so only trusted staff should be added to this group.

Restricting Access

Access to webs and topics is controlled by setting the values of certain preferences. These names of these preferences have the general form:

permission context mode

Where permission is ALLOW or DENY, _context is TOPIC, WEB, or ROOT, and mode is VIEW, CHANGE, or RENAME. For example, the preference ALLOWWEBCHANGE lists who is allowed to change topics in the current web.

• Restricting VIEW blocks viewing and searching of content. When you restric VIEW to a topic or web, this also restricts INCLUDE and Formatted SEARCH from showing the content of the topics.
• Restricting CHANGE blocks creating new topics, changing topics or attaching files.
• Restricting RENAME prevents renaming of topics within a web.

There is an important distinction between CHANGE access and RENAME access. A user can CHANGE a topic, but thanks to version control their changes cannot be lost (the history of the topic before the change is recorded). However if a topic or web is renamed, that history may be lost. Typically a site will only give RENAME access to administrators and content owners.

Note that ALLOWWEBxxx and DENYWEBxxx preferences can only be set in WebPreferences topics. You cannot define a site level access. Each web must be protected on their own. Subwebs inherit access settings from the parent web. See next section.

Note that ALLOWTOPICxxx and DENYTOPICxxx preferences apply only to the topic itself.

Be warned that some plugins may not respect access permissions.

FINALPREFERENCES affects access controls, allowing you to prevent changes to access control settings while still allowing edit access to topics.

Controlling access to a Web

You can define restrictions on who is allowed to view a BACCHUS Wiki web. You can restrict access to certain webs to selected users and groups, by:

• authenticating all webs and restricting selected webs: Topic access in all webs is authenticated, and selected webs have restricted access.
• authenticating and restricting selected webs only: Provide unrestricted viewing access to open webs, with authentication and restriction only on selected webs.

• You can define these settings in the WebPreferences topic, preferable towards the end of the topic:
  • Set DENYWEBVIEW = < comma-delimited list of users and groups >
  • Set ALLOWWEBVIEW = < comma-delimited list of users and groups >
  • Set DENYWEBCHANGE = < comma-delimited list of users and groups >
  • Set ALLOWWEBCHANGE = < comma-delimited list of users and groups >
  • Set DENYWEBRENAME = < comma-delimited list of users and groups >
  • Set ALLOWWEBRENAME = < comma-delimited list of users and groups >

If your site allows sub-webs, then access to sub-webs is determined from the access controls of the parent web, plus the access controls in the sub-web. So, if the parent web has ALLOWWEBVIEW set, this will also apply to the subweb. Also note that you will need to ensure that the parent web's FINALPREFERENCES does not include the access control settings listed above. Otherwise you will not be able override the parent web's access control settings in sub-webs.

Creation and renaming of sub-webs is controlled by the WEBCHANGE setting on the parent web (or ROOTCHANGE for root webs). Renaming is additionally restricted by the setting of WEBRENAME in the web itself.

Controlling access to a topic

• You can define these settings in any topic, preferable towards the end of the topic:
  • Set DENYTOPICVIEW = < comma-delimited list of users and groups >
  • Set ALLOWTOPICVIEW = < comma-delimited list of users and groups >
  • Set DENYTOPICCHANGE = < comma-delimited list of users and groups >
  • Set ALLOWTOPICCHANGE = < comma-delimited list of users and groups >
  • Set DENYTOPICRENAME = < comma-delimited list of users and groups >
  • Set ALLOWTOPICRENAME = < comma-delimited list of users and groups >

Caution! Settings are always taken from the latest (current) revision of a topic. If older revisions of a topic had more restrictive access controls, they will not be used when accessing the older revision.

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

Be careful with empty values for any of these.

• Set ALLOWTOPICVIEW =
  This means the same as not setting it at all. (This was documented wrong in versions 4.0.X, 4.1.0 and 4.1.1)

• Set DENYTOPICVIEW =
  This means do not deny anyone the right to view this topic. If DENYTOPICVIEW is set to an empty value anyone has access even if ALLOWTOPICVIEW or ALLOWWEBVIEW is defined. This allows you to have very restrictive default access rights to an entire web and still allow individual topics to have more open access.

The same rules apply to ALLOWTOPICCHANGE/DENYTOPICCHANGE and APPLYTOPICRENAME/DENYTOPICRENAME. Setting ALLOWTOPICCHANGE or ALLOWTOPICRENAME to en empty value means the same as not defining it. Setting DENYTOPICCHANGE or DENYTOPICRENAME to an empty value means that anyone can edit or rename the topic.

If the same setting is defined multiple times the last one overrides the previous. They are not OR'ed together.

Setting to an empty value has caused confusion and great debate and it has been decided that the empty setting syntax will be replaced by something which is easier to understand in a later version of Foswiki. A method to upgrade will be provided. Please read the release notes carefully when you upgrade.

See "How Foswiki evaluates ALLOW/DENY settings" below for more on how ALLOW and DENY interacts.

Controlling access to attachments

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

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

    ScriptAlias /foswiki/bin/ /filesystem/path/to/bin/
    Alias /foswiki/pub/       /filesystem/path/to/pub/

    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/+foswiki/+pub/+System/+.+
    RewriteRule ^/+foswiki/+pub/+([^/]+)((/+([^/]+))+)/+(.+) /foswiki/bin/viewfile/$1/$2?filename=$5 [L,PT]

That way all the controls that apply to the topic also apply to attachments to the topic. Other types of webserver have similar support.

Images embedded in topics will load much slower since each image will be delivered by the viewfile script.

Controlling who can manage top-level webs

Top level webs are a special case, because they don't have a parent web with a WebPreferences. So there has to be a special control just for the root level.

• You can define these settings in the Main.SitePreferences topic, preferably towards the end of the topic:
  • Set DENYROOTCHANGE = < comma-delimited list of users and groups >
  • Set ALLOWROOTCHANGE = < comma-delimited list of users and groups >

Note that you do not require ROOTCHANGE access to rename an existing top-level web. You just need WEBCHANGE in the web itself.

How Foswiki evaluates ALLOW/DENY settings

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

Settings are only read from the most current (latest) revision of a topic. Settings from older revisions are never used, even when viewing an older revision with the rdiff script

1. If the user is an administrator
   • access is PERMITTED.
2. If DENYTOPIC is set to a list of wikinames
   • people in the list will be DENIED.
3. If DENYTOPIC is set to empty ( i.e. Set DENYTOPIC = )
   • access is PERMITTED i.e no-one is denied access to this topic.
     

     Attention: Use this with caution. This is deprecated and will likely change in the next release.

4. If ALLOWTOPIC is set
   1. people in the list are PERMITTED
   2. everyone else is DENIED
5. If DENYWEB is set to a list of wikinames
   • people in the list are DENIED access
6. If ALLOWWEB is set to a list of wikinames
   • people in the list will be PERMITTED
   • everyone else will be DENIED
7. If you got this far, access is PERMITTED

Access control and INCLUDE

ALLOWTOPICVIEW and ALLOWTOPICCHANGE only applies to the topic in which the settings are defined. If a topic A includes another topic B, topic A does not inherit the access rights of the included topic B.

Examples: Topic A includes topic B

• If the included topic B has ALLOWTOPICCHANGE set to block editing for a user, it does not prevent editing the including topic A.
• If the included topic B has ALLOWTOPICVIEW set to block view for a user, the user can still view topic A but he cannot see the included topic B. He will see a message No permission to view B

Access control quick recipes

Obfuscating webs

Another way of hiding webs is by setting the NOSEARCHALL setting in WebPreferences. It does the following:

• Prevents the all webs search option from accessing the web
• Hides the web from the %WEBLIST% macro.

   * Set NOSEARCHALL = on

This setup can be useful to hide a new web until content its ready for deployment, or reduce clutter in the WebLeftBar and default search results when restricted access is not desired.

Setting NOSEARCHALL to any value other than the empty string will hide a web. Setting NOSEARCHALL = off will have the same effect as setting it to on

Obfuscating a web without setting view access control is very insecure, as anyone who knows the URL can access the web, and explicit searches naming that web will also work. For security purposes it is better to use the ALLOW or DENY VIEW settings in the WebPreferences topic. %SEARCH% and %WEBLIST% will not show any results for webs that the current user does not have permission to view.

Restrict Access to a whole Foswiki site

For a firewalled Foswiki, e.g. an intranet wiki or extranet wiki, you want to allow only invited people to access your Foswiki.

With this configuration, someone with access to the site needs to register new users. ResetPassword will also have to be done by administrators.

When using Apache Login

User authentication with ApacheLogin is enabled on your site. To reqire login for all scripts:

• lock down access to the whole bin and pub directories to all but valid users. In the Apache .htaccess file or the appropriate .conf file, replace the <FilesMatch "(attach|edit|... section with this:

<FilesMatch ".*">
       require valid-user
</FilesMatch>

If needed, you can further restrict access to selected webs with ALLOWWEBVIEW and other access control settings.

When using Template Login

User authentication with TemplateLogin is enabled on your site. To require login for all scripts:

• Add all scripts in the foswiki/bin directory (except for login, logon and configure) to the list of {AuthScripts} in configure. For a default Foswiki installation:

• Default (open) site:

{AuthScripts} = 'attach,compareauth,edit,manage,previewauth,rdiffauth,rename,rest,restauth,save,statistics,upload,viewauth,viewfileauth';

• Restricted (closed) site:

{AuthScripts} = 'attach,changes,compare,compareauth,edit,manage,oops,preview,previewauth,rdiff,rdiffauth,register,rename,resetpasswd,rest,restauth,save,search,statistics,upload,view,viewauth,viewfile,viewfileauth

If you install extensions that add scripts, you must also remember to add the new scripts to this list or the new scripts will not be protected.

Authenticate all webs and restrict selected webs

Use the following setup to authenticate users for topic viewing in all webs and to restrict access to selected webs. Requires UserAuthentication to be enabled.

1. The simple way is to add this to WebPreferences in all webs.
   • Set DENYWEBVIEW = WikiGuest
2. Restrict view access to selected users and groups. Set one or both of these settings in its WebPreferences topic:
   • Set ALLOWWEBVIEW = < list of users and groups >
   • Note: DENYWEBVIEW is evaluated before ALLOWWEBVIEW. Access is denied if the authenticated person is in the DENYWEBVIEW list, or not in the ALLOWWEBVIEW list. Access is granted if DENYWEBVIEW and ALLOWWEBVIEW are not defined.

In rare cases it may be required to authenticate the view script. This can in some cases have a dramatic performance hit because the webserver must re-authenticate for every page view.

1. Set require valid-user on your view script in .htaccess or the appropriate Apache .conf file. This looks like: FilesMatch "(attach|edit|manage|rename|save|view|upload|mail|logon|.*auth).*" (normally view is not in that list).

Authenticate and restrict selected webs only

Use the following setup to provide unrestricted viewing access to open webs, with authentication only on selected webs. Requires UserAuthentication to be enabled.

1. Restrict view access to selected users and groups. Set one or both of these settings in its WebPreferences topic:
   • Set DENYWEBVIEW = < list of users and groups >
   • Set ALLOWWEBVIEW = < list of users and groups >
   • Note: DENYWEBVIEW is evaluated before ALLOWWEBVIEW. Access is denied if the authenticated person is in the DENYWEBVIEW list, or not in the ALLOWWEBVIEW list. Access is granted if DENYWEBVIEW and ALLOWWEBVIEW are not defined.

Show control settings

You can list the access controls affecting a topic using the %SHOWPREFERENCE{}% macro in the topic, thus:

%SHOWPREFERENCE{"DENYWEBVIEW,ALLOWWEBVIEW,DENYWEBCHANGE,ALLOWWEBCHANGE,DENYWEBRENAME,ALLOWWEBRENAME"}%

For this topic, this displays:

• Set DENYWEBVIEW = ""
• Set ALLOWWEBVIEW = ""
• Set DENYWEBCHANGE = ""
• Set ALLOWWEBCHANGE = "%USERSWEB%.AdminGroup"
  • ALLOWWEBCHANGE was defined in System.WebPreferences
• Set DENYWEBRENAME = ""
• Set ALLOWWEBRENAME = "%USERSWEB%.AdminGroup"
  • ALLOWWEBRENAME was defined in System.WebPreferences

Hide control settings

To hide access control settings from normal browser viewing, you can put them into the topic preference settings by clicking the link Edit topic preference settings under More topic actions menu. Preferences set in this manner are not visible in the topic text, but take effect nevertheless. Access control settings added as topic preference settings are stored in the topic meta data and they override settings defined in the topic text.

Alternatively, place them in HTML comment markers, but this exposes the access setting during ordinary editing.

<!-- 

   * Set DENYTOPICCHANGE = Main.SomeGroup 

-->

Back to top

---

Text Formatting

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

Editing Shorthand

Formatting Command:	You write:	You get:
Paragraphs: Blank lines will create new paragraphs.	1st paragraph 2nd paragraph	1st paragraph 2nd paragraph
Headings: Three or more dashes at the beginning of a line, followed by plus signs and the heading text. One plus creates a top level heading, two pluses a second level heading, etc. The maximum heading depth is 6. You can create a table of contents with the %TOC% macro. If you want to exclude a heading from the TOC, put !! after the ---+. Empty headings are allowed, but won't appear in the table of contents.	---++ Sushi ---+++ Maguro ---+++!! Not in TOC	Sushi Maguro Not in TOC
Bold Text: Words get shown in bold by enclosing them in * asterisks.	*Bold*	Bold
Italic Text: Words get shown in italic by enclosing them in _ underscores.	_Italic_	Italic
Bold Italic: Words get shown in bold italic by enclosing them in __ double-underscores.	__Bold italic__	Bold italic
Fixed Font: Words get shown in fixed font by enclosing them in = equal signs.	=Fixed font=	Fixed font
Bold Fixed Font: Words get shown in bold fixed font by enclosing them in double equal signs.	==Bold fixed==	Bold fixed
You can follow the closing bold, italic, or other (* _ __ = ==) indicator with normal punctuation, such as commas and full stops. Make sure there is no space between the text and the indicators.	_This works_, _this does not _	This works, _this does not _
Verbatim (Literal) Text: Surround code excerpts and other formatted text with <verbatim> and </verbatim> tags. verbatim tags disable HTML code. Use <pre> and </pre> tags instead if you want the HTML code within the tags to be interpreted. Preferences settings (* Set NAME = value) are set within verbatim tags.	<verbatim> class CatAnimal { void purr() { <code here> } } </verbatim>	class CatAnimal { void purr() { <code here> } }
Verbatim (Literal) Code Highlighting: Surround code excerpts and other formatted text e.g. with <verbatim class="bash"> and </verbatim> tags. This type of code highlighting is based on Chili - the jQuery code highlighter plugin. Please find supported class attributes in System.JQueryChili. verbatim tags disable HTML code. Use <pre class="bash"> and </pre> tags instead if you want the HTML code within the tags to be interpreted. Preferences settings (* Set NAME = value) are set within verbatim tags.	<verbatim class="bash"> #!/bin/bash while [ -n "$(ls . ~/ \ ~/pub* /var/www 2>/dev/null \ | fgrep foswiki )" ] ; do clear printf "\nFoswiki rules!\n" sleep 10 clear printf "\nFoswiki still rules!\n" sleep 10 done; exit 0 </verbatim>	#!/bin/bash while [ -n "$(ls . ~/ \ ~/pub* /var/www 2>/dev/null \ | fgrep foswiki )" ] ; do clear printf "\nFoswiki rules!\n" sleep 10 clear printf "\nFoswiki still rules!\n" sleep 10 done; exit 0
Separator (Horizontal Rule): Three or more three dashes at the beginning of a line..	---
Bulleted List: Multiple of three spaces, an asterisk, and another space. For all the list types, you can break a list item over several lines by indenting lines after the first one by at least 3 spaces.	* level 1 * level 2 * back on 1 * A bullet broken over three lines * last bullet	level 1 level 2 back on 1 A bullet broken over three lines last bullet
Numbered List: Multiple of three spaces, a type character, a dot, and another space. Several types are available besides a number: Type Generated Style Sample Sequence 1. Arabic numerals 1, 2, 3, 4... A. Uppercase letters A, B, C, D... a. Lowercase letters a, b, c, d... I. Uppercase Roman Numerals I, II, III, IV... i. Lowercase Roman Numerals i, ii, iii, iv...	1. Sushi 1. Dim Sum 1. Fondue A. Sushi A. Dim Sum A. Fondue i. Sushi i. Dim Sum i. Fondue	Sushi Dim Sum Fondue Sushi Dim Sum Fondue Sushi Dim Sum Fondue
Definition List: Three spaces, a dollar sign, the term, a colon, a space, followed by the definition.	$ Sushi: Japan $ Dim Sum: S.F.	Sushi Japan Dim Sum S.F.
Definition List: (deprecated) Three spaces, the term (a single word, no spaces), a colon, a space, followed by the definition.	Sushi: Japan Dim-Sum: S.F.	Sushi Japan Dim-Sum S.F.
Table: Each row of the table is a line containing of one or more cells. Each cell starts and ends with a vertical bar '|'. Any spaces at the beginning of a line are ignored. | *bold* | header cell with text in asterisks |   center-aligned   | cell with at least two, and equal number of spaces on either side |      right-aligned | cell with more spaces on the left | 2 colspan || and multi-span columns with multiple |'s right next to each other |^| cell with caret indicating follow-up row of multi-span rows You can split rows over multiple lines by putting a backslash '\' at the end of each line Contents of table cells wrap automatically as determined by the browser Use %VBAR% or &#124; to add | characters in tables. Use %CARET% or &#94; to add ^ characters in tables. The System.TablePlugin provides the |^| multiple-span row functionality and additional rendering features	| *L* | *C* | *R* | | A2 | B2 | C2 | | A3 | B3 | C3 | | multi span ||| | A5-7 | 5 | 5 | |^| six | six | |^| seven | seven | | split\ | over\ | 3 lines | | A9 | B9 | C9 | | %CARET% | B10 |%VBAR%| | &#94; | B11 |&#124;|	L C R A2 B2 C2 A3 B3 C3 multi span A5-7 5 5 six six seven seven split over 3 lines A9 B9 C9 ^ B10 | ^ B11 |
WikiWord Links: CapitalizedWordsStuckTogether (or WikiWords) will produce a link automatically if preceded by whitespace or parenthesis. If you want to link to a topic in a different web write Otherweb.TopicName. To link to a topic in a subweb write Otherweb.Subweb.TopicName. The link label excludes the name of the web, e.g. only the topic name is shown. As an exception, the name of the web is shown for the WebHome topic. Dots '.' are used to separate webs and subwebs from topic names and therefore cannot be used in topic names. It's generally a good idea to use the macros %SYSTEMWEB%, %SANDBOXWEB% and %USERSWEB% instead of System, Sandbox and Main.	%STATISTICSTOPIC% %SANDBOXWEB%.WebNotify %SANDBOXWEB%.WebHome %SANDBOXWEB%.Subweb.TopicName	WebStatistics Sandbox.WebNotify Sandbox.WebHome TopicName
Acronym Links: Words that are all capitals will produce a link automatically only if the topic already exists!.	ACRONYM %SYSTEMWEB%.ACRONYM	ACRONYM System.ACRONYM
Anchors: You can define a reference inside a topic (called an anchor name) and link to that. To define an anchor write #AnchorName at the beginning of a line. The anchor name must be a WikiWord of no more than 32 characters. To link to an anchor name use the [[MyTopic#MyAnchor]] syntax. You can omit the topic name if you want to link within the same topic.	[[WikiWord#NotThere]] [[#MyAnchor][Jump]] #MyAnchor To here	WikiWord#NotThere Jump To here
Forced Links: You can create a forced internal link by enclosing words in double square brackets. Text within the brackets may contain optional spaces; the topic name is formed by capitalizing the initial letter and by removing the spaces; for example, [[wiki syntax]] links to topic WikiSyntax. You can also refer to a different web and use anchors. To "escape" double square brackets that would otherwise make a link, prefix the leading left square bracket with an exclamation point.	[[wiki syntax]] [[Main.Wiki groups]] escaped: ![[wiki syntax]]	wiki syntax Main.Wiki groups escaped: [[wiki syntax]]
Specific Links: You can create a link where you specify the link text and the URL separately using nested square brackets [[reference][text]]. Internal link references (e.g. WikiSyntax) and URLs (e.g. http://foswiki.org/) are both supported. The rules described under Forced Links apply for internal link references. Anchor names can be added as well, to create a link to a specific place in a topic.	[[WikiSyntax][wiki syntax]] [[http://gnu.org][GNU]]	wiki syntax GNU
Prevent a Link: Prevent a WikiWord from being linked by prepending it with an exclamation point.	!SunOS	SunOS
Disable Links: You can disable automatic linking of WikiWords by surrounding text with <noautolink> and </noautolink> tags. It is possible to turn off all auto-linking with a NOAUTOLINK preference setting.	<noautolink> RedHat & SuSE </noautolink>	RedHat & SuSE
Mailto Links: E-mail addresses are linked automatically. To create e-mail links that have more descriptive link text, specify subject lines or message bodies, or omit the e-mail address, you can write [[mailto:user@domain][descriptive text]].	a@b.com [[mailto:a@b.com][Mail]] [[mailto:?subject=Hi][Hi]]	a@b.com Mail Hi
Literal content: Foswiki generates HTML code from TML shorthand. Experts surround anything that must be output literally in the HTML code, without the application of shorthand rules, with <literal>..</literal> tags. Any HTML within literal tags must be well formed i.e. all tags must be properly closed before the end of the literal block. Macros are expanded within literal blocks.	<literal> | Not | A | Table | </literal>	| Not | A | Table |
Protected content: Experts protect text from mangling by WYSIWYG editors using <sticky>..</sticky> tags. Sticky tags don't have any effect on normal topic display; they are only relevant when content has to be protected from a WYSIWYG editor (usually because it isn't well-formed HTML, or because it is HTML that WYSIWYG would normally filter out or modify). Protected content appears as plain text in the WYSIWYG editor. Any HTML within sticky tags must be well formed i.e. all tags must be properly closed before the end of the sticky block. Macros are expanded within sticky blocks.	<sticky> <div> This div %RED%is%ENDCOLOR% required </div> </sticky>	This div is required

Using HTML

You can use most HTML tags in topics without a problem. This is useful where you want to add some content that is formatted in a way that is not supported using wiki syntax, for example, you can write <strike>deleted text</strike> to get deleted text.

There are a few usability and technical considerations to keep in mind:

• On collaboration pages, it's better not to use HTML, but to use wiki syntax instead - this keeps the text uncluttered and easy to edit using the plaintext editor.
• If you must use HTML, use XHTML 1.0 Transitional syntax.
• Use <literal>..</literal> tags around blocks of HTML to avoid accidental interpretation of Wiki syntax within the HTML.

Script tags may be filtered out, at the discretion of your Wiki administrator.

Recommendations when pasting HTML from other sources (using the plain-text editor):

• Copy only text between <body> and </body> tags.
• Remove all empty lines. Foswiki inserts <p /> paragraph tags on empty lines, which causes problems if done between HTML tags that do not allow paragraph tags, like for example between table tags.
• Remove leading spaces. Foswiki might interpret some text as lists.
• Do not span a tag over more than one line. Foswiki requires that the opening and closing angle brackets - <...> - of a HTML tag are on the same line, or the tag will be broken.
• In your HTML editing program, save without hard line breaks on text wrap.

When using a WYSIWYG editor, you can just copy-paste directly into the editor, and the content will be converted to wiki syntax automatically when you save.

Hyperlinks

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

Internal Links

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

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

• ACRONYM links to a topic name consisting of only upper-case letters. Acronyms are linked only if the target topic actually exists.

External Links

• Protocols matching the configuration parameter LinkProtocolPattern, which by default is set to (file|ftp|gopher|https|http|irc|mailto|news|nntp|telnet), are linked automatically. You might change this setting to add more protocols (such as smb).

  LinkProtocolPattern is an expert setting in the Foswiki configuration and can only be changed by a systems administrator.

  Thus, all lines containing:
  • file://...
  • ftp://...
  • gopher://...
  • https://...
  • http://...
  • irc://...
  • mailto:...@...
  • news://...
  • nntp://...
  • telnet://... are linked automatically.
• E-mail addresses like name@domain.com are linked automatically.
• [[Square bracket rules]] let you easily create non-WikiWord links.
  • You can also write [[http://yahoo.com Yahoo home page]] as an easier way of doing external links with descriptive text for the link, such as Yahoo home page.

Macros

Macros are names enclosed in percent signs that are that are expanded to some other text when the topic is displayed. For example, %TOPIC% is expanded to TextFormattingRules, the title of this topic.

Some macros can take arguments in curly braces - for example, %INCLUDE{"OtherTopic" ARG="arg"}%.

Many macro definitions are built-in, and others (preference settings) are predefined for your convenience. You can also define your own preference settings at the entire site, individual web, or individual topic level. For more information, see Macros

Macros are fully expanded before any of the text formatting rules are applied.

Plugin Formatting Extensions

Plugins can extend the functionality of Foswiki into many other areas. There are a huge number of plugins available from the foswiki site.

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

• System.SpreadSheetPlugin (1.1.7, v1.1.7): Add spreadsheet calculations like "$SUM($ABOVE())" to Foswiki tables and other topic text
• System.AutoViewTemplatePlugin (2012-12-16, v1.1.7): Automatically sets VIEW_TEMPLATE and EDIT_TEMPLATE
• System.CommentPlugin (1.1.6, v1.1.6): Quickly post comments to a page without an edit/save cycle
• System.CompareRevisionsAddonPlugin (1.1.11, v1.1.11):
• System.EditTablePlugin (4.43, 4.43): Edit tables using edit fields, date pickers and drop down boxes
• System.HistoryPlugin (1.11, 1.11): Shows a complete history of a topic
• System.InterwikiPlugin (1.1.7, v1.1.7): Link ExternalSite:Page text to external sites based on aliases defined in a rules topic
• System.JQueryPlugin (4.91, 4.91): jQuery JavaScript library for Foswiki
• System.MailerContribPlugin (2.5.3, v2.5.3): Supports e-mail notification of changes
• System.PreferencesPlugin (1.1.5, v1.1.5): Allows editing of preferences using fields predefined in a form
• System.RenderListPlugin (2.2.7, v2.2.7): Render bullet lists in a variety of formats
• System.SlideShowPlugin (2.1.6, v2.1.6): Create web based presentations based on topics with headings
• System.SmiliesPlugin (28 Nov 2012, v1.1.6): Render smilies like as icons
• System.TablePlugin (1.142, 1.142): Control attributes of tables and sorting of table columns
• System.TinyMCEPlugin (1.2.9, v1.2.9): Integration of the Tiny MCE WYSIWYG Editor
• System.TwistyPlugin (1.6.18, v1.6.18): Twisty section Javascript library to open/close content dynamically
• System.WysiwygPlugin (16 May 2013, v1.1.16): Translator framework for WYSIWYG editors

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

Common Editing Errors

Foswiki formatting rules are fairly simple to use and quick to type. However, there are some things to watch out for:

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

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

Back to top

---

No permission to view System.Macros

Back to top

---

Formatted Search

Customize the display of search results.

The default output format of a %SEARCH{...}% is a table consisting of topic names and topic summaries. Use the format="..." parameter to customize the search result. The format parameter typically defines a bullet or a table row containing macros, such as %SEARCH{ "food" format="| $topic | $summary |" }%. See %SEARCH{...}% for other search parameters, such as separator="".

Syntax

Three 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:* |"

Format tokens that can be used in the header string:

Name:	Expands To:
$web	Name of the web
$ntopics	Number of topics found in current web. Will be 0 (zero).
$nhits	Number of hits if multiple="on". Will be 0 (zero).
$pager	pager control - can be optionally customised using the pagerformat below
$n or $n()	New line. Use $n() if followed by alphanumeric character, e.g. write Foo$n()Bar instead of Foo$nBar Most macros accept parameter strings which are split over multiple lines. This is usually more readable than using $n tokens. If you are familiar with sectional includes, you might also consider nested sectional includes to hold the newline content outside of the parameter string entirely. Note that newline is not a line break. The browser will wrap the lines together. If you require a line break, displaying the results on two lines, use %BR%. Or use two consecutive newlines to create a TML "Paragraph".
$nop or $nop()	Is a "no operation". This token gets removed; useful for nested search
$quot	Double quote (") (\" also works)
$percent	Percent sign (%) ($percnt also works)
$dollar	Dollar sign ($)
$lt	Less than sign (<)
$gt	Greater than sign (>)
$amp	Ampersand (&)
$comma	Comma (,)

Note that if the separator parameter for SEARCH is not defined a newline is added after the header.

2. footer="..." parameter

Use the footer parameter to specify the footer of a search result. It should correspond to the format of the format parameter. This parameter is optional. Example:

footer="| *Total:* | *$nhits* |"

Format tokens that can be used in the footer string:

Name:	Expands To:
$web	Name of the web
$ntopics	Number of topics found in current web
$nhits	Number of hits if multiple="on". Cumulative across all topics in current web. Identical to $ntopics unless multiple="on"
$pager	pager control - can be optionally customised using the pagerformat below
$n or $n()	New line. Use $n() if followed by alphanumeric character, e.g. write Foo$n()Bar instead of Foo$nBar Most macros accept parameter strings which are split over multiple lines. This is usually more readable than using $n tokens. If you are familiar with sectional includes, you might also consider nested sectional includes to hold the newline content outside of the parameter string entirely. Note that newline is not a line break. The browser will wrap the lines together. If you require a line break, displaying the results on two lines, use %BR%. Or use two consecutive newlines to create a TML "Paragraph".
$nop or $nop()	Is a "no operation". This token gets removed; useful for nested search
$quot	Double quote (") (\" also works)
$percent	Percent sign (%) ($percnt also works)
$dollar	Dollar sign ($)
$lt	Less than sign (<)
$gt	Greater than sign (>)
$amp	Ampersand (&)
$comma	Comma (,)

Note that if the separator parameter for SEARCH is not defined a newline is added after the last search result.

3. pagerformat="..." parameter

Use the pagerformat parameter to customise the appearance of the paging control. It should correspond to the format of the format parameter. This parameter is optional. Example:

pagerformat="Page $currentpage of $numberofpages [[$nexturl][next page]]"

Format tokens that can be used in the pagerformat string:

Name:	Expands To:
$previouspage	The page number before the currently displayed one
$currentpage	The currently displayed page number
$nextpage	The page number after the currently displayed one
$numberofpages	Total number of pages there are results for
$pagesize	The number of results per page
$previousurl	full URL to the previous page - IF using the built in pager system
$nexturl	full URL to the previous page - IF using the built in pager system
$previousbutton	skin template (SEARCH:pager_previous) html for the full URL to the previous page - IF using the built in pager system
$nextbutton	skin template (SEARCH:pager_next) html for the full URL to the previous page - IF using the built in pager system
$n or $n()	New line. Use $n() if followed by alphanumeric character, e.g. write Foo$n()Bar instead of Foo$nBar Most macros accept parameter strings which are split over multiple lines. This is usually more readable than using $n tokens. If you are familiar with sectional includes, you might also consider nested sectional includes to hold the newline content outside of the parameter string entirely. Note that newline is not a line break. The browser will wrap the lines together. If you require a line break, displaying the results on two lines, use %BR%. Or use two consecutive newlines to create a TML "Paragraph".
$nop or $nop()	Is a "no operation". This token gets removed; useful for nested search
$quot	Double quote (") (\" also works)
$percent	Percent sign (%) ($percnt also works)
$dollar	Dollar sign ($)
$lt	Less than sign (<)
$gt	Greater than sign (>)
$amp	Ampersand (&)
$comma	Comma (,)

4. format="..." parameter

Use the format parameter to specify the format of one search hit. Example:

format="| $topic | $summary |"

Format tokens that can be used in the format string:

Name:	Expands To:
$web	Name of the web
$topic	Topic name
$topic(20)	Topic name, "- " hyphenated every 20 characters
$topic(30, -<br />)	Topic name, hyphenated every 30 characters with separator "-<br />"
$topic(40, ...)	Topic name, shortened to 40 characters with trailing ellipsis.
$parent	Name of parent topic; empty if not set
$parent(20)	Name of parent topic, same hyphenation/shortening as $topic()
$text	Formatted topic text. In case of a multiple="on" search, it is the line found for each search hit.
$locked	LOCKED flag (if any)
$date	Time stamp of last topic update, e.g. 26 Dec 2024 - 04:21
$isodate	Time stamp of last topic update, e.g. 2024-12-26T04:21Z
$index	number of total results - can be used as a running counter in the format, or in the footer. This $index is not affected by web based partitioning of results.
$item	the full name of a result item - in a SEARCH context, equivalent to $web.$topic
$rev	Number of last topic revision, e.g. 4
$username	Login name of last topic update, e.g. jsmith
$wikiname	Wiki user name of last topic update, e.g. JohnSmith
$wikiusername	Wiki user name of last topic update, like Main.JohnSmith
$createdate	Time stamp of topic revision 1
$createusername	Login name of topic revision 1, e.g. jsmith
$createwikiname	Wiki user name of topic revision 1, e.g. JohnSmith
$createwikiusername	Wiki user name of topic revision 1, e.g. Main.JohnSmith
$summary	Topic summary, just the plain text, all formatting and line breaks removed; up to 162 characters
$summary(50)	Topic summary, up to 50 characters shown
$summary(showvarnames)	Topic summary, with %SOMEMACRO{...}% macros shown as SOMEMACRO{...}
$summary(noheader)	Topic summary, with leading ---+ headers removed Note: The tokens can be combined, for example $summary(100, showvarnames, noheader)
$summary(searchcontext)	Creates a topic summary with the search terms highlighted
$summary(searchcontext, 50)	Creates a topic summary with the search terms highlighted, up to 50 characters
$changes	Summary of changes between latest rev and previous rev
$changes(n)	Summary of changes between latest rev and rev n
$formname	The name of the form attached to the topic; empty if none
$formfield(name)	The field value of a form field; for example, if FAQWhatIsWikiWiki was a search hit, $formfield(TopicClassification) would get expanded to ==. This applies only to topics that have a DataForm. For multi-line textfields new lines are replace by an HTML <br />
$formfield(name, 10)	Form field value, "- " hyphenated every 10 characters
$formfield(name, 20, -<br />)	Form field value, hyphenated every 20 characters with separator "-<br />"
$formfield(name,30,...)	Form field value, shortened to 30 characters with trailing ellipsis.
$formfield(name, display)	Form field value after mapping the stored value to the display value (use with +values form fields). You can still use the hyphenation controls described above by placing them after display e.g. $formfield(name, display, 10)
$pattern(reg-exp)	A regular expression pattern to extract some text from a topic (does not search meta data; use $formfield instead). In case of a multiple="on" search, the pattern is applied to the line found in each search hit. • Specify a RegularExpression that covers the whole text (topic or line), which typically starts with .*, and must end in .* • Put text you want to keep in parenthesis, like $pattern(.*?(from here.*?to here).*) • Example: $pattern(.*?\*.*?Email\:\s*([^\n\r]+).*) extracts the e-mail address from a bullet of format * Email: ... • This example has non-greedy .*? patterns to scan for the first occurance of the Email bullet; use greedy .* patterns to scan for the last occurance • Limitation: Do not use .*) inside the pattern, e.g. $pattern(.*foo(.*)bar.*) does not work, but $pattern(.*foo(.*?)bar.*) does • Note: Make sure that the integrity of a web page is not compromised; for example, if you include an HTML table make sure to include everything including the table end tag
$count(reg-exp)	Count of number of times a regular expression pattern appears in the text of a topic (does not search meta data). Follows guidelines for use and limitations outlined above under $pattern(reg-exp). Example: $count(.*?(---[+][+][+][+]) .*) counts the number of <H4> headers in a page.
$ntopics	Number of topics found in current web. This is the current topic count, not the total number of topics
$nhits	Number of hits if multiple="on". Cumulative across all topics in current web. Identical to $ntopics unless multiple="on"
$pager	pager control - can be optionally customised using the pagerformat below
$n or $n()	New line. Use $n() if followed by alphanumeric character, e.g. write Foo$n()Bar instead of Foo$nBar Most macros accept parameter strings which are split over multiple lines. This is usually more readable than using $n tokens. If you are familiar with sectional includes, you might also consider nested sectional includes to hold the newline content outside of the parameter string entirely. Note that newline is not a line break. The browser will wrap the lines together. If you require a line break, displaying the results on two lines, use %BR%. Or use two consecutive newlines to create a TML "Paragraph".
$nop or $nop()	Is a "no operation". This token gets removed; useful for nested search
$quot	Double quote (") (\" also works)
$percent	Percent sign (%) ($percnt also works)
$dollar	Dollar sign ($)
$lt	Less than sign (<)
$gt	Greater than sign (>)
$amp	Ampersand (&)
$comma	Comma (,)

Examples

Here are some samples of formatted searches. The SearchPatternCookbook has other examples, such as creating a picklist of usernames, searching for topic children and more.

Search showing topic name and summary

Write this:

%SEARCH{
   "VarREMOTE"
   scope="topic"
   nonoise="on"
   header="| *Topic*        | *Summary*  |"
   format="| [[$topic]]     | $summary   |"
   footer="| *Topics found* | *$ntopics* |"
}%

To get this:

Topic	Summary
Topics found	3
VarREMOTEADDR	#VarREMOTEADDR REMOTE_ADDR environment variable * Syntax: %REMOTE_ADDR% * Expands to: == * Related: ENV, HTTP_HOST, REMOTE_PORT, REMOTE_USER
VarREMOTEPORT	#VarREMOTEPORT REMOTE_PORT environment variable * Syntax: %REMOTE_PORT% * Expands to: * Related: ENV, HTTP_HOST, REMOTE_ADDR, REMOTE_USER
VarREMOTEUSER	#VarREMOTEUSER REMOTE_USER environment variable * Syntax: %REMOTE_USER% * Expands to: * Related: ENV, HTTP_HOST, REMOTE_ADDR, REMOTE_PORT, USERNAME, WIKINAME ...

Table showing form field values of topics with a form

In a web where there is a form that contains a TopicClassification field, an OperatingSystem field and an OsVersion field we could write:

| *Topic:* | *!OperatingSystem:* | *!OsVersion:* |
%SEARCH{
   "TopicClassification~'FrequentlyAskedQuestion'"
   type="query"
   nonoise="on"
   format="| [[$topic]] | $formfield(OperatingSystem) | $formfield(OsVersion) |"
}%

To get this (simulated):

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

Extract some text from a topic using regular expression

The following example makes use of the $pattern() token to extract the first level-1 heading for each topic:

%SEARCH{
    "^---[+][^+][^\r\n]+[\r\n]"
    type="regex"
    nonoise="on"
    header="Headings:"
    limit="5"
    format="   * [[$topic][$pattern([\r\n\-+!]+([^\r\n]*?)[\r\n].*)]]"
    footer="Found $ntopics topics with level-1 headings"
}%

Test case

Headings:

• What is an ACRONYM?
• Access Control
• A List of Wiki Administrator Documentation
• Administrator Skills Assumptions
• Admin tools

Found 5 topics with level-1 headings

Nested Search

SEARCH is one of many macros that produce output which may be controlled with format, header and footer parameters, among others. To make use of additional macros in the output, familiarity with inside-out, left-to-right order of expansion rules is required. There are two forms:

1. Standard: Use %INNERMACRO% to build the parameter string before %OUTERMACRO% is expanded

    %OUTERMACRO{
      format="%INNERMACRO%"
    }%

2. Delayed: Use the parameter string to incorporate %INNERMACRO% into the output of %OUTERMACRO%

    %OUTERMACRO{
      format="$percentINNERMACRO$percent"
    }%

   No permission to view System.Macros

No permission to view System.Macros

Worked example

Problem: search for some topics in an initial (outer) search, and for each of them apply a second (inner) search. The idea is to use the outer search to build a series of inner seraches.

Consider the following example. Let's search for all topics that contain the word "culture" (outer search), and find out where each topic found is linked from (inner search).

Initial (outer) search:

%SEARCH{
   "culture"
   nonoise="on"
   format="   * $topic is referenced by: (list all references)"
}%

Second (inner) search:

For each hit, we want this search:

%SEARCH{
   "(topic found in outer search)"
   nonoise="on"
   format="$topic"
   separator=", "
}%

Now let's nest the two.

Method 1 (nesting with escapes)

The inner search cannot be placed directly into the format string of the outer, because of the "inside-out, left-to-right" macro expansion behaviour discussed earlier. It must be delayed so that the outer search is evaluated first. To do this, we need to escape the inner search, i.e. let the outer search build a series of searches comprised of the inner search.

• Use $percent to escape (delay) the inner search's SEARCH macro
• Use \" to escape the double quotes
• Use $dollar to escape the $ of $topic

Write this:

%SEARCH{
   "culture"
   nonoise="on"
   limit="5"
   format="\
   * $topic is referenced by:
      * $percentSEARCH{
         \"$topic\"
         nonoise=\"on\"
         format=\"$dollartopic\"
         separator=\", \"
      }$percent"
}%

To get this:

• AccessControl is referenced by:
  • AdminDocumentationCategory, CommandAndCGIScripts, CompleteDocumentation, DataForms, DefaultPreferences, DevelopingPlugins, FAQHiddenUsersAndGroups, FAQRebuildingWikiUsersTopic, FileAttachment, InstallationGuidePart1, ManagingTopics, ManagingUsers, PreferenceSettings, PublishedAPI, ReferenceManual, ReleaseHistory, ReleaseNotes01x00, ReleaseNotes01x01, SitePermissions, SiteTools, SkinTemplates, TipTopic017, TopicsAndWebs, TwentyMinuteTutorial, UserAuthentication, VarSEARCH, WebPreferencesHelp, WikiWord
• BeginnersStartHere is referenced by:
  • PatternSkinElements, ReleaseNotes01x00, ReleaseNotes01x01, UserDocumentationCategory, WebHome, WebLeftBarExample, WelcomeGuest
• FAQWhatIsWikiWiki is referenced by:
  • DataForms, FAQWhatIsWikiWiki, FormattedSearch, UserDocumentationCategory
• FormattedSearch is referenced by:
  • AccessControl, BookView, CompleteDocumentation, DataForms, DeveloperDocumentationCategory, EditTablePlugin, FormatTokens, IfStatements, MetaData, QuerySearch, ReferenceManual, ReleaseHistory, ReleaseNotes01x00, ReleaseNotes01x01, RenderListPlugin, SearchHelp, SearchPatternCookbook, SiteTools, SpreadSheetPlugin, TopicsAndWebs, TwistyPlugin, UserDocumentationCategory, VarFORMAT, VarMETASEARCH, VarSEARCH, VarURLPARAM, WebLeftBarExample, WebPreferences
• UserDocumentationCategory is referenced by:
  • ACRONYM, AccessControl, AccessKeys, AdminDocumentationCategory, AdminToolsCategory, BookView, BumpyWord, CompleteDocumentation, DataForms, DeveloperDocumentationCategory, DocumentGraphics, DontNotify, FAQAnApplicationWithWikiForm, FAQDeleteOrRenameATopic, FAQDeleteOrRenameAnAttachment, FAQEditDoesNotIncreaseTheRevision, FAQGnuGeneralPublicLicense, FAQSimultaneousEdits, FileAttachment, FileAttribute, ForceNewRevision, FormattedSearch, GlossaryOfTerms, GoBox, GoodStyle, HiddenAttachment, IncludeTopicsAndWebPages, InterWikis, LoginName, MainFeatures, ManagingTopics, ProjectLogos, QuietSave, ReferenceManual, RegularExpression, SearchPatternCookbook, SitePermissions, SkinBrowser, StandardColors, TextEditor, TimeSpecifications, TopicsAndWebs, TwentyMinuteTutorial, UserToolsCategory, UsingHTML, WabiSabi, WebLeftBarExample, WikiNotation, WikiWikiClones, WikiWord, YouAreHere

When nesting with escapes, each new nesting level must "escape the escapes", e.g. write $dollarpercentSEARCH{ for level three, $dollardollarpercentSEARCH{ for level four, etc.

Method 2 (nesting with sectional includes)

Nested expressions with delayed macros can be difficult to write: care must be taken to escape all the quotes of the inner delayed macro, and it may become confusing whether to use $topic, $dollartopic or $dollardollartopic.

If you find yourself using escaped tokens like $dollartopic, another approach is to use the STARTSECTION/ENDSECTION feature of INCLUDE. Instead of nesting the inner search expression directly inside the format string of the outer, the inner search is written as a separate stand-alone section of a topic which is INCLUDEd into the format string of the outer.

Write this:

%SEARCH{
   "culture"
   nonoise="on"
   limit="5"
   format="\
   * $topic is referenced by:
      * $percentINCLUDE{\"%TOPIC%\" section=\"mysearch\" thetopic=\"$topic\"}$percent"
}%

<!-- HTML comment to hide this section from the user and web browser's DOM.
     verbatim prevents the section being evaluated. Alternatively, sections
     like this can be placed into dedicated utility topics which may hold
     many such re-usable pieces of your wiki application
<verbatim>
%SEARCH{
   "%thetopic%"
   nonoise="on"
   format="$topic"
   separator=", "
}%
</verbatim>
-->

Output will be the same as for the first method

Nested search can be slow, especially if you nest more than 3 levels deep. Nesting is limited to 16 levels.

Most recently changed pages

Write this:

%SEARCH{
   "1"
   type="query"
   nonoise="on"
   order="modified"
   reverse="on"
   limit="7"
   format="| [[$topic]] | $wikiusername  | $date |"
}%

To get this:

WebTopBarExample	Main.UrsBeyerle	19 Mar 2017 - 09:57
WebPreferences	Main.UrsBeyerle	19 Mar 2017 - 09:53
WebLeftBarWebsList	Main.MiriamKuebbeler	21 Feb 2014 - 10:24
WebTemplateTopics	Main.ProjectContributor	23 Sep 2011 - 21:18
WebSearch	Main.ProjectContributor	01 Jul 2011 - 02:16
WikiSyntax	Main.ProjectContributor	19 Sep 2010 - 14:08
WikiName	Main.ProjectContributor	19 Sep 2010 - 14:08

Search with conditional output

Sometimes it may be desirable for each hit to be displayed differently depending on some criteria. For example, maybe you want to list 20 topics modified in 2009, but decorate the hits which are children of UserDocumentationCategory with an icon.

1. Specify a search which returns the hits you need
2. For each search hit, test the condition that will influence the output using a nested IF statement

Write this:

%SEARCH{
   "info.date >= d2n('2009-01-01') AND info.date <= d2n('2009-12-31')"
   type="query"
   limit="20"
   format="   * $percentICON{
      \"$percentIF{
         \"'$topic'/parent.name='UserDocumentationCategory'\"
         then=\"info\"
         else=\"gear\"
      }$percent\"
   }$percent [[$topic]]"
}%

Details:

• The SEARCH has a delayed ICON. The $percent ensures that ICON is evaluated once for each search hit
• The ICON contains an IF, which again is delayed with the $percent token and will also be evaluated for each SEARCH hit. Additionally, the inside-out, left-to-right rule discussed earlier means that this IF expression will be evaluated before ICON.
• If $topic is a child of UserDocumentationCategory, the info icon is used; otherwise, gear.

To get this:

• AccessKeys
• AdminSkillsAssumptions
• BookView
• BumpyWord
• DefaultWebStatistics
• DontNotify
• EnhancementRequests
• ExampleTopicTemplate
• FamFamFamSilkCompanion1Icons
• FamFamFamSilkCompanion2Icons
• FamFamFamSilkIcons
• FileAttribute
• HiddenAttachment
• HierarchicalNavigationChildExample
• JQueryBgiframe
• JQueryEmpty
• JQueryFoswiki
• JQueryMigrate
• JQuerySupersubs
• JQueryTreeview

Embedding search forms to return a formatted result

Use an HTML form and an embedded formatted search on the same topic. You can link them together with an URLPARAM macro. Example:

Write this:

<form action="%SCRIPTURLPATH{"view"}%/%WEB%/%TOPIC%">
Find Topics:
<input type="text" name="q" size="32"\
  value="%URLPARAM{"q" encode="entity"}%" />&nbsp;<input\
  type="submit" class="foswikiSubmit" value="Search" />
</form>

Result:
%SEARCH{
   "%URLPARAM{"q" encode="quote"}%"
   type="keyword"
   nosearch="on"
   format="   * $web.$topic: %BR% $summary"
}%

To get this:

Find Topics:  

Result:

---

Related Topics: UserDocumentationCategory, SearchHelp, Macros#VarSEARCH, SearchPatternCookbook, RegularExpression

Back to top

---

File Attachments

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

What are attachments good for?

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

Document management system

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

File sharing

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

Web authoring

Through your web browser, you can easily upload graphics (or sound files, or anything else you want to link to on a page) and place them on a single page, or use them across a web, or site-wide.

You can also add graphics - any files - directly, typically by FTP upload. This requires FTP access, and may be more convenient if you have a large number of files to load. FTP-ed files cannot be managed using browser-based attachment controls. You can use your browser to create shortcuts using Macros, like this %H% = .

Attachment Names

Attachment names are stored directly in the server native file system, so filenames are sanitized to prevent use of names that would be unacceptable to the variety of platforms where Foswiki is supported. Note that the rules are different depending on whether or not your installation is configured to support international characters (UseLocale)

Default rules without international character set support.

• Filenames must only be compose of:
  • "Mixed Alpha-Numeric" characters. (A-Z, a-z and 0-9)
  • May also contain:
    • . (period / decimal point / "dot")
    • _ (Underscore)
    • - (Hyphen or dash)
    • embedded spaces (Will be converted to underscore (_) during upload
• Any other characters are removed from the filename.
• Any leading dots or slashes (., \ or /) will be stripped
• Embedded spaces will be converted to underscore _
• Certain filenames that might be interpreted as executable code will have .txt appended. (This is set locally by your system administrator)

Attachment name rules with international character set support enabled.

• Embedded spaces are converted to _ (Underscore).
• Filenames are filtered according to rules set by your administrator.
• The default rules will strip the following characters from the filename:
  • Any "whitespace" characters
  • * (Asterisk)
  • ? (Question mark)
  • ~ (Tilde)
  • ^ (Caret / Circumflex)
  • \ (Backslash)
  • $ (Dollar-sign)
  • @ (At-sign)
  • % (Percent-sign)
  • `'" Quotes (Open-quote, Close-quote/Apostrophe, and Double-quote)
  • & (Ampersand)
  • ; (Semicolon)
  • | (Vertical line)
  • <> (Less and Greater signs)
  • [] (Open and close square brackets)
  • And any ASCII control characters (Hex x00-x1f)
• Any leading dots or slashes (., \ or /) will be stripped
• Certain filenames that might be interpreted as executable code will have .txt appended. (This is set locally by your system administrator)

Uploading files

• Click on the [Attach] link at the bottom of the page. The Attach screen lets you browse for a file, add a comment, and upload it. The uploaded file will show up in the file attachment table.

  The topic must already exist. If it does not, it is a two step process: First create the topic, then add the file attachment.

  • Any type of file can be uploaded. Some files that might pose a security risk are renamed, for example: *.php files are renamed to *.php.txt so that no one can place code that would be read in a .php file.
  • Foswiki can limit the file size. This is defined by the %ATTACHFILESIZELIMIT% preference settings, currently set at 35000 kB.

    It is not recommended to upload files greater than a few hundred K through a browser. Large files can be extremely slow-loading, and often time out. Use an FTP site for large file uploads.

• Automatic attachments:
  • When enabled, all files with valid names in a topic's attachment directory are shown as attachments to the topic - even if they were directly copied to the directory and never attached by using an [Attach] link. This is a convenient way to quickly "attach" files to a topic without uploading them one by one; although at the cost of losing audit trail and version control.
    • Before an attachment is shown, the filename is filtered per the above Attachment name rules. If the filtered name is not identical to the actual file name, the file will not be included in the list of attachments
  • To enable this feature, set the {AutoAttachPubFiles} configuration option.

    The automatic attachment feature can only be used by an administrator who has access to the server's file system.

• Linking to the attached file in the topic:
  • Checking the "Create a link to the attached file" appends a link at the end of the topic. The format can be modified with the %ATTACHEDFILELINKFORMAT% preference setting. Images (files ending in gif, jpg, jpeg or png) are handled by %ATTACHEDIMAGEFORMAT%.
  • The two named preference settings may use the following variables:
    • $filename: the name of the file
    • $fileurl: URL encoded version of the filename
    • $comment: the file comment from the upload dialog
    • $size: the filesize (%ATTACHEDIMAGEFORMAT% only)
    • $name: (deprecated, should no longer be used)

Downloading files

• Click on the file in the File Attachment table.

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

Moving attachment files

An attachment can be moved between topics.

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

Deleting attachments

Move unwanted Attachments to web Trash, topic TrashAttachment.

Linking to attached files

• Once a file is attached it can be referenced in the topic. Example:
  1. [Attach] a file, for example: Sample.txt
  2. [Edit] the topic you attached the file to and enter: %ATTACHURL%/Sample.txt
  3. [Preview]: the %ATTACHURL%/Sample.txt text appears as: https://wiki.bacchus-env.eu/pub/System/FileAttachment/Sample.txt, a link to the text file.

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

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

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

Securing Attachments

In most installations, attachments are not secured. Anyone can read them if they know the name of the web, topic and attachment.

To secure attachments, you have to control access to the attachments through the viewfile script, which requires a change in your web server configuration. To see how to configure Apache to do this, see http://foswiki.org/Support/ApacheConfigGenerator#Attachments

Examples

Following you will find some examples of screens and tables related to this topic and referenced throughout the previous text. The appearance of these tables might vary, depending on what skin is used on your Foswiki installation.

File attachment table

Files attached to a topic are displayed in a directory table, showing the different file names and attributes. An h means the attachment is hidden and not listed when viewing a topic in normal mode.

The file attachment table is normally displayed at the bottom of the page, or optionally, hidden and accessed when you click [Attach].

File attachment controls

Clicking on a [Manage] link takes you to a new page that looks a bit like this (depending on what skin is selected).

Here, you have different options:

• To update an existing file, choose the updated file on your local drive and click [Update file]. The filename of the original attachment will preserved; the filename of the local file you chose will not be used.
• To change the comment on an attachment, enter a new comment and then click [Change comment and properties only]. Note that the comment listed against the specific version will not change, however the comment displayed when viewing the topic does change.
• To hide/unhide an attachment, enable the Do not show attachment in table checkbox, then click [Change comment and properties only].

Back to top

---

Data Forms

This page introduces structured data, and explains how to set up and work with data forms.

Overview

Next to freeform topic contents, each topic can store additional data in name/value pairs.

Topic data is normally not visible when you view a topic (except for a small table at the bottom of the topic - dependent on the used skin). Topic data works "behind the scenes" and facilitates searches, reports and custom displays.

Topic data, or better: structured data, can be used in many ways. The Foswiki Support questions serves as a demonstration how topic data can be used:

• To create a complete list of "Support Questions" topics
• To show a subset of all questions that have not been answered yet
• To display the title and subject of each question

Another uses for structured data could be:

• Create a list of all contributions of one particular author
• Create a quick report of all employee names and phone numbers
• Create a software documentation repository
• Create and track tasks
• Create a bug tracker

To work with topic data, you will need 3 things:

1. The data definition, specified in a table in a "data form" topic. The table lists all fields and their types - see The data definition.
2. The web's WebPreferences needs to list the form in the WEBFORMS setting - see Enabling forms.
3. The form must get connected to the topic - see Adding a form to a topic.

Then you are ready to enter data values for each topic.

Optional further steps are:

1. Create a template topic so that new topics based on that template have the form already added - see Template topics.
2. Build an HTML form to create new topics based on that template topic, or to pass field values from the HTML form to the data form.
3. Build a search to create a report from the stored data

For a step by step tutorial, see the FAQ How can I create a simple data form based application?.

The data definition

Topics can store data as name/value pairs, or form fields. The attributes of each form field are specified in the data definition, which is an ordinary topic.

The data form topic

The data definition is defined in a TML table and looks like this:

| *Name*  | *Type* | *Size* | *Values* | *Tooltip message* | *Attributes* |
| TopicTitle | text | 100 | | | H |
| Version | select | 1 | ,Version in SVN,Foswiki 1.1.4,Foswiki 1.1.3,Foswiki 1.1.2,Foswiki 1.1.1 | | |
| Status | select | 1 | Asked,More info required,Answered | | M |
| Related Topics | textboxlist | | | |

In the next section we'll go into the details of the table contents.

The name of the data form topic usually ends with "Form". For example, the form topic for the Support Questions is named "QuestionForm". The form topic can be placed in any web, but usually this is in the same web as the topics that will be using it.

The form table

A form is to a web as a table is to a database. -- Andrew Steele

The data form table is a kind of spreadsheet:

• Each row of the table specifies one form field
• The table header defines what attributes of the form fields need to be specified

Header row

Each column name in the table header row is one element of an entry field:

| *Name*  | *Type* | *Size* | *Values* | *Tooltip message* | *Attributes* |

Only Name, Type and Size are required. So the minimum table has this header row:

| *Name* | *Type* | *Size* |

A simple form just supporting entry of a name and a date would be:

| *Name* | *Type* | *Size* |
| Name   | text   | 80     |
| Date   | date   | 30     |

Form field rows

Each form field is defined by these attributes:

Name	The name of the form field; must be unique for that form.
Type	The data type: text, date, single or multi-value, labels (read-only). The type also defines how form field data can be entered in the edit screen, such as text field or radio buttons.
Size	The input size of the form field inputs on the edit screen.
Values	For checkboxes, radio buttons and dropdown lists: predefined input to select from. More advanced: this can be a dynamically generated list of values.
Tooltip message	(hardly used or useful anymore) A message that will be displayed when the cursor is hovered over the field in edit view.
Attributes	Whether the field is mandatory or hidden in view mode.

As said, only Name, Type and Size are required.

Form field attributes

Name

The name of the form field.

• Names have to be unique for each data definition.
• A very few field names are reserved. If you try to use one of these names, Foswiki will automatically append an underscore to the name when the form is used. But do not use the field name undefined (or any variant of that name, such as UnDefined), as that name is reserved for use in search queries.
• You can space out the title of the field, and it will still find the topic e.g. Aeroplane Manufacturers is equivalent to AeroplaneManufacturers.
• If a label field has no name, it will not be shown when the form is viewed, only when it is edited.
• Field names can in theory include any text, but you should stick to alphanumeric characters. If you want to use a non-wikiname for a select, checkbox or radio field, and want to get the values from another topic, you can use [[...]] double bracket links. This notation can also be used when referencing another topic to obtain field values, but a name other than the topic name is required as the name of the field.
• If you want the Field name to include embedded spaces, use the format [<nop>[FieldName][Descriptive human-friendly Field Name]].
• Leading and trailing spaces do not matter.

Type

The data type defines the kind of input: text, date, single or multi-value, or labels (read-only). This is done by setting the type of interface control on the edit screen: checkbox, radio button, text field, and so on.

The control appearance is also specified by size and (initial) value. More on those attributes below.

Type	Description	Size attribute	Value attribute	Modifiers
checkbox	One or more checkboxes.	How many checkboxes will be displayed on each line.	A comma-separated list of item labels.	checkbox+buttons will add Set and Clear buttons to the basic checkbox type. checkbox+values allows the definition of values that are different to the displayed text.
date	A single-line text box and a calendar icon button next to it; clicking on the button will bring up a calendar from which the user can select a date. The date can also be typed into the text box.	The text box width in characters.	The initial text.
label	Read-only label text.		The text of the label.
radio	Like checkbox except that radio buttons are mutually exclusive; only one can be selected.			radio+values allows the definition of values that are different to the displayed text.
select	A select box / dropdown.	A fixed size for the box (e.g. 1, or a range e.g. 3..10. To get a dropdown, use size 1. If you specify a range, the box will never be smaller than 3 items, never larger than 10, and will be 5 high if there are only 5 options. Caution size 1 dropdown is incompatible with select+multi modifier on some browsers.	A comma-separated list of options for the box.	select+multi turns multiselect on for the select, to allow Shift+Click and Ctrl+Click to select (or deselect) multiple items. select+values allows the definition of values that are different to the displayed text. You can combine these modifiers e.g. select+multi+values
text	A one-line text field.	The text box width in number of characters.	The initial (default) content when a new topic is created with this form definition.
textarea	A multi-line text box.	Size in columns x rows, e.g. 80x6; default size is 40x5.	The initial text.

Size

The input size of the form field inputs on the edit screen. The size acts a bit different for each type - see the Type table above.

Values

For checkboxes, radio buttons and dropdown lists: predefined input to select from. More advanced: this can be a dynamically generated list of values.

• The field value will be used to initialize a field when a form is created, unless specific values are given by the topic template or query parameters. The first item in the list for a select or radio type is the default item. For label, text, and textarea fields the value may also contain commas. checkbox fields cannot be initialized through the form definition.
• Leading and trailing spaces do not matter.
• Field values can also be generated through a System.FormattedSearch, which must yield a suitable table as the result.
• Macros in the initial values of a form definition get expanded when the form definition is loaded.
  • If you want to use a | character in the initial values field, you have to precede it with a backslash, thus: \|.
  • You can use <nop> to prevent macros from being expanded.
  • The Format tokens can be used to prevent expansion of other characters.

Tooltip message

(hardly used or useful anymore) A message that will be displayed when the cursor is hovered over the field in edit view.

Attributes

Whether the field is mandatory or hidden in view mode.

H	Indicates that this field should not be shown in view mode. However, the field is available for editing and storing information.
M	Indicates that this field is mandatory. The topic cannot be saved unless a value is provided for this field. If the field is found empty during topic save, the user is presented with an error message. Mandatory fields are indicated by an asterisk next to the field name.

Multiple attributes can be entered, separated by spaces:

| TopicTitle | text | 100 | | | H M |

Enabling forms

Before connecting topics to a data definition, the definition must be enabled in the Web's WebPreferences topic.

This is done by adding the form topic name to the WEBFORMS setting. The setting accepts a comma-separated list of form topics:

   * Set WEBFORMS = BugForm, FeatureForm, Books.BookLoanForm, %USERSWEB%.UserForm

As you can see, form topics located in other webs can be added by using their web prefix.

You have to list the available form topics explicitly. You cannot use a SEARCH to define WEBFORMS.

Adding a form to a topic

With WEBFORMS enabled, a form can be added or changed on the edit screen.

Manual operation

1. Add a form: click the "Add form" button and select one of the forms in the list.
2. Switching or removing a form: click the "Change form" button and select another one, or none, from the list.

Automatically adding a form to a new topic

Using a template topic

If you don't want users to select a form themselves, this step can be automated by using a template topic that has the form connected.

For example, Question topics on foswiki.org are created using QuestionTemplate:

%META:FORM{name="QuestionForm"}%
%META:FIELD{name="TopicTitle" attributes="H" title="TopicTitle" value=""}%
%META:FIELD{name="Subject" attributes="" title="Subject" value=""}%
%META:FIELD{name="Status" attributes="M" title="Status" value="Asked"}%

In the template initial field values can be set, like the "Status" field in this example.

Using the edit template

If you will use only one form in a web, you can also modify the web's WebTopicEditTemplate topic to contain the form reference.

Using url parameters

You can also pass the formtemplate parameter to the edit (not save) URL. Initial values can then be provided in the URLs or as form values.

For example:

%SCRIPTURL{edit}%/%WEB%/KnowledgeTopicAUTOINC00001?formtemplate=MyForm;Subject=FAQWhatIsWikiWiki;Category=One;Category=Two;action=form

• XxxYyyAUTOINC00001: creates a new auto-numbered topic name with base "XxxYyy" - see automatically generate unique topic names
• formtemplate: specifies the form topic, like: formtemplate=MyForm
• form values: name=value, like: Subject=FAQWhatIsWikiWiki
• form values with multiple values like checkboxes: name=value1;name=value2, like: Category=One;Category=Two
• action=form: shows the topic data form and hides the topic text form

Using a web form to create a topic and pass data

If you want to create+save a topic instead of bringing up the edit screen, you must use a web form.

The same parameters as above can be set in HTML (hidden) form fields:

<form name="newtopic" action="%SCRIPTURLPATH{"save"}%/%SANDBOXWEB%/" method="post">
<input type="hidden" name="formtemplate" value="SimpleForm" />
<input type="hidden" name="topic" value="KnowledgeTopicAUTOINC00001" />
<input type="hidden" name="Subject" value="FAQWhatIsWikiWiki" />
<input type="hidden" name="Category" value="One" />
<input type="hidden" name="Category" value="Two" />
<input type="submit" class="foswikiSubmit" value="Create topic" />
</form>

Creates:

For an overview of web form parameters, see CGI and Command Line Scripts.

Changing a form

You can change a form definition, and Foswiki will try to make sure you don't lose any data from the topics that use that form.

• If you change the form definition, the changes will not take affect in a topic that uses that form until you edit and save it.
• If you add a new field to the form, then it will appear next time you edit a topic that uses the form.
• If you delete a field from the form, or change a field name, then the data will not be visible when you edit the topic (the changed form definition will be used). If you save the topic, the old data will be lost (though thanks to revision control, you can always see it in older versions of the topic)
• If two people edit the same topic containing a form at exactly the same time, and both change fields in the form, Foswiki will try to merge the changes so that no data is lost.

Searching in form data

The best way to search in form data is using the structured query language in the SEARCH macro.

As an example, the search used on Foswiki Support questions is:

%SEARCH{
   "QuestionForm.Status='Asked'"
   type="query"
   excludetopic="QuestionTemplate"
   web="%WEB%"
   format="   * [[$web.$topic][$formfield(TopicTitle)]] $formfield(Subject)"
   order="formfield(Extension)"
   nonoise="on"
}%

For a step by step tutorial, see the FAQ How can I create a simple data form based application?.

See SEARCH for an overview of SEARCH parameters, and Query Search for the query language specifics.

Back to top

---

Template topics

Template topics are topics that define the default text for new topics.

Overview

There are four types of template topics:

Topic Name:	What it is:
WebCreateNewTopicTemplate	Page shown when you click on a Create New Topic link. It provides a form requesting the necessary information to create a new, nonexistent topic.
TopicDoesNotExistViewTemplate	Alert page shown when you try to view a nonexistent topic and usually used as a prompt to help you create this new topic. For this reason, the form of the WebCreateNewTopicTemplate is included and therefore shown, too.
WebTopicEditTemplate	Default text used in a new topic.
<MyCustomNamed>Template	Whenever you create a topic ending in the word "Template", it is automatically added to the list of available template topics in the "Use Template" drop down field on the WebCreateNewTopic page.

When you create a new topic using the edit script, the system locates a template topic according to the following search order:

1. A topic name specified by the templatetopic CGI parameter
   • if no web is specified, the current web is searched first and then the System web
2. WebTopicEditTemplate in the current web
3. WebTopicEditTemplate in the System web

Macro expansion

When the following macros are used in a template topic, they automatically get expanded when new topic is created based on it:

Macro:	Description:
%DATE%	Signature format date. See VarDATE
%GMTIME%	Date/time. See VarGMTIME
%GMTIME{...}%	Formatted date/time. See VarGMTIME
%NOP%	A no-operation macro that gets removed. Useful to prevent a SEARCH from hitting an edit template topic; also useful to escape a variable, such as %URLPA%NOP%RAM{...}% escaping URLPARAM
%STARTSECTION{type="templateonly"}% ... %ENDSECTION{type="templateonly"}%	Text that gets removed when a new topic based on the template topic is created. See notes below.
%STARTSECTION{type="expandvariables"}% ... %ENDSECTION{type="expandvariables"}%	All Foswiki macros in this section type are expanded when a new topic based on the template topic is created. Otherwise only the macros listed here are expanded.
%SERVERTIME%	Date/time. See VarSERVERTIME
%SERVERTIME{...}%	Formatted date/time. See VarSERVERTIME
%USERNAME%	Login name of user who is instantiating the new topic, e.g. guest
%URLPARAM{"name"}%	Value of a named URL or HTTP POST parameter
%WIKINAME%	WikiName of user who is creating the new topic, e.g. WikiGuest
%WIKIUSERNAME%	User name of user who is creating the new topic, e.g. Main.WikiGuest

Macro notes:

%STARTSECTION{type="templateonly"}%
...
%ENDSECTION{type="templateonly"}%

markers are used to embed text that you do not want expanded when a new topic based on the template topic is created. For example, you might want to write in the template topic:

%STARTSECTION{type="templateonly"}%
This template topic can only be changed by:
   * Set ALLOWTOPICCHANGE = Main.AdminGroup
%ENDSECTION{type="templateonly"}%

This will restrict who can edit the template topic, but will get removed when a new topic based on that template topic is created.

%NOP% can be used to prevent expansion of macros that would otherwise be expanded during topic creation e.g. escape %SERVERTIME% with %SER%NOP%VERTIME%.

All other macros are unchanged, e.g. are carried over "as is" into the new topic, unless they are contained within a %STARTSECTION{type="expandvariables"}% section.

Specifying a form

When you create a new topic based on a template topic, you often want the new topic to have a form attached to it. You can attach a form to the template topic, in which case it will automatically be copied into the new topic.

Sometimes this isn't quite what you want, as it copies all the existing data from the template topic into the new topic. To avoid this and use the default values specified in the form definition instead, you can use the formtemplate parameter to the edit script to specify the name of a form to attach.

See CommandAndCGIScripts for information about this, and all the other parameters to edit.

Automatically generated topic names

For some applications it is useful to be able to automatically generate unique topicnames, such as BugID0001, BugID0002, etc. You can add AUTOINC<n> to the topic name in the edit and save scripts, and it will be replaced with an auto-incremented number on topic save. <n> is a number starting from 0, and may include leading zeros. Leading zeros are used to zero-pad numbers so that auto-incremented topic names can sort properly. Deleted topics are not re-used to ensure uniqueness of topic names. That is, the auto-incremented number is always higher than the existing ones, even if there are gaps in the number sequence.

Examples:

• BugAUTOINC0 - creates topic names Bug0, Bug1, Bug2, ... (does not sort properly)
• ItemAUTOINC0000 - creates topic names Item0000, Item0001, Item0002, ... (sorts properly up to 9999)
• DocIDAUTOINC10001 - start with DocID10001, DocID10002, ... (sorts properly up to 99999; auto-links)

Example link to create a new topic:

[[%SCRIPTURLPATH{edit}%/%WEB%/BugIDAUTOINC00001?templatetopic=BugTemplate;topicparent=%TOPIC%;t=%SERVERTIME{"$day$hour$min$sec"}%][Create new item]]

Template topics in action

Here is an example for creating new topics (in the Sandbox web) based on a specific template topic and form:

New example 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}%/%SANDBOXWEB%/" method="post">
New example topic: <input type="text" name="topic" class="foswikiInputField" value="ExampleTopicAUTOINC0001" size="30" />&nbsp;<input type="submit" class="foswikiSubmit" value="Create" />
<input type="hidden" name="templatetopic" value="%SYSTEMWEB%.ExampleTopicTemplate" />
<input type="hidden" name="topicparent" value="%TOPIC%" />
<input type="hidden" name="onlywikiname" value="on" />
<input type="hidden" name="onlynewtopic" value="on" />
</form>

Note: You can create a topic in one step, without going through the edit screen. To do that, specify the save script instead of the edit script in the form action. When you specify the save script you must use the "post" method. Example:

<form name="new" action="%SCRIPTURLPATH{save}%/Sandbox/" method="post">
    ...
</form>

See CommandAndCGIScripts#edit for details of the parameters that the edit script understands.

You can use the %WIKIUSERNAME% and %DATE% macros in your template topics to include the signature of the person creating a new topic. The macros are expanded into fixed text when a new topic is created. The standard signature is:
-- %WIKIUSERNAME% - %DATE%

Using absolute vs relative URLs in templates

When you use Macros such as %PUBURL% and %PUBURLPATH% in template topics you should be aware that using %PUBURL% instead of %PUBURLPATH% puts absolute URLs in the produced HTML. This means that when a user saves a page in HTML and emails the file to someone outside a company firewall, the receiver has a severe problem viewing it. It is therefore recommended always to use the %PUBURLPATH% to refer to images, CSS, Javascript files etc so links become relative. This way browsers just give up right away and show a usable html file.

Back to top

---

Skin Templates

The framework used to render output.

Overview

Skin Templates are plain text with embedded template directives, macros and tokens that are expanded by Foswiki to build an output, usually HTML.

Skin templates are used when composing the output from all actions, such as view, edit, and preview. By sharing common template definitions between all these actions, it makes it easy to change the look and feel of all pages by editing just a few templates.

Skin templates are either stored as text files with the extension .tmpl in the templates/ directory, or in Foswiki topics.

Template directives are expanded when the template is loaded, and are used to define the general structure of the output. Macros and Template Tokens are expanded when the page is rendered, and fill in page-specific information.

Note that Macros and Tokens are written using the same syntax. See Macros for more information on macros.

Tokens look exactly like Macros, but they are specific for the script expanding the template, and cannot be used elsewhere in Foswiki. See SkinTemplateTokens for more information on tokens.

How Template Directives Work

Template directives look a lot like standard macros.

• %TMPL:INCLUDE{"file"}% includes a template file. The file is found as described below.
• %TMPL:DEF{"name"}% defines a block. All text between this and the next %TMPL:END% directive is removed and saved for later use with %TMPL:P%.
• %TMPL:END% ends a block definition.
• %TMPL:PREV%: returns the previous definition of the block being defined.
• %TMPL:P{"name"}% includes a previously defined block.
• %{...}% is a comment. Whitespace either side of the comment (newlines, spaces, tabs etc) is treated as part of the comment, and removed when the comment is removed.

You can use a block before or after declaring it. If you define the same block twice, only the second definition is used.

Most template directives work only for templates: they do not get processed in normal topic text. The one exception is %TMPL:P.

Parameters to blocks

%TMPL:DEF% and %TMPL:P% support simple parameters.

Parameters are only available in the immediate definition being included; they are not passed on to any other TMPL:P inside the TMPL:DEF being expanded unless they are passed on explicitly in a new parameter.

Block parameters

For example, we can define a parameter P inside a block:

%TMPL:DEF{"x"}% x%P%z %TMPL:END%

then pass a value to that parameter:

%TMPL:P{"x" P="y"}%

This will expand to xyz.

Naming

Any alphanumeric characters can be used in parameter names. TMPL:P parameters override any other possible definition of the name, so you should not use parameter names that might clash with Macros.

Conditional expansion

Three parameter names, context, then and else are reserved. They are used to support a limited form of "if" condition that you can use to select which of two TMPL:DEF to expand, based on a context identifier:

%TMPL:DEF{"link_inactive"}%<input type="button" disabled value="Link>%TMPL:END%
%TMPL:DEF{"link_active"}%<input type="button" onclick="link()" value="Link" />%TMPL:END%
%TMPL:P{context="inactive" then="link_inactive" else="link_active"}% for %CONTEXT%

When the inactive context is set, then this will expand the link_inactive TMPL:DEF; otherwise it will expand link_active.

This style of conditional expansion is used in preference to the %IF{} macro where possible because it is much more efficient.

See If Statements: Context identifiers for details of supported context identifiers.

TMPL:INCLUDE recursion

You can use recursion with %TMPL:INCLUDE% for piecewise customisation, or mixing in new features.

If there is a recursion in the %TMPL:INCLUDE% chain (eg. view.tmpl contains %TMPL:INCLUDE{"view"}%), the templating system will detect that you are trying to include the same template again, and will instead include the next version of the template of that name that it finds in the template path.

For example, say you only want to override the breadcrumbs for the view script. You could create a tempate called view.crumbless.tmpl:

%TMPL:INCLUDE{"view"}%
%TMPL:DEF{"breadcrumb"}% We don't want any crumbs %TMPL:END%

and then * Set SKIN=crumbless,pattern

Remember: the template path contains the most specific template first.

Comments

Comments %{...}% are removed from the templates as soon as the file is read, before any other template macros are evaluated. Whitespace either side of the comment (newlines, spaces, tabs etc) is also removed.

Finding Skin Templates

Most skin templates are stored in .tmpl files in the templates directory. For example, templates/view.tmpl is the default skin template file for the bin/view script. You can also save skin templates in user topics.

The {TemplatePath} configuration setting (in the Miscellaneous section of the configure page) defines which directories, files and Foswiki topics will be recognised as containing templates.

Skin templates that are loaded using %TMPL:INCLUDE with an explicit .tmpl extension are looked for only in the templates/ directory. For instance %TMPL:INCLUDE{"example.tmpl"}% will only return templates/example.tmpl, regardless of {TemplatePath} and SKIN settings.

All other templates are searched for using the {TemplatePath}. This is a list of generic name patterns, each of which contains the placeholders $name (the template name), $web (the web), and $skin (the skin), each standing in for part of the name. Each entry in this list is expanded in turn until the template is found.

The rules defined by the out-of-the-box setting of {TemplatePath} are:

1. templates/$web/$name.$skin.tmpl
2. templates/$name.$skin.tmpl
3. $web.$skinSkin$nameTemplate
4. System.$skinSkin$nameTemplate
5. templates/$web/$name.tmpl
6. templates/$name.tmpl
7. $web.$nameTemplate
8. System.$nameTemplate

For example, let's say we are viewing a topic in web Sandbox and are searching for the template called function. The skin path is set to custom,pattern. The following locations will be considered in turn, until a template is found:

1. templates/Sandbox/function.custom.tmpl (rule 1)
2. templates/Sandbox/function.pattern.tmpl (rule 1)
3. templates/function.custom.tmpl (rule 2)
4. templates/function.pattern.tmpl (rule 2)
5. Sandbox.CustomSkinFunctionTemplate (rule 3)
6. Sandbox.PatternSkinFunctionTemplate (rule 3)
7. System.CustomSkinFunctionTemplate (rule 4)
8. System.PatternSkinFunctionTemplate (rule 4)
9. templates/Sandbox/function.tmpl (rule 5)
10. templates/function.tmpl (rule 6)
11. Sandbox.FunctionTemplate (rule 7)
12. System.FunctionTemplate (rule 8)

This usage is supported for compatibility only and is deprecated. Store web-specific templates in topics instead.

When a skin name or template name is used to build a topic name, the first character is automatically capitalised.

The skin path is set as described in Skins.

Template file names are usually derived from the name of the currently executing script; however it is also possible to override these settings in the view and edit scripts, for example when a topic-specific template is required. Two preference settings can be used to override the skin templates used:

• VIEW_TEMPLATE sets the template to be used for viewing a topic.
• EDIT_TEMPLATE sets the template for editing a topic.

If these preferences are set

• locally (using Local instead of Set) in a topic, or
• in WebPreferences, or
• in Main.SitePreferences, or
• in System.DefaultPreferences (using Set),

then the indicated templates will be chosen for view and edit respectively. The template search order remains as specified above.

Security and usability

Setting the {TemplatePath} is a compromise between the often opposing goals of security and usability. From a security perspective, allowing templates to be loaded from topics might open a door to people who want to inject their own evil HTML in those topics. From a usability perspective, it's very desireable to be able to override templates from topics, as it vastly increases the range of wiki applications.

The default {TemplatePath} comes down on the side of usability, by allowing templates from topics to be found before templates from the (more secure) templates directory. If you are particularly security concious, you may want to reverse this order, so that templates in templates/ are always found before those in topics. You can do this by simply moving rules 3 and 7 to the end of the list.

Note that topics containing templates are checked for VIEW access using the normal Foswiki access controls. Any access control failure is silently ignored, and the template path expansion continues.

Developing new templates

Debugging

When writing new templates, it can sometimes it can be hard to work out where different parts of the generated output come from. To help you debug your new templates, the Foswiki::Templates module has a "trace" mode. In this mode, the output is annotated with HTML comments that are wrapped around the output generated by each template, as it is expanded. For example, when trace mode is off,

%TMPL:DEF{"x:y"}% de %TMPL:END%
blah %TMPL:P{"x:y"}% blah

will expand to:

blah  de  blah

With tracing enabled, it will expand to:

blah <!--x:y--> de <!--/x:y--> blah

To enable the trace mode, edit lib/Foswiki/Templates.pm in your installation and change use constant TRACE => 0 to use constant TRACE => 1.

Note that the trace annotations may make your output look strange. However you can usually "view source" in the browser to see what was generated (or you may be able to run the script from the command-line e.g. cd bin; perl -T -I . view topic=MyWeb.MyTopic skin=mynewskin).

Don't forget to switch the trace mode off again when you are finished!

Overview of the default templates

Finally, here's a very high-level overview of the default templates. These templates are rarely used on their own, but are used as the base on which skins, such as PatternSkin, are built.

foswiki.tmpl is the default master template. The main purpose of this template is to instantiate the following blocks:

• htmldoctype - start of all HTML pages
• bodystart - start of the body tag
• main - page content
• bodyend - end of the page

Default definitions are provided for each of these blocks. foswiki.tmpl is never used on its own, but is frequently included by other templates.

Next, there are a number of action-specific templates, such as view.tmpl, edit.tmpl, login.tmpl. These are the templates loaded by the actions of the same name. Their purpose is to include foswiki.tmpl, and provide new, page-specific, definitions of the blocks described above.

Several of the action-specific templates have skinned versions, such as view.print.tmpl and view.text.tmpl. These skinned versions are used to view the page in a specific way - for printing, or as plain text, for example.

messages.tmpl is an important template; it provides the basic definitions of all error and warning messages that Foswiki issues. These are defined using the %MAKETEXT macro to simplify translation into different languages.

attachtables.tmpl is another template worthy of separate mention. This template defines the different parts of the page that are involved in displaying tables of attachments. The blocks defined in this template are instantiated directly from code, rather than via %TMPL:P.

The remainder of the templates are used for varying purposes; their names, or introductory comments, should clarify.

A skin can provide a new version of any or all of these templates, depending on the depth of customisation. See the template files named *.pattern.* to see what PatternSkin defines.

---

Related Topics: Skins Macros JavascriptFiles

Back to top

---

Foswiki Skins

Skins overlay regular templates to give different looks and feels to Foswiki screens.

Overview

Foswiki uses skin templates as the basis of all the screens it uses to interact with users. Each screen has an associated template file that contains the basic layout of the screen. This is then filled in by the code to generate what you see in the browser.

Foswiki ships with a default set of template files that give a very basic, CSS-themable, look-and-feel. Foswiki also includes support for skins that can be selected to give different, more sophisticated, look and feel. A default Foswiki installation will usually start up with the PatternSkin already selected. Skins may also be defined by third parties and loaded into a Foswiki installation to give more options. To see how Foswiki looks when no skin is selected, view this topic with a non-existant skin.

Topic text is not affected by the choice of skin, though a skin can be defined to use a CSS (Cascading Style Sheet), which can sometimes give a radically different appearance to the text.

Changing the default skin

BACCHUS Wiki by default ships with the PatternSkin activated. You can set the skin for the whole site (via Main.SitePreferences), a single web (via its WebPreferences topic) or topic, for each user individually, or even per request - see Activating Skins below for more details.

Defining Skins

You may want to define your own skin, for example to comply with corporate web guidelines, or because you have a aesthetic vision that you want to share. There are a couple of places you can start doing this.

Skin templates are located by looking at a list of possible locations, including topics and files in the templates directory. The lookup process is configurable, and is described in SkinTemplates#FindingTemplates. You can choose to define your skin entirely in topics, entirely in files in templates, or in a mixture of both.

The easiest way to start creating a new skin is to layer it over an existing skin, only overriding those parts of the existing skin that you want to customise. Foswiki can be configured to fall back to another skin if a template is not defined in your skin. A custom skin can be as small as one file!

Most skins, even those that look radically different to the default, use this layering approach, by basing themselves on the default skin templates (those template files with no skin name e.g view.tmpl, edit.tmpl etc). These templates provide a minimal interface that is easy to understand and build on. Another advantage of this approach is that if new features are exposed in the default templates, your skin has a chance to pick them up "for free".

If you use PatternSkin as your starting point, and you want to modify the layout, colors or even the templates to suit your own needs, have a look first at the topics PatternSkinCustomization and PatternSkinCssCookbook. These topics also provide practical instructions how to create custom skin template files.

Note: Don't call your skin text or rss as these two skin names have reserved meanings, see below at hard-coded meanings.

The following template names are used for Foswiki screens, and are referenced in the Foswiki core code. If a skin doesn't define its own version of a template file, then Foswiki will fall back to the next skin in the skin path, or finally, to the default version of the template file.

(Certain template files are expected to provide certain TMPL:DEFs - these are listed in sub-bullets)

• addform - used to select a new form for a topic
• attachagain - used when refreshing an existing attachment
• attachnew - used when attaching a new file to a topic
• attachtables - defines the format of attachments at the bottom of the standard topic view
  • ATTACH:files:footer, ATTACH:files:header, ATTACH:files:row, ATTACH:versions:footer, ATTACH:versions:header, ATTACH:versions:row
• changeform - used to change the form in a topic
• changes - used by the changes script
• edit - used for the edit screen
• form
• formtables - used to defined the format of forms
  • FORM:display:footer, FORM:display:header, FORM:display:row
• login - used for loggin in when using the TemplateLoginManager
  • LOG_IN, LOG_IN_BANNER, LOG_OUT, LOGGED_IN_BANNER, NEW_USER_NOTE, UNRECOGNISED_USER
• moveattachment - used when moving an attachment
• oopsaccessdenied - used to format Access Denied messages
  • no_such_topic, no_such_web, only_group, topic_access
• oopsattention - used to format Attention messages
  • already_exists, bad_email, bad_ver_code, bad_wikiname, base_web_missing, confirm, created_web, delete_err, invalid_web_color, invalid_web_name, in_a_group, mandatory_field, merge_notice, missing_action, missing_fields, move_err, missing_action, no_form_def, no_users_to_reset, not_a_user, oversized_upload, password_changed, password_mismatch, problem_adding, remove_user_done, rename_err, rename_not_wikiword, rename_topic_exists, rename_web_err, rename_web_exists, rename_web_prerequisites, reset_bad, reset_ok, save_error, send_mail_error, thanks, topic_exists, unrecognized_action, upload_name_changed, web_creation_error, web_exists, web_missing, wrong_password, zero_size_upload
• oopsgeneric - a basic dialog for user information; provides "ok" button only
• oopslanguagechanged - used to confirm a new language when internationalisation is enabled
• oopsleaseconflict - used to format lease Conflict messages
  • lease_active, lease_old
• preview - used for previewing edited topics before saving
• rdiff - used for viewing topic differences
• registernotify - used by the user registration system
• registernotifyadmin - used by the user registration system
• rename - used when renaming a topic
• renameconfirm - used when renaming a topic
• renamedelete - used when renaming a topic
• renameweb - used when renaming a web
• renamewebconfirm - used when renaming a web
• renamewebdelete - used when renaming a web
• searchbookview - used to format search results in book view
• searchformat - used to format search results
• search - used to format inline search results if no formatting is specified
• settings
• view - used by the view CGI script
• viewprint - used to create the printable view

foswiki.tmpl is a master template conventionally used by other templates, but not used directly by code.

Note: Make sure templates do not end with a newline. Any newline will expand to an empty <p /> in the generated html. It will produce invalid html, and may break the page layout.

Partial customisation, or adding in new features to an existing skin

You can use recursion in the TMPL:INCLUDE chain. For example, if view.tmpl contains %TMPL:INCLUDE{"foswiki"}%, the templating system will include the next SKIN in the skin path. To create a customisation of the Pattern skin, where you only want to remove the edit & WYSIWYG buttons from the view screen, you create only a view.yourlocal.tmpl:

%TMPL:INCLUDE{"view"}%
%TMPL:DEF{"edit_topic_link"}%%TMPL:END%
%TMPL:DEF{"edit_wysiwyg_link"}%%TMPL:END%

and then set SKIN=yourlocal,pattern in Main.SitePreferences, a particular web's WebPreferences, or in an individual topic, depending on the desired scope of the skin.

Settings in Skins

You can use template directives, ordinary macros, and other predefined settings in your skins. Some commonly used macros in skins:

Macro:	Expanded to:
%WEBLOGONAME%	Filename of web logo
%WEBLOGOIMG%	Image URL of web logo
%WEBLOGOURL%	Link of web logo
%WEBLOGOALT%	Alt text of web logo
%WIKILOGOURL%	Link of page logo
%WIKILOGOIMG%	Image URL of page logo
%WIKILOGOALT%	Alt text of page logo
%WEBBGCOLOR%	Web-specific background color, defined in the WebPreferences
%WIKITOOLNAME%	The name of your Foswiki site
%SCRIPTURL%	The script URL of Foswiki
%SCRIPTURLPATH%	The script URL path
%SCRIPTSUFFIX%	The script suffix, ex: .pl, .cgi
%WEB%	The name of the current web.
%TOPIC%	The name of the current topic.
%WEBTOPICLIST%	Common links of current web, defined in the WebPreferences. It includes a Go box
%TEXT%	The topic text, e.g. the content that can be edited
%QUERY{"form.name"}%	DataForm, if any
%QUERY{"attachments.name"}%	FileAttachment list
%QUERY{"parent.name"}%	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 - Main.WikiGuest
%WEBCOPYRIGHT%	Copyright notice, defined in the WebPreferences
%BROADCASTMESSAGE%	Broadcast message at the beginning of your view template, can be used to alert users of scheduled downtimes; can be set in Main.SitePreferences

Using Cascading Style Sheets

CSS files are gererally attachments to the skin topic that are included in the skin templates - in the case of PatternSkin in the template css.pattern.tmpl.

• General documentation of CSS classes: AppendixCascadingStyleSheets
• To see how CSS is used in the default Foswiki skin, see: PatternSkin
• If you write a complete new skin, this is the syntax to use in a template file:

%ADDTOZONE{
    "head"
    id="MySkin/mystyle"
    text="
        <style type='text/css' media='all'>
            @import url('%PUBURLPATH%/%SYSTEMWEB%/MySkin/mystyle.css');
        </style>"
}%

See ADDTOZONE

Skin parts

The "Go" Box and Navigation Box

The default skins include a "Go" box, also called "Jump" box, to jump to a topic.

The box also understands URLs, e.g. you can type http://www.google.com/ to jump to an external web site. The feature is handy if you build a skin that has a select box of frequently used links, like Intranet home, employee database, sales database and such. A little JavaScript gets into action on the onchange method of the select tag to fill the selected URL into the "Go" box field, then submits the form.

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

Bare bones header, for demo only
Navigate:	chooseIntranet homeEmployee indexMain webSystem webGoogleYahoo!
Jump:

Note: Redirect to a URL only works if it is enabled in configure (Miscellaneous, {AllowRedirectUrl}).

FLASHNOTE Notifications

PatternSkin has a notification message display using the variable FLASHNOTE. For example:

• Set FLASHNOTE = Skins documentation

See the alert at the top of this topic.

While this feature is not yet used by the system, it might be a good idea to already prepare your skin.

Attachment Tables

Controlling the look and feel of attachment tables is a little bit more complex than for the rest of a skin. By default, the attachment table is a standard Foswiki table, and the look is controlled in the same way as other tables. In a very few cases you may want to change the content of the table as well.

The format of standard attachment tables is defined through the use of special template directives which by default, are defined in the attachtables.tmpl template using the %TMPL:DEF directive syntax described in SkinTemplates. These macros are:

Macro	Description
ATTACH:files:header	Standard title bar
ATTACH:files:row	Standard row
ATTACH:files:footer	Footer for all screens
ATTACH:files:header:A	Title bar for upload screens, with attributes column
ATTACH:files:row:A	Row for upload screen
ATTACH:files:footer:A	Footer for all screens

The format of tables of file versions in the Upload screen can also be changed, using the macros:

Macro	Description
ATTACH:versions:header	Header for versions table on upload screen
ATTACH:versions:row	Row format for versions table on upload screen
ATTACH:versions:footer	Footer for versions table on upload screen

The ATTACH:row macros are expanded for each file in the attachment table, using the following special tags:

Tag	Description
%A_URL%	viewfile URL that will recover the file
%A_REV%	Revision of this file
%A_ICON%	A file icon suitable for representing the attachment content
%A_FILE%	The name of the file. To get the 'pub' url of the file, use %PUBURL%/%WEB%/%TOPIC%/%A_FILE%
%A_SIZE%	The size of the file
%A_DATE%	The date the file was uploaded
%A_USER%	The user who uploaded it
%A_COMMENT%	The comment they put in when uploading it
%A_ATTRS%	The attributes of the file as seen on the upload screen e.g "h" for a hidden file

Packaging and Publishing Skins

See Foswiki:Development/ExtensionDeveloperGuide

For your own skin you are encouraged to show a small 88x31 pixel logo at the bottom of your skin:

<a href="http://foswiki.org/">
     <img src="%PUBURL%/%SYSTEMWEB%/ProjectLogos/foswiki-badge.gif"\
          alt="Powered by Foswiki" width="88" height="31"\
          title="Powered by Foswiki" border="0" />
</a>

Generating:

The standard BACCHUS Wiki skins show the logo in the %WEBCOPYRIGHT%.

Browsing Installed Skins

You can try out all installed skins in the SkinBrowser.

Activating Skins

Foswiki uses a skin search path, which lets you combine skins additively. The skin path is defined using a combination of preference settings and URL parameters.

Foswiki works by asking for a template for a particular function - for example, 'view'. The detail of how templates are searched for is described in SkinTemplates, but in summary, the templates directory is searched for a file called view.skin.tmpl, where skin is the name of the skin e.g. pattern. If no template is found, then the fallback is to use view.tmpl. Each skin on the path is searched for in turn. For example, if you have set the skin path to local,pattern then view.local.tmpl will be searched for first, then view.pattern.tmpl and finally view.tmpl.

The basic skin is defined by the SKIN preference:

   * Set SKIN = catskin, bearskin

You can override this using the URL parameter skin, such as ?skin=catskin,bearskin:

• https://wiki.bacchus-env.eu/bin/view/System/Skins?skin=catskin,bearskin

Setting the ?skin parameter in the URL replaces the existing skin path setting for the current request only.

You can also extend the existing skin path using covers:

   * Set COVER = ruskin

This pushes a different skin to the front of the skin search path, so the final skin path will be ruskin, catskin, bearskin.

There is also a cover URL parameter that can be used to push yet more skin names in front of the COVER preference.

So the final value of the skin path is given by:

1. value of the cover url parameter
2. value of the COVER preference
3. value of the skin url parameter, if it is non-null
4. value of the SKIN preference, if the skin url parameter is not given

For example, if we have

   * Set SKIN = muscle,bone
   * Set COVER = epidermis

and a URL with the parameter ?cover=hair,dermis then the final skin path will be hair, dermis, epidermis, muscle, bone.

Or we might specify a skin url parameter, ?skin=flesh. With the same preferences this will set the skin path epidermis, flesh.

Note that you cannot use the cover url parameter to remove a skin applied by the COVER preference. Once a COVER preference is defined, it is always applied.

Hard-Coded Skins

The text skin is reserved for Foswiki internal use.

Skin names starting with rss also have a special meaning; if one or more of the skins in the skin path starts with 'rss' then 8-bit characters will be encoded as XML entities in the output, and the content-type header will be forced to text/xml.

---

Related Topics: SkinTemplates, SkinBrowser, AdminDocumentationCategory, DeveloperDocumentationCategory

Back to top

---

Meta data

Additional data, Foswiki-generated or from forms, may be embedded in the topic text using META: macros

Overview

The default store engines store topics in plain-text files on disk, in a simple and obvious directory structure. The big advantage of this approach is that it makes it very easy to manipulate topics from outside Foswiki, and it is also very robust; there are no complex binary indexes to maintain, and moving a topic from one installation to another is as simple as copying a couple of text files.

To keep everything together in one place, meta-data (Foswiki-generated or from forms) is embedded directly in topics, using special macros. These macros are easy to spot, as they all start with the reserved META: prefix.

META: data includes information such as file attachments, topic movement history, and form field values. For efficiency reasons, the topic history is not stored in this meta-data, but is expected to be implemented elsewhere by the store engine.

Meta data syntax

• Format is the same as for any other macros except that each meta-data macro must be on a line on its own.
  • %META:<type>{key1="value1" key2="value2" ...}%
• The characters %"\r\n{} are encoded in argument values, using the standard URL encoding.
• Meta-data is divided into core meta-data, described below, and extension meta-data, which shares the same syntax but is used by extensions.
• Dates are stored as "epoch times" i.e. the integer number of seconds since 1st January 1970.

Example of core meta-data

%META:TOPICINFO{version="6" date="976762663" author="LastEditor" format="1.0"}%
   text of the topic
%META:TOPICMOVED{from="Real.SecretAgents" to="Hollywood.SecretAgents"
   by="CoverUp" date="976762680"}%
%META:TOPICPARENT{name="MilitaryIntelligence5"}%
%META:FILEATTACHMENT{name="CV.txt" version="3" ... }%
%META:FILEATTACHMENT{name="Photo.gif" version="1" ... }%
%META:FORM{name="SecretAgentForm"}%
%META:FIELD{name="ChosenWeapon" value="Beretta"}%
%META:FIELD{name="Paramour" value="PussyGalore"}%
%META:PREFERENCE{name="ALLOWTOPICCHANGE" value="JamesBond"}%
%META:PREFERENCE{name="DENYTOPICVIEW" value="ErnstBlofeld"}%

Core meta-data

The following meta-data macros are supported by the Foswiki core. Other macros may be used by extensions; see the extension documentation for more details. The core will read and write these extension macros, but will otherwise ignore them.

Some fields are required by macros, while others are optional. Required fields are marked with a %REG% symbol. The %REG% character is not part of the attribute name.

META:TOPICINFO

This macro caches some of the information that would normally be derived from the underlying store engine. It does this for efficiency reasons.

Key	Comment
author%REG%	Canonical user identifier of last user to change the topic. The exact format of this depends on the user mapping manager.
version	Topic version; a plain integer.
date	epoch time
format	Format of this topic, will be used for automatic format conversion
reprev	Set when a revision is overwritten by the same author within the {ReplaceIfEditedAgainWithin} window (set in configure ). If reprev is the same as version, it prevents Foswiki from attempting to do a 3-way merge when merging overlapping edits by two different users.

Note that the version and date fields are advisory only and cannot be trusted. This is because processes outside of Foswiki's control may write topic files without maintaining these fields.

META:TOPICMOVED

This only exists if the topic has been moved. If a topic is moved more than once, only the most recent META:TOPICMOVED meta datum exists in the topic. Older ones can to be found in the topic history.

%META:TOPICMOVED{from="Real.SecretAgents" to="Hollywood.SecretAgents" by="CoverUp" date="976762680"}%

Key	Comment
from%REG%	Full name, i.e., web.topic
to%REG%	Full name, i.e., web.topic
by%REG%	Canonical user identifier of who moved the topic. The exact format of this depends on the user mapping manager.
date%REG%	epoch time

Notes:

• the moved version numbers can be deduced from the topic history.

META:TOPICPARENT

The topic from which this topic was created, typically when clicking on a ? question mark link, or by filling out a form. The topic parent may also be manipulated in the user interface.

Key	Comment
name%REG%	Normally just TopicName, but it can be a full Web.TopicName format if the parent is in a different Web.

META:FILEATTACHMENT

Reference to a file attached to this topic.

Key	Comment
name%REG%	Name of file, no path. Must be unique within topic
version	An integer
path	Full path file was loaded from
size	In bytes
date	epoch time when the file was attached
user	Canonical user identifier of user who uploaded the attachment. The exact format of this depends on the user mapping manager.
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.filename
movedby	Canonical user identifier of user who moved the attachment. The exact format of this depends on the user mapping manager.
movedto	full topic name - web.topic.filename
movedwhen	epoch time

META:FORM

Key	Comment
name%REG%	The name of the topic containing the form definition. 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.

Key	Name
name%REG%	Ties to entry in the form definition. This is the title with all characters except alphanumerics and . removed
value%REG%	Value user has supplied via form
title	Full text from the form definition

META:PREFERENCE

Out-of-band preference.

Key	Name
name%REG%	Preference name
value%REG%	Preference value
type	Set or Local (Set is the default)

Recommended sequence

There is no absolute need for meta-data macros to be listed in a specific order within a topic, but it makes sense to do so, because form fields are displayed in the order they are defined when the topic is viewed.

The recommended sequence is:

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

Viewing meta-data embedded in page source

You can append the raw=debug parameter to the URL to view the topic text with embedded meta-data, e.g: debug view for this topic. raw=all lets you view the topic source as plain text, e.g: plain text view for this topic.

Including meta data in viewed topics

%META

Meta-data belonging to the viewed topic can be included in the view using the %META macro. See VarMETA for details.

%FORMFIELD

The %FORMFIELD macro lets you inspect the values of form field meta-data in other topics. See VarFORMFIELD for details.

%SEARCH

%SEARCH can also be used to extract meta data. See VarSEARCH and the examples in FormattedSearch and SearchPatternCookbook.

Extending meta-data in Extensions

Extensions can extend meta-data with information of their own. See Foswiki::Func for more information.

---

Related Topics: DeveloperDocumentationCategory

Back to top

---

Add-Ons

Add functionality with extensions not based on the Foswiki scripts.

Overview

An add-on runs separately from the Foswiki scripts, e.g. for data import, export to static HTML, etc. Add-Ons normally do not call any Foswiki code directly, though may invoke Foswiki scripts. There are different types of add-ons, they may be stand alone scripts, browser plugins, office tool extensions, or even a set of topics that form a wiki application.

See other types of extensions: Contribs, Plugins, Skins

Add-Ons Installed on this site

• CompareRevisionsAddOn: Compares two revisions of a document. In contrast to normal rdiff, the comparison is done with the rendered HTML output. - version v1.1.11
  Author: Foswiki:Main.KennethLavrsen - last modified: r1 - 28 May 2011 - 13:02 - Main.ProjectContributor

Installing Add-Ons

• Download an add-on from Foswiki:Extensions.
• Follow the installation instructions in the add-on topic.

Creating new Add-Ons

• Visit Foswiki:Development/ExtensionDeveloperGuide and follow the instructions.

Back to top

---

Foswiki Contribs

Extensions to Foswiki that are not plugins

Overview

The term "Contrib" is used to refer to any package that is not just a simple plugin.

Foswiki contribs may

• extend the functionality of Foswiki, in a lower-level way than plugins,
• or provide alternative implementations for sections of the Foswiki core e.g. user management, or when an extension just can't be implemented as a plugin because it requires very close access to Foswiki internals,
• or they might provide other files that Foswiki uses, for example language files,
• or they might be packages of topics that implement a "Wiki Application", using the wiki macro language, TML.

Relevant links on Foswiki.org:

• Foswiki:Extensions - list of all contributed contrib packages
• Foswiki:Development - where developers get started

See other types of extensions: ContributedAddOns, Plugins, Skins

Foswiki Contribs Installed on this site

• FamFamFamContrib: 4 great free icon sets, by Mark James http://www.famfamfam.com - version v1.4.5
  Author: - last modified: r1 - 04 Sep 2011 - 18:45 - Main.ProjectContributor
• JSCalendarContrib: Mishoo JSCalendar date and time picker, packaged for use by plugins, skins and add-ons - version v1.5.4
  Author: Foswiki:Main/CrawfordCurrie http://c-dot.co.uk - last modified: r1 - 18 Nov 2013 - 22:07 - Main.UnknownUser
• MailerContrib: Supports email notification of changes - version v2.5.5
  Author: Crawford Currie - last modified: r1 - 18 Nov 2013 - 22:09 - Main.UnknownUser
• PatchFoswikiContrib: File patch tool for Foswiki - version 1.5
  Author: GeorgeClark - last modified: r1 - 18 Nov 2013 - 22:06 - Main.UnknownUser
• TipsContrib: Displays rotating list of "Tip-of-the-day" - version v1.2.0
  Author: - last modified: r1 - 11 Apr 2011 - 00:00 - Main.ProjectContributor
• TopicUserMappingContrib: User management using data stored in topics - version v4.3.7
  Author: - last modified: r1 - 18 Nov 2013 - 22:10 - Main.UnknownUser

Installing Contribs

• Use configure to browse to the list of extensions available from Foswiki.org
• Or, download an extension package from some other source, and unzip it
• Follow the installation instructions in the contrib topic.

Back to top

---

Foswiki Plugins

Extensions that use a simple API to talk to Foswiki

Overview

You can add plugins to extend Foswiki functionality without altering the core code. A plug-in approach lets you:

• add virtually unlimited features while keeping the main Foswiki code compact and efficient;
• heavily customize an installation and still do clean updates to new versions of Foswiki;
• rapidly develop new Foswiki functions in Perl using the plugin API.

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

Foswiki plugins are developed and contributed by interested members of the community. Plugins are provided on an 'as is' basis; they are not a part of Foswiki, but are independently developed and maintained.

Most TWiki^® plugins can also be used with Foswiki if the TWikiCompatibilityPlugin is installed.

See other types of extensions: Contribs, Skins

See InstalledPlugins for a list of plugins installed on this site.

Installing Plugins

Each plugin comes with its own documentation page, which includes step-by-step installation instructions, a detailed description of any special requirements, and version details. Many also have a worked example for testing.

The easiest way to install plugins is to use the configure interface. However you can also install plugins from the command-line. Every plugin comes with installation instructions.

Each plugin has a standard release topic, located in the Foswiki:Extensions web at Foswiki.org. There's usually a number of other related topics, such as a developers page, and an appraisal page. After installation, a copy of this page will be installed to your System web.

If you install a plugin and it doesn't seem to work, then you can get information on all the installed plugins that may help to resolve the issue.

Failing that, you may want to check your webserver error log and the various Foswiki log files, and any notes in the support topic for the plugin (linked from the plugin front page).

Some Notes on Plugin Performance

The performance of the system depends to some extent on the number of plugins installed and on the plugin implementation. Some plugins impose no measurable performance decrease, some do. For example, a Plugin might use many Perl libraries that need to be initialized with each page view (unless you run mod_perl). You can only really tell the performance impact by installing the plugin and by measuring the performance with and without the new plugin, on real data.

If you need to install an "expensive" plugin, but you only need its functionality only in a subset of your data, you can disable it elsewhere by defining the %DISABLEDPLUGINS% setting.

Define DISABLEDPLUGINS to be a comma-separated list of names of plugins to disable. Define it in Main.SitePreferences to disable those plugins everywhere, in the WebPreferences topic to disable them in an individual web, or in a topic to disable them in that topic. For example,

   * Set DISABLEDPLUGINS = SpreadSheetPlugin, EditTablePlugin

Managing Installed Plugins

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:

Listing Active Plugins

Plugin status macros let you list all active plugins wherever needed.

This site is running Foswiki version v1.1.9, plugin API version 2.2

• %ACTIVATEDPLUGINS% - shows the activated plugins
• %PLUGINVERSION% - shows the plugins API version
• %FAILEDPLUGINS% - shows what plugins failed, and why

Enabling Plugins

Plugins can be enabled and disabled with the configure script. An installed plugin needs to be enabled before it can be used. Plugins can also be selectively disabled again using the DISABLED_PLUGINS preference, as described above.

Plugin Evaluation Order

By default, plugins are executed in alphabetical order of plugin name. It is possible to change the order, for example to evaluate database macros before the spreadsheet CALCs, using the {PluginsOrder} in the Extensions section of configure.

Plugin-Specific Settings

Some plugins are configured with plugin preference settings, some with configure settings, and some with both. The plugin topic will contain details.

configure settings are accessible though the configure interface.

Note that some older plugins use preference settings defined in the plugin topic. For example, the (fictional) BathPlugin topic might contain:

• Set ELECTRIC = on

This setting defines the default value for the preference BATHPLUGIN_ELECTRIC. You should never edit the BathPlugin topic to change this setting; instead, override the setting by defining BATHPLUGIN_ELECTRIC as described in preference settings.

Developing your own plugins

Developing plugins provides a simple introduction to hooking into Foswiki code from your own Perl modules. Foswiki:Development.GettingStarted is the starting point for more comprehensive documentation.

Back to top

---

Developing Plugins

The usual way Foswiki is extended is by writing a Plugin. Plugins extend Foswiki by providing functions that 'listen' to events in the Foswiki core, and handling these events. These functions are called "Plugin Handlers" and they are described in depth in EmptyPlugin ( lib/Foswiki/Plugins/EmptyPlugin.pm ).

The 3048m view of how Foswiki works

Foswiki is a web application that runs inside a web server. When the web server receives a request that it recognises as being for Foswiki, it calls one of the perl scripts in the Foswiki bin directory. Each of the scripts has a specific function, as described in command and CGI scripts.

The scripts are responsible for interpreting the parameters passed in the request, and generating a response that is sent back to the browser, usually in the form of an HTML page.

Foswiki contains three engines that are used by the scripts; the template engine, the macro engine, and the TML engine.

1. The template engine reads predefined templates from files on the server. These templates contain directives that are expanded by the engine to create the output HTML skeleton. One of these directives expands to the topic text.
2. The macro engine then expands the macros in the skeleton. This is also where macros registered by plugins are expanded.
   • Macros, including those registered by plugins, are processed in a strict left-right-inside-out processing order. See macros for more details.
   • Macros include things like searches, so this is usually the slowest part of generating a page.
3. The TML (Topic Markup Language) engine now processes the expanded text, looking for TML constructs such as bulleted lists and tables. It generates HTML for these constructs.

Once all the engines have run, the output is sent to the browser.

There are several ways plugins can interact with this process.

1. They can register macros that are expanded by the macro engine. This is the simplest kind of plugin.
2. The can interact with various points in the rendering pipeline by implementing handlers (callbacks).
3. They can register REST handlers that are invoked via the rest script to support some form of transaction outside those supported by the standard scripts.

APIs available to Extensions

To be robust, extensions must avoid using any unpublished functionality from the Foswiki core. The following perl packages give access to features for extension authors. These APIs are not just for Plugins, they can be used in any type of extension. Click on the name of the package to see the full documentation.

• Foswiki::Func - this is the package you will use most. This package exposes a lot of core functionality in a way that is friendly to extension writers. If you find that there are two ways of doing something - a Foswiki::Func way, and another call to one of the packages below, then the Foswiki::Func way is almost always the right way.
• Foswiki::Meta - topic and web meta-data. Certain Foswiki::Func methods, and some plugin handlers, are passed (or return) objects of this type. Almost all of the methods of Foswiki::Meta have analagous methods in Foswiki::Func - in general you should call the Foswiki::Func methods in preference to calling Foswiki::Meta methods directly.
• Foswiki::OopsException - special exception for invoking the 'oops' script
• Foswiki::AccessControlException - access control exception
• Foswiki::Attrs - parser and storage object for macro parameters
• Foswiki::Time - time parsing and formatting
• Foswiki::Sandbox - safe server-side program execution, used for calling external programs.
• Iterators - these are classes that implement the Foswiki::Iterator specification
  • Foswiki::ListIterator - utility class for iterator objects that iterate over list contents
  • Foswiki::LineIterator - utility class for iterator objects that iterate over lines in a block of text
  • Foswiki::AggregateIterator - utility class for iterator objects that aggregate other iterators into a single iteration

In addition the following global variables may be referred to:

• $Foswiki::Plugins::VERSION - plugin handler API version number
• $Foswiki::Plugins::SESSION - reference to Foswiki singleton object
• $Foswiki::cfg - reference to configuration hash
• $Foswiki::regex - see Standard Regular Expressions, below

Foswiki:Development.GettingStarted is the starting point for more comprehensive documentation on developing for Foswiki.

Note: the APIs are available to all extensions, but rely on a Foswiki singleton object having been created before the APIs can be used. This will only be a problem if you are writing an extension that doesn't use the standard initialisation sequence.

Standard Regular Expressions

A number of standard regular expressions are available for use in extensions, in the $Foswiki::regex hash. these regular expressions are precompiled in an I18N-compatible manner. The following are guaranteed to be present. Others may exist, but their use is unsupported and they may be removed in future Foswiki versions.

In the table below, the expression marked type 'String' are intended for use within character classes (i.e. for use within square brackets inside a regular expression), for example:

   my $isCapitalizedWord =
     ( $s =~ /[$Foswiki::regex{upperAlpha}][$Foswiki::regex{mixedAlpha}]+/ );

Those expressions marked type 'RE' are precompiled regular expressions that can be used outside square brackets. For example:

   my $isWebName = ( $s =~ m/$Foswiki::regex{webNameRegex}/ );

Name	Matches	Type
upperAlpha	Upper case characters	String
upperAlphaNum	Upper case characters and digits	String
lowerAlpha	Lower case characters	String
lowerAlphaNum	Lower case characters and digits	String
numeric	Digits	String
mixedAlpha	Alphabetic characters	String
mixedAlphaNum	Alphanumeric characters	String
wikiWordRegex	WikiWords	RE
webNameRegex	User web names	RE
topicNameRegex	Topic names	RE
anchorRegex	#AnchorNames	RE
abbrevRegex	Abbreviations/Acronyms e.g. GOV, IRS	RE
emailAddrRegex	email@address.com	RE
tagNameRegex	Standard macro names e.g. %THIS_BIT% (THIS_BIT only)	RE

Creating New Plugins

With a reasonable knowledge of the Perl scripting language, you can create new plugins or modify and extend existing ones.

Anatomy of a Plugin

A (very) basic Foswiki plugin consists of two files:

• a Perl module, e.g. lib/Foswiki/Plugins/MyFirstPlugin.pm
• a documentation topic, e.g. MyFirstPlugin.txt

The Perl module can invoke other, non-Foswiki, elements, like other Perl modules (including other plugins), graphics, external applications, or just about anything else that Perl can call.

The plugin API handles the details of connecting your Perl module with the Foswiki core.

The Foswiki:Extensions.BuildContrib module provides a lot of support for plugins development, including a plugin creator, automatic publishing support, and automatic installation script writer. If you plan on writing more than one plugin, you probably need it.

Creating the Perl Module

Copy file lib/Foswiki/Plugins/EmptyPlugin.pm to <name>Plugin.pm. The EmptyPlugin does nothing, but it contains all the information you need to create you own custom plugin.

Writing the Documentation Topic

The plugin documentation topic contains usage instructions and version details. (The doc topic is also included in the distribution package.) To create a documentation topic:

1. Copy the plugin topic template from EmptyPlugin
2. Customize your plugin topic.
   • Important: In case you plan to publish your plugin on Foswiki.org, use Interwiki names for author names and links to Foswiki.org topics, such as Foswiki:Main/WikiGuest. This is important because links should work properly in a plugin topic installed on any Foswiki, not just on Foswiki.org.
3. Save your topic, for use in packaging and publishing your plugin.

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

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

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

Plugin Settings: <Description and settings for custom plugin settings, and those required by Foswiki.>"

• Plugins Preferences <If user settings are needed, link to preference settings and explain the role of the plugin name prefix

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 Foswiki:Extensions web.>

Packaging for Distribution

The Foswiki:Extensions.BuildContrib is a powerful build environment that is used by the Foswiki project to build Foswiki itself, as well as many of the plugins. You don't have to use it, but it is highly recommended!

If you don't want to (or can't) use the BuildContrib, then a minimum plugin release consists of a Perl module with a WikiName that ends in Plugin, ex: MyFirstPlugin.pm, and a documentation page with the same name(MyFirstPlugin.txt).

1. Distribute the plugin files in a directory structure that mirrors Foswiki. If your plugin uses additional files, include them all:
   • lib/Foswiki/Plugins/MyFirstPlugin.pm
   • data/Foswiki/MyFirstPlugin.txt
   • pub/Foswiki/MyFirstPlugin/uparrow.gif [a required graphic]
2. Create a zip archive with the plugin name (MyFirstPlugin.zip) and add the entire directory structure from Step 1. The archive should look like this:
   • lib/Foswiki/Plugins/MyFirstPlugin.pm
   • data/Foswiki/MyFirstPlugin.txt
   • pub/Foswiki/MyFirstPlugin/uparrow.gif

Publishing for Public Use

You can release your tested, packaged plugin to the Foswiki community through the Foswiki:Extensions web. All plugins submitted to Foswiki.org are available for public download and further development.

Publish your plugin by following these steps:

1. Post the plugin documentation topic to the Foswiki:Extensions web
2. Attach the distribution zip file(s) to the topic, eg: MyFirstPlugin.zip
3. Add a user support hub by visiting Foswiki:Support.CreateNewSupportHub
4. Optionally, check in the sources to the Foswiki subversion repository (see Foswiki:Development.HowToStartExtensionDevelopmentInSubversion)

Once you have done the above steps once, you can use the BuildContrib to upload updates to your plugin.

Thank you very much for sharing your plugin with the Foswiki community

Hints on Writing Fast Plugins

• Delay initialization as late as possible. For example, if your plugin is a simple syntax processor, you might delay loading extra Perl modules until you actually see the syntax in the text.
  • For example, use an eval block like this:
    eval { require IPC::Run }
return "<font color=\"red\">SamplePlugin: Can't load required modules ($@)</font>" if $@;
• Keep the main plugin package as small as possible; create other packages that are loaded if and only if they are used. For example, create sub-packages of BathPlugin in lib/Foswiki/Plugins/BathPlugin/.
• Avoid using preferences in the plugin topic; set $NO_PREFS_IN_TOPIC if you possibly can, as that will stop Foswiki from reading the plugin topic for every page. Use Config.spec instead.
• Use registered tag handlers

Security

• Badly written plugins can open security holes in Foswiki. This is especially true if care isn't taken to prevent execution of arbitrary commands on the server.
• Don't allow sensitive configuration data to be edited by users. Use the %Foswiki::cfg hash for configuration options. Don't ask installers to edit topics in the System web.
  • Integrating with configure describes the steps
  • Foswiki:Extensions.MailInContrib has an example
  • Foswiki:Extensions.BuildContrib can help you with this
• Make sure that all user input is checked and validated. Be especially careful to filter characters that might be used in perl string interpolation.
• Avoid eval, and if you must use it make sure you sanitise parameters
• Always use the Foswiki::sandbox to execute commands. Never use backtick or qx//.
• Use Foswiki::Func::checkAccessPermission to check the access rights of the current user.
• Always audit the plugins you install, and make sure you are happy with the level of security provided. While every effort is made to monitor plugin authors activities, at the end of the day they are uncontrolled user contributions.

Recommended Storage of Plugin Specific Data

Plugins sometimes need to store data. This can be plugin internal data such as cache data, or data generated for browser consumption such as images. Plugins should store data using Foswiki::Func functions that support saving and loading of topics and attachments.

Plugin Internal Data

You can create a plugin "work area" using the Foswiki::Func::getWorkArea() function, which gives you a persistent directory where you can store data files. By default they will not be web accessible. The directory is guaranteed to exist, and to be writable by the webserver user. For convenience, Foswiki::Func::storeFile() and Foswiki::Func::readFile() are provided to persistently store and retrieve simple data in this area.

Web Accessible Data

The internal data area is not normally made web-accessible for security reasons. If yoou want to store web accessible data, for example generated images, then you should use Foswiki's attachment mechanisms.

Topic-specific data such as generated images can be stored in the topic's attachment area, which is web accessible. Use the Foswiki::Func::saveAttachment() function to store the data.

Recommendation for file name:

• Prefix the filename with an underscore (the leading underscore avoids a name clash with files attached to the same topic)
• Identify where the attachment originated from, typically by including the plugin name in the file name
• Use only alphanumeric characters, underscores, dashes and periods to avoid platform dependency issues and URL issues
• Example: _GaugePlugin_img123.gif

Such auto-generated attachments han be hidden from users by setting the 'h' attribute in the attachment attributes.

Web specific data should be stored in the attachment area of a topic in the web that you specify for the purpose, e.g. Web.BathPlugPictures. Use the Foswiki::Func::saveAttachment() function to store the data in this topic.

Integrating with configure

Some extensions have setup requirements that are best integrated into configure rather than trying to use preference settings. These extensions use Config.spec files to publish their configuration requirements.

Config.spec files are read during configuration. Once a Config.spec has defined a configuration item, it is available for edit through the standard configure interface. Config.spec files are stored in the 'plugin directory' e.g. lib/Foswiki/Plugins/BathPlugin/Config.spec.

Structure of a Config.spec file

The Config.spec file for a plugin starts with a line that declares what section the configuration should appear in. The standard for all extensions is:

# ---+ Extensions

Next we have a sub-heading for the configuration specific to this extension, and the actual configuration options:

# ----++ BathPlugin
# This plugin senses the level of water in your bath, and ensures the plug
# is not removed while the water is still warm.

This is followed by one or more configuration items. Each configuration item has a type, a description and a default. For example:

# **SELECT Plastic,Rubber,Metal**
# Select the plug type
$Foswiki::cfg{BathPlugin}{PlugType} = 'Plastic';

# **NUMBER**
# Enter the chain length in cm
$Foswiki::cfg{BathPlugin}{ChainLength} = '30';

# **BOOLEAN EXPERT**
# Turn this option off to disable the water temperature alarm
$Foswiki::cfg{BathPlugin}{TempSensorEnabled} = '1';

The type (e.g. **SELECT** ) tells configure to how to prompt for the value. It also tells configure how to do some basic checking on the value you actually enter. All the comments between the type and the configuration item are taken as part of the description. The configuration item itself defines the default value for the configuration item. The above spec defines the configuration items $Foswiki::cfg{BathPlugin}{PlugType}, $Foswiki::cfg{BathPlugin}{ChainLength}, and $Foswiki::cfg{BathPlugin}{TempSensorEnabled} for use in your plugin. For example,

if( $Foswiki::cfg{BathPlugin}{TempSensorEnabled} && $curTemperature > 50 ) {
    die "The bathwater is too hot for comfort";
}

You can use other $Foswiki::cfg values in other settings, but you must be sure they are only evaluated under program control, and not when this file is parsed by perl. For example:

$Foswiki::cfg{BathPlugin}{MyBath} = "$Foswiki::cfg{PubDir}/enamel.gif"; # BAD
# Perl will interpolate variables in double-quotes, so $Foswiki::cfg{PubDir}
# will be evaluated at configuration time, which will make reconfiguration
# difficult.

$Foswiki::cfg{BathPlugin}{MyBath} = '$Foswiki::cfg{PubDir}/enamel.gif'; # GOOD
# The single quotes make sure $Foswiki::cfg{PubDir} will only be evaluated
# at run-time.

The Config.spec file is read by configure, and configure then writes LocalSite.cfg with the values chosen by the local site admin.

A range of types are available for use in Config.spec files:

BOOLEAN	A true/false value, represented as a checkbox
COMMAND length	A shell command
LANGUAGE	A language (selected from {LocalesDir}
NUMBER	A number
OCTAL	An octal number
PASSWORD length	A password (input is hidden)
PATH length	A file path
PERL	A simplified perl data structure, consisting of arrays, hashes and scalar values
REGEX length	A perl regular expression
SELECT choices	Pick one of a range of choices
SELECTCLASS package-specifier	Select a perl package (class) e.g. SELECTCLASS Foswiki::Plugins::BathPlugin::*Plug lets the user select between all packages with names ending in Plug, Foswiki::Plugins::BathPlugin::RubberPlug, Foswiki::Plugins::BathPlugin::BrassPlug etc.
STRING length	A string
URL length	A url
URLPATH length	A relative URL path

All types can be followed by a comma-separated list of attributes.

EXPERT	means this an expert option
M	means the setting is mandatory (may not be empty)
H	means the option is not visible in configure
5x80	means "use a 5 row, 80 column textarea". Can be used with any text entry field type, such as STRING, COMMAND, PERL etc.

See lib/Foswiki.spec for many more examples.

Config.spec files are also used for other (non-plugin) extensions. in this case they are stored under the Contrib directory instead of the Plugins directory.

Linking to configure

You can link to your configure settings by using the following:

[[%SCRIPTURL{"configure"}%/#BathPlugin$Extensions][configure]]

Replace BathPlugin with the name of your extension.

Maintaining Plugins

Discussions and Feedback on Plugins

Usually published plugins have a support hub in the Support web on Foswiki.org.Support hubs have links to where to discuss feature enhancements and give feedback to the developer and user communities.

Maintaining Compatibility with Earlier Foswiki Versions

The plugin interface (Foswiki::Func functions and plugin handlers) evolve over time. Foswiki introduces new API functions to address the needs of plugin authors. Plugins using unofficial Foswiki internal functions may no longer work on a Foswiki upgrade.

Organizations typically do not upgrade to the latest Foswiki for many months. However, many administrators still would like to install the latest versions of a plugin on their older Foswiki installation. This need is fulfilled if plugins are maintained in a compatible manner.

Tip: Plugins can be written to be compatible with older and newer Foswiki releases. This can be done also for plugins using unofficial Foswiki internal functions of an earlier release that no longer work on the latest Foswiki codebase. Here is an example; the Foswiki:Support.PluginsSupplement has more details.

    if( $Foswiki::Plugins::VERSION >= 1.1 ) {
        @webs = Foswiki::Func::getListOfWebs( 'user,public' );
    } else {
        @webs = Foswiki::Func::getPublicWebList( );
    }

Handling deprecated functions

From time-to-time, the Foswiki developers will add new functions to the interface (either to Foswiki::Func, or new handlers). Sometimes these improvements mean that old functions have to be deprecated to keep the code manageable. When this happens, the deprecated functions will be supported in the interface for at least one more Foswiki release, and probably longer, though this cannot be guaranteed.

When a plugin defines deprecated handlers, a warning will be shown in the list generated by %FAILEDPLUGINS%. Admins who see these warnings should check Foswiki.org and if necessary, contact the plugin author, for an updated version of the plugin.

Updated plugins may still need to define deprecated handlers for compatibility with old Foswiki versions. In this case, the plugin package that defines old handlers can suppress the warnings in %FAILEDPLUGINS%.

This is done by defining a map from the handler name to the Foswiki::Plugins version in which the handler was first deprecated. For example, if we need to define the endRenderingHandler for compatibility with Foswiki::Plugins versions before 1.1, we would add this to the plugin:

package Foswiki::Plugins::SinkPlugin;
use vars qw( %FoswikiCompatibility );
$FoswikiCompatibility{endRenderingHandler} = 1.1;

If the currently-running Foswiki version is 1.1 or later, then the handler will not be called and the warning will not be issued. Foswiki with versions of Foswiki::Plugins before 1.1 will still call the handler as required.

TWiki^® Plugins

Most plugins written for TWiki can also be run in Foswiki, by installing the TWikiCompatibilityPlugin. See Foswiki:Extensions.TWikiCompatibilityPlugin for more information.

Back to top

---

CGI and Command Line Scripts

Programs on the server performing actions such as rendering, saving and renaming topics.

These scripts are located in the bin and tools directories. This topic describes the interfaces to some of those scripts. All scripts in the bin directory can be called from the CGI (Common Gateway Interface) environment or from the command line. The scripts in the tools directory can only be called from the command line.

CGI Scripts

Details on CGI scripts located in the bin directory.

Note that a blank in the 'Default' column means that the parameter is not required, and has no default. required means the parameter is required, and has no default. text in italics describes default behaviour if no value is given.

General Information

CGI environment

In the CGI environment parameters are passed to the scripts via the URL and URL parameters. Environment variables are also used to determine the user performing the action. If the environment is not set up, the default user is used (usually guest).

Command-line

You must be have the bin directory on the perl path to run the scripts from the command line. To avoid issues with file permissions, run the scripts as the web server user such as nobody or www.

Parameters are passed on the command line using two possible formats:

• Traditional command line "switch" style format: -name value, The "-" prefix for the keyword is required.

$ cd /usr/local/foswiki/bin
$ save -topic MyWeb.MyTopic -user admin -action save -text "New text of the topic"

• Keyword format: parameter=value. A "-" prefix is optional.

$ cd /usr/local/foswiki/bin
$ save topic=MyWeb.MyTopic user=admin action=save text="New text of the topic"

All parameters require a value, even if that is the empty string. Note that parameters passed on the command-line should not be URL-encoded.

"Authentication" in the command line environment

Unlike the CGI environment, the default user for command line operations is AdminUser.

• The -user parameter is specific to the command line and is not recognized by in the web environment. It allows a user to be specified without requiring that the password be supplied. It is only active from the command line.
• The -username / -password parameters are processed by the authentication system and require the password be authenticated. Depending upon the authentication implementation, it may or may not be usable in the command line environment.

When calling a tools script from the command line, you normally need to be cd'd to the =bin directory e.g.

$ cd bin
$ ../tools/mailnotify -q -nonews -nochanges -Main -System

Context

Each script sets a Foswiki context to signal to plugins and other components the environment that they are running. In addition to the per-script context, two additional contexts are optionally set:

• command_line is set if there is no CGI query object available.
• static is set by scripts that render static content like PDF or other offline publishing tools

A comprehensive list of core context identifiers used by Foswiki is found in the System.IfStatements#Context_identifiers.

Common parameters

All the scripts accept a number of common parameters. The first two components of the URL after the script name are taken as the web and the topic, respectively. Standard URL parameters are:

Parameter	Description	Default
cover	Specifies temporary skin path to prepend to the skin path for this script only (see Skins)
debugenableplugins	During debugging it can be useful to selectively disable all but a subset of plugins. This parameter allows the caller to specify a comma-separated list of plugins that should be enabled.
foswikioriginalquery	The original query that was being made before a redirect for user confirmation was required.
foswiki_redirect_cache	Foswiki sometimes caches long lists of parameters that must survive over a sequence of browser redirects. This parameter identifies one of these caches. The parameter value is a "magic number" that uniquely idenitifies a file in the working/tmp directory. These files have a very short lifetime, and are destroyed when the cache is read.
logout	requests the LoginManager to log the current user out (this happens at the begining of the request so will terminate any other operation requested)
refresh	If the Foswiki page cache is in use, setting this parameter will invalidate the cache. Valid values are cache, on and all. See PageCaching for more information on the page cache.
response	Used as part of the request validation process.
skin	Overrides the default skin path (see Skins)	value of the SKIN preference
t	While the t parameter is not actively used by any scripts, it is used when building links to scripts such as edit, to ensure that each edit link is unique. This stops the browser from trying to use a cached reply from a previous call to the script.	generally set to current time, in seconds
topic	Overrides the web.topic path given in the URL (specify Web.TopicName)
user	Command-line only; set the name of the user performing the action. Note: this usage is inherently insecure, as it bypasses webserver login constraints. For this reason only authorised users should be allowed to execute scripts from the command line.
validation_key	part of cross-site scripting protection. Any request sent from browsers that might change data stored on the server must carry a key that indentifies the source of the request.
<any name>	Any other parameter name passed to the script is passed through for possible use by the script. This is typically only applicable to the edit, save and view scripts.

*Note:* Prior releases of Foswiki would accept the undocumented username and password parameter on any script. Foswiki 1.1.9 restricts this to the view script and only on POST transactions unless overridden in the Foswiki configuration.

attach

Despite the name, this script doesn't actually attach a file to a topic - for that, use upload. This script is part of the transactions sequence executed when a file is uploaded from the browser. it just generates the "new attachment" page for a topic.

Parameter	Description	Default
filename	Name of existing attachment (if provided, this is a "manage attachment" action)	this is a "new attachment" action

changes

Shows all the changes in the given web.

The changes script can receive one parameter:

Parameter	Description	Default
minor	If 0, show only major changes. If 1, show all the changes (both minor and major)	show major changes

The main difference between invoking this script and using WebChanges is that WebChanges is based on a %SEARCH%, while this script reads the changes file in each web, making it much faster.

NOTE: The result from changes script and the topic WebChanges can be different, if the changes file is deleted from a web. In particular, in new installations the changes script will return no results while the WebChanges topic will.

configure

configure is the browser script used for inspection of, and changes to, the site configuration. None of the parameters to this script are useable for any purpose except configure. See configure.

edit

The edit script understands the following parameters, typically supplied by HTML input fields.

A major role of the edit script is new topic creation. Parameters that are mainly relevant to new topic creation are marked with

Parameter name	Description	Default
action	If action=text, then hide the form. If action=form, then hide the normal text area and only edit the form.	edit both
breaklock	If set, any lease conflicts will be ignored, and the edit will proceed even if someone is already editing the topic.
contenttype	Optional parameter that defines the application type to write into the CGI header. May be used to invoke alternative client applications	text/html
formtemplate	Name of the form to instantiate in the topic. Set to none to remove any existing form.
notemplateexpansion	Do not expand any macros in the template topic. (see New topic creation below)	expand
onlynewtopic	If on, error if the topic already exists	edit existing topic
onlywikiname	If on, error if the name of a topic being created is not a WikiWord	allow non-wikiword names
redirectto	If the user continues from edit to save, and if the save (or cancel) process is successful, save will redirect to this topic or URL. The parameter value can be a TopicName, a Web.TopicName, or a URL. Note: Redirect to a URL only works if it is enabled in configure (Miscellaneous {AllowRedirectUrl}).
rev	Lets you specify a specific revision to use as the basis of the edit.	latest
template	Allows you to specify a different skin template. Overrides any setting of EDIT_TEMPLATE.
templatetopic	The name of the template topic, copied to get the initial content for a new topic. (see New topic creation below)
text	Set the text to be edited. If this parameter is not given, the text is taken from the existing topic (if it exists)
topicparent	Sets the parent topic.
<any name>	This can be used in two ways; first, if the topic has a form with a field called <any name>, it will set the value of that field. Second, it can be expanded in the topic text during topic creation - see New topic creation below

The following options are only available to the site Administrator. They can "rewrite history" and should be used with caution only when absolutely necessary.

Parameter name	Description	Default
delRev	Administrators only delete the most recent revision of the topic - all other parameters are ignored. You have to be an administrator to use this, and not all store implementations will support it. This option returns you to an editor for the current version, but the edit is ignored, and save will delete the latest revision.
repRev	Administrators only replace the text of the most recent revision of the topic with the text in the text parameter. text must included embedded meta-data tags. All other parameters are ignored. You have to be an administrator to use this, and not all store implementations will support it.

Skin notes:

The EDIT_TEMPLATE preference (or the template parameter) can be used to override the default 'edit' template on a per-web or per-topic basis.

The action parameter works by loading the editform.tmpl or edittext.tmpl templates in place of the standard edit.tmpl. If an EDIT_TEMPLATE has been defined, then it replaces edit, e.g. if EDIT_TEMPLATE=specialed and action=form then the template used will be specialedform

In most skins that are based on the default templates (such as Pattern skin) you can easily change the Edit and Edit WikiText buttons to append the action parameter, by setting the preference EDITACTION to the value text or form. (You can always get back to editing the whole topic by removing the action parameter from the URL browser Location window, and reloading the edit window).

New topic creation :

The string AUTOINC followed by one or more digits anywhere in the topic name will be converted to a number such that the resulting topic name is unique in the target web. However this doesn't happen until the topic is saved.

When a new topic is created using edit, the topic isn't actually created until the edit is saved. The content of the new topic is initialised according to the parameters you pass.

• templatetopic - defines the full name (web.topic) of a topic to use as a template for the new topic. The template topic is copied and, unless notemplateexpansion is set, the following macros are expanded in the topic text: URLPARAM, DATE, SERVERTIME, GMTIME, USERNAME, WIKINAME, WIKIUSERNAME, USERINFO.
• text - use this as the text of the topic. Macros are not expanded in this text. Overrides any text set in the templatetopic.
• formtemplate - Overrides any form set in the templatetopic.
• notemplateexpansion - given by templatetopic. Use this when you want a verbatim copy of a topic.
• onlynewtopic and onlywikiname are used to control validation of the new topic name.
• <any name> - besides the form field value setting described above, when creating a new topic, %URLPARAM{" <any name> "}% in the templatetopic will be expanded to the parameter value.

login

Used for logging in with TemplateLoginManager, and for interactive validation of operations that require user confirmation.

Parameter	Description	Default
foswikiloginaction	If 'validate', the login script is being used for interactive validation of an operation. Otherwise it is being used for login.
foswiki_origin	URL that was being accessed when an access violation occurred. the login process will redirect to this URL if it is successful
remember	If set, this will cause the user's login to be retained even after their browser is shut down.
sudo	promote login to internal wiki admin (admins only)
password	password of user logging in
username	username of user logging in (if set, login will attempt to authenticate)
usernamestep	used to initialise the username input field in the login form (will not attempt to authenticate)

Note: The login script will only accept the username and password fields when submitted with a POST.

logon

Used for logging in when Web Server authentication is being used (e.g. ApacheLoginManager). The script does nothing; it is purely a placeholder for triggering the login process. The webserver must be set up to require a valid user to access this script, thus triggering the webserver login process.

manage

Performs a range of management functions.

Note: The manage script can only be called via the HTTP POST method. Make sure you specify method="post" if you call the manage script via a form action. It is not possible to call manage from an <a href ...> link.

Parameter	Description	Default
action	One of create, createweb, changePassword, resetPassword, bulkRegister, deleteUserAccount, editSettings, saveSettings, restoreRevision	required

action=create

Alternative entry point for creation, via edit, of a new topic, used by screens that support several actions using manage.

Parameter	Description	Default
topic	Name of topic to create (can be web.topic)	required

Other parameters are the same as for edit.

action=createweb

Create a new web

Parameter	Description	Default
baseweb	Name of the web to copy to create the new web	required
newtopic	Value of %TOPIC% within the web creation message. Optionally used in some skins to signify a non-default home topic.
newweb	Name of the new web	required
nosearchall	Value for NOSEARCHALL	''
webbgcolor	value for WEBBGCOLOR	''
websummary	Value for WEBSUMMARY	''

action=editSettings

No parameters

action=saveSettings

Parameter	Description	Default
originalrev	Revision that the edit started on	latest
redirectto	If the savesettings process is successful, save will redirect to this topic or URL. The parameter value can be a TopicName, a Web.TopicName, or a URL. Note: Redirect to a URL only works if it is enabled in configure (Miscellaneous {AllowRedirectUrl}).	redirect to the web.topic from the URL path
text	Text of the topic	required
action_save	Must be set to Save or settings are not saved	required
action_cancel	Must be set to Cancel to cancel save.	required

If neither action_save or action_cancel are provided, an oops error is issued. All other parameters may be interpreted as form fields, depending on the current form definition in the topic.

action=bulkRegister

See BulkRegistration.

Parameter	Description	Default
logtopic	Topic to save the log in	same as topic name, with 'Result' appended
overwritehometopics	Whether to overwrite existing home topics or not	do not overwrite

action=changePassword

Change password, email address, or both, of a user.

Parameter	Description	Default
email	new email address
oldpassword	current password	required, unless current user is an admin
password	new password
passwordA	new password confirmation	required if password is given
username	login name of user to change password/email for	required

password, =passwordA and email are optional. If neither or password and passwordA is set, then the user password is left unchanged. If email is unset, their email is left unchanged.

action=resetPassword

Reset the password for a single or multiple users

Parameter	Description	Default
introduction	message to be sent alongside the reset, most often used to announce to the user that they have been given an account.
loginname	list of usernames to reset	required

This is used by BulkResetPassword and ResetPassword. Only administrators can provide a list of LoginNames, non-admins can only provide a single LoginName.

BulkRegistration provides the means to create multiple accounts but it does not announce those accounts to the users who own them. BulkResetPassword is used to assign the passwords, the Introduction is used to explain why they are receiving the mail.

action=deleteUserAccount

Unregisters (removes) the currently logged-in user.

Parameter	Description	Default
password	Users' password	required

action=restoreRevision

Alternative entry point for edit, used by screens that support several actions using manage. Parameters are as for =edit.

action=addUserToGroup

add a user / list of users to a group

Parameter	Description	Default
create	create the group if it doesn't exist	0
groupname	groupname to change	required
redirectto	If the add process is successful, manage will redirect to this topic or URL. The parameter value can be a TopicName, a Web.TopicName, or a URL. Note: Redirect to a URL only works if it is enabled in configure (Miscellaneous {AllowRedirectUrl}).	None. An Oops screen showing the results is returned.
username	list of usernames/wikinames to add to group	required

action=removeUserFromGroup

remove a user / list of users to a group

Parameter	Description	Default
groupname	groupname to change	required
redirectto	If the remove process is successful, manage will redirect to this topic or URL. The parameter value can be a TopicName, a Web.TopicName, or a URL. Note: Redirect to a URL only works if it is enabled in configure (Miscellaneous {AllowRedirectUrl}).	None. An Oops screen showing the results is returned.
username	list of usernames/wikinames to add to group	required

oops

This script is mainly used for rendering pages containing error messages, though it is also used for some functional actions such as manage pages (move topic etc).

oops templates are used with the oops script to generate system messages. This is done to make internationalisation or other local customisations simple.

The oops script supports the following parameters:

Parameter	Description	Default
def	Can be set to the name of a single definition within template. This definition will be instantiated in the template wherever %INSTANTIATE% is seen. This lets you use a single template file for many messages. For an example, see oopsmanagebad.tmpl.
paramN	Where N is an integer from 1 upwards. These values will be substituted into template for %PARAM1% etc.
template	Name of the template file to display	oops

preview

This script is deprecated. Its functions are covered by the save script.

rdiff

Renders the differences between version of a topic

Parameter	Description	Default
context	number of lines of context
render	the rendering style {sequential, sidebyside, raw, debug}	DIFFRENDERSTYLE, sequential
rev1	the higher revision	latest
rev2	the lower revision	latest
type	history gives a history, diff rev1 against rev2, last latest to previous	diff

The context parameter is only respected if the back-end store supports context diffs.

register

Parameter	Description	Default
action	register or verify or approve	required

Note: The register script can only be called via the HTTP POST method except when the action is verify. Make sure you specify method="post" if you call the register script via a form action. It is not possible to call register from an <a href ...> link. The verify action is an exception as it is used to verify registration by clicking a href link from an email.

Parameter	Description	Default
addtogroups	Accepts a comma-separated list of group names to add the user to.
code	(verify= only) Activation code, verifies a pending registration
create	If on, and a group being added to does not exist, create it.
email	New user's email address	required
firstname	New user's first name	required
lastname	New user's surname	required
loginname	New user's login name	required
password	New user's password
wikiname	Wikiname of user being registered	required
<any name>	Any other parameter passed during registration will normally be passed on into the new user's home topic, or ignored.

rename

Used for renaming webs, topics and attachments.

Parameter	Description	Default
action	renameweb or renameother	renameother
confirm	if non-0, requires a second level of confirmation
referring_topics	(internal use only) list of topics that refer to the web or topic being renamed
redirectto	If the rename process is successful, rename will redirect to this topic or URL. The parameter value can be a TopicName, a Web.TopicName, or a URL. Note: Redirect to a URL only works if it is enabled in configure (Miscellaneous {AllowRedirectUrl}).	the renamed topic

action="renameweb"

Rename a web.

Parameter	Description	Default
newparentweb	new parent web name	existing parent
newsubweb	new web name

action=renameother

Rename a topic or an attachment.

Parameter	Description	Default
attachment	Attachment to move
currentwebonly	if non-0, searches current web only for links to this topic	search all webs
newattachment	New name for attachment	same as attachment, if given
newtopic	new topic name	required
newweb	new web name	required
nonwikiword	if on, a non-wikiword is acceptable for the new topic name	off
template	template for error when an attachment doesn't exist, deleteattachment for when deleting an attachment

Note: The rename script can only be called via the HTTP POST method. Make sure you specify method="post" if you call the rename script via a form action. It is not possible to call rename from an <a href ...> link.

resetpasswd

This script is deprecated. Its functions are covered by the manage script.

rest

This REST (Representational State Transfer) script can be invoked via http in the same way as the other scripts (see Invocation Examples, below) to execute a function that is associated to a "subject" and a "verb" (see below). These functions are usually registered by plugins using the Foswiki::Func::registerRESTHandler method. The rest script will print the result directly to the browser unless the endPoint parameter is specified, in which case it will output a redirect to the given topic.

The rest script supports the following parameters:

Parameter	Description	Default
endPoint	Where to redirect the response once the request is served, in the form "Web.Topic". If not given, the REST script must generate a valid response.
password	See username
username	If TemplateLogin, or a similar login manager not embedded in the web server, is used, then you need to pass a username and password to the server. The username and password parameters are used for this purpose.

Note: As of 1.1.9, the rest script no longer will accept the username and password fields by default. If the prior behavior is required, it can be enabled in bin/configure by setting $Foswiki::cfg{Session}{AcceptUserPwParam} = /^rest$/;. Note that even with this enabled, the rest script requires that the username and password be entered using POST.

REST scripts that require a topic context must use the standard topic parameter to pass the topic name, as the URL path is used to identify the REST function. If not defined, then the topic context in REST handlers will be Main.WebHome.

The function is free to use any other query parameters for its own purposes.

The rest script should always require authentication in any site that has logins. Otherwise there is a risk of opening up major security holes. So make sure you add it to the list of authenticated scripts if you are using ApacheLogin.

Invocation Examples

The rest script assumes that it will be called with URL in the form:

http://my.host/bin/rest/<subject>/<verb>

where <subject> must be the WikiWord name of one of the installed Plugins, and the <verb> is the alias for the function registered using the Foswiki::Func::registerRESTHandler method. The <subject> and <verb> are then used to lookup and call the registered function.

<subject> and <verb> are checked for illegal characters exactly in the same way as the web and topic names.

As an example, the EmptyPlugin has registered a function to be used with the rest script under the subject EmptyPlugin and the verb example.

The URL to call this function from a browser would be:

• https://wiki.bacchus-env.eu/bin/rest/EmptyPlugin/example?debugenableplugins=EmptyPlugin

alternatively, to run it from the commandline:

• cd foswiki/bin ; ./rest /EmptyPlugin/example debugenableplugins=EmptyPlugin

Note that for Plugins to register REST handlers, they must be enabled in configure.

Retrieving passed values

Additional parameters can be recovered via the query object in the $session, for example with the url:

http://my.host/bin/rest/MyPlugin/update?web=foo

The url parameters can be processed using:

my $query = $session->{request};
my $web = $query->{param}->{web}[0];

save

The save script performs a range of save-related functions.

Parameter	Description	Default
action_addform	Redirect to the "change form" page.
action_cancel	exit without save, return to view
action_checkpoint	save and redirect to the edit script, dontnotify is on
action_delRev	Administrators only delete the most recent revision of the topic - all other parameters are ignored. You have to be an administrator to use this, and not all store implementations will support it.
action_preview	preview edited text
action_quietsave	save, and return to view, dontnotify is on
action_replaceform	Redirect from the "change form" page.
action_repRev	Administrators only replace the text of the most recent revision of the topic with the text in the text parameter. text must included embedded meta-data tags. All other parameters are ignored. You have to be an administrator to use this, and not all store implementations will support it.
action_save	default behaviour; save, return to view
dontnotify	if non-0, suppress change notification
edit	The bin script to use to re-edit the topic when action is checkpoint	edit
editaction	When action is checkpoint, add form or replace form..., this is used as the action parameter to the edit script that is redirected to after the save is complete.
editparams	The parameter string to use to edit the topic when action is checkpoint
forcenewrevision	if set, forces a revision even if BACCHUS Wiki thinks one isn't needed
formtemplate	if defined, use the named template for the form (will remove the form if set to 'none')
newtopic	If templatetopic is given, and this parameter is set to 1 and the topic does not exist, will clear the initial topic text.
onlynewtopic	If set, error if topic already exists
onlywikiname	If set, error if topic name is not a WikiWord
originalrev	Revision on which the edit started.
redirectto	The save process will redirect to this topic or URL if it is successful. (Typically this would be the URL that was being viewed when edit was invoked). The parameter value can be a TopicName, a Web.TopicName, or a URL. Note: Redirect to a URL only works if it is enabled in configure (Miscellaneous {AllowRedirectUrl}).	topic specified in URL path
template	The template to use to re-edit the topic when action is checkpoint
templatetopic	Name of a topic to use as a template for the text and form (new topic only)
text	New text of the topic
topicparent	If 'none' remove any current topic parent. If the name of a topic, set the topic parent to this.
<any name>	If the topic has a form with a field called <any name>, it will set the value of that field.

Any errors will cause a redirect to another page, either an oops page to report the error, or a login if the save is not authorized.

The string AUTOINC followed by one or more digits anywhere in the topic name will be converted to a number such that the resulting topic name is unique in the target web.

When the action is save, checkpoint, quietsave, or preview:

1. The new text is taken from the text parameter, if it is defined,
   • otherwise it is taken from the templatetopic, if it is defined, (new topic only)
   • otherwise it is taken from the previous version of the topic, if any,
2. The name of the new form is taken from the formtemplate, if defined
   • otherwise it is taken from the templatetopic, if defined, (new topic only)
   • otherwise it is taken from the previous version of the topic, if any,
   • otherwise no form is attached.
3. The value for each field in the form is taken from the query, if it is defined
   • otherwise it is taken from the templatetopic, if defined, (new topic only)
   • otherwise it is taken from the previous version of the topic, if any,
   • otherwise it defaults to the empty string.

Merging is only enabled if the topic text comes from text and originalrev is > 0 and is not the same as the revision number of the most recent revision. If merging is enabled both the topic and the meta-data are merged.

Form field values are passed in parameters named 'field' - for example, if I have a field Status the parameter name is Status.

Note: The save script can only be called via HTTP POST method. Make sure you specify method="post" if you call the save script via a form action. Example:

<form name="new" action="%SCRIPTURLPATH{save}%/%SANDBOXWEB%/" method="post">
    ...
</form>

It is not possible to call save from an <a href ...> link.

search

This cgi script has been deprecated. When called, it will redirect to the WebSearch topic, and the parameters will be passed on.

statistics

Refresh the %ISSTATISTICSTOPIC% topics in range of webs.

Parameter	Description	Default
logdate	YYYYMM to generate statistics for	current month
webs	comma-separated list of webs to run stats on	all accessible webs

for example:

1. from browser https://wiki.bacchus-env.eu/bin/statistics updates all user webs
2. from browser https://wiki.bacchus-env.eu/bin/statistics?webs=Userweb,Sandbox updates Userweb,Sandbox
3. from browser https://wiki.bacchus-env.eu/bin/statistics/System/ updates System
4. from command line bin/statistics updates all user webs
5. from command line bin/statistics -webs=Userweb,Sandbox updates Userweb,Sandbox
6. from command line bin/statistics System.WebHome updates System

see SiteTools#WebStatistics for more details on %ISSTATISTICSTOPIC% and how to update statistics using cron.

upload

Uploads an attachment to a topic. The HTTP request is expected to be in multipart/form-data format.

Parameter	Description	Default
changeproperties	if non=0, this is a property change operation only - no file will be uploaded.
createlink	if non-0, will create a link to file at end of topic
filecomment	Comment to associate with file in attachment table
filepath	local (client) path name of the file being uploaded. This is used to look up the data for the file in the HTTP query.
hidefile	if non-0, will not show file in attachment table
noredirect	Normally the script will redirect to 'view' when the upload is complete, but also designed to be useable for REST-style calling using the 'noredirect' parameter. If this parameter is set it will return an appropriate HTTP status code and print a message to STDOUT, starting with 'OK' on success and 'ERROR' on failure.
redirectto	URL to redirect to after upload. The parameter value can be a TopicName, a Web.TopicName, or a URL. Redirect to a URL only works if it is enabled in configure, and is ignored if noredirect is specified. (Miscellaneous {AllowRedirectUrl}).	topic specified in URL path

Tips

• You can use a tool like curl to upload files from the command line using this script.
• You can call upload easily from XmlHttpRequest in Javascript.

Note: The upload script can only be called via HTTP POST method. Make sure you specify method="post" if you call the upload script via a form action. It is not possible to call upload from an <a href ...> link.

view

Used for viewing topics.

Parameter	Description	Default
contenttype	Allows you to specify a different Content-Type: (e.g. contenttype=text/plain)	text/html
raw	on - show the text of the topic in a scrollable textarea. debug - as on, but also shows the metadata (forms etc) associated with the topic. text - show only the source of the topic, as plain text (Content-type: text/plain). Only shows the body text, not the form or other meta-data. all - show only the source of the topic, as plain text (Content-type: text/plain), with embedded meta-data. This may be useful if you want to extract the source of a topic to a local file on disc.
rev	Revision to view (e.g. rev=45)	latest
SEARCH<hex number>	Identifies a result set that is being paged through
section	Allows to view only a part of the topic delimited by a named section (see System.VarSTARTSECTION). If the given section is not present, no topic content is displayed.
template	Allows you to specify a different skin template, overriding the 'view' template the view script would normally use. The default template is view. For example, you could specify /bin/view/System/CommandAndCGIScripts?template=edit. This is mainly useful when you have specialised templates for a Wiki Application.
<any name>	It can be expanded in the topic text during rendering and referenced in IF statements - See the System.VarURLPARAM macro and System.IfStatements

For historical reasons, the view script has a special interpretation of the text skin. This skin cannot be redefined.

viewfile

Used for viewing attachments. Normally, a site will publish the attachments (pub) directory using a URL. However if it contains sensitive information, you will want to protect attachments using AccessControls. In this case, you can use the viewfile script to give access to attachments while still checking access controls.

Parameter	Description	Default
filename	name of attachment	required
rev	Revision to view	latest

Instead of using the filename parameter, you can append the attachment name to the end of the URL path (after the topic) e.g. https://wiki.bacchus-env.eu/bin/viewfile/Webname/TopicName/Attachment.gif

Tool Scripts

Details on command line scripts located in the tools directory.

geturl.pl

This is a very simple script to get the content of a web site, either using GET or POST. It is marked as deprecated and might be removed in a future release. Its functions are covered by the standard wget and curl commands, which have the added advantage of performing authentication..

• Usage: geturl.pl <host> <path> [<port> [<header>]]
• Example: geturl.pl some.domain /some/dir/file.html 80
• Will get: http://some.domain:80/some/dir/file.html
• Example: geturl.pl POST some.domain /bin/statistics?webs=Sandbox
• Will post: http://some.domain/bin/statistics?web=Sandbox triggering a statistics run

rewriteshebang.pl

Simple script to rewrite the #!/usr/bin/perl shebang lines specific to your local Perl installation. It will rewrite the first line of all your cgi scripts so they use a different shebang line. Use it if your perl is in a non-standard location, or you want to use a different interpreter (such as 'speedy').

tick_foswiki.pl

This script executes a number of non-essential regular administration tasks that will help keep your site healthy and happy, such as removing expired sessions and lease files.

It is intended to be run as a cron job or a scheduled task once a week. Example crontab entry:
0 0 * * 0 cd /usr/local/foswiki/bin && perl ../tools/tick_foswiki.pl

Note: The script has to be run by a user who can write files created by the webserver user.

Extensions, such as the MailerContrib, also install tool scripts. Check the documentation of the extension for details.

extension_installer

This script will download and install, or remove an extension.

For more details, execute it from the Foswiki root directory with the usage parameter:

./tools/extension_installer usage

Note that this script is a generic version of the _installer script shipped with each extension. There are 3 ways to install a script using these scripts:

• Download SomePlugin_installer and execute it from the Foswiki root directory
• run ./tools/extension_installer SomePlugin - the extension will be downloaded and installed
• Use the configure web interface to the Extensions Installer.

dependencies_installer.pl

This script searches for missing Perl modules that should be available according to your Foswiki environment and offers installation via CPANPLUS or a supported package management system. It eases Perl module installation, which is part of a Foswiki installation, may be part of an extension installation or may need to follow upgrades. The script can be used to just provide an overview of Foswiki related perl modules in your installation by running it with option -v.

For more details, execute it using option -h (help) or -m (manual):

./dependencies_installer.pl -h
Usage:
    dependencies_installer.pl [-h|?|--help] [-m|--man] [-p|--print]
    [-q|--questions] [-v|--verbose]

[...]

---

Related Topics: AdminDocumentationCategory, DeveloperDocumentationCategory

Back to top

---

Site Tools

Utilities for searching, navigation, and monitoring site activity

Site Tools include utilities for navigating, searching and keeping up with site activity.

In particular, you have two highly configurable, automated site monitoring tools, WebNotify, to e-mail alerts when topics are edited, and WebStatistics, to generate detailed activity reports.

WebNotify - recent changes alert

About the Web changes notification service

Each Foswiki web has an automatic e-mail notification service that sends you an e-mail with links to all of the topics modified since the last alert.

Users subscribe to email notifications using their WikiName or an alternative email address, and can specify the webs/topics they wish to track. Whole groups of users can also be subscribed for notification.

The general format of a subscription is:

three spaces * subscriber [ : topics ]

Where subscriber can be a WikiName, an email address, or a group name. If subscriber contains any characters that are not legal in an email address, then it must be enclosed in 'single' or "double" quotes. Note: The guest user Main.WikiGuest does not have an email address mapped to it, and will never receive email regardless of the configuraion of that user.

topics is an optional space-separated list of topics:

• ... without a Web. prefix
• ...that exist in this web.

Users may further customize the specific content they will receive using the following controls:

• Using wild-card character in topic names - You can use * in a topic name, where it is treated as a wildcard character. A * will match zero or more other characters - so, for example, Fred* will match all topic names starting with Fred, *Fred will match all topic names ending with Fred, and * will match all topic names.
• Unsubscribing to specific topics - Each topic may optionally be preceded by a '+' or '-' sign. The '+' sign means "subscribe to this topic". The '-' sign means "unsubscribe" or "don't send notifications regarding this particular topic". This allows users to elect to filter out certain topics. Topic filters ('-') take precedence over topic includes ('+') i.e. if you unsubscribe from a topic it will cancel out any subscriptions to that topic.
• Including child-topics in subscription - Each topic may optionally be followed by an integer in parentheses, indicating the depth of the tree of children below that topic. Changes in all these children will be detected and reported along with changes to the topic itself. Note This uses the Foswiki "Topic parent" feature.
• Subscribing to entire topic ("news mode") - Each topic may optionally be immediately followed by an exclamation mark ! and/or a question mark ? with no intervening spaces, indicating that the topic (and children if there is a tree depth specifier as well) should be mailed out as complete topics instead of change summaries. ! causes the full topic to be mailed every time even if there have been no changes, and ? will mail the full topic only if there have been changes. One can limit the content of the subscribed topic to send out by inserting %STARTPUBLISH% and %STOPPUBLISH% markers within the topic.

Examples: Subscribe Daisy to all changes to topics in this web.

   * daisy.cutter@flowers.com

Subscribe Daisy to all changes to topics that start with Web.

   * daisy.cutter@flowers.com : Web*

Subscribe Daisy to changes to topics starting with Petal, and their immediate children, WeedKillers and children to a depth of 3, and all topics that match start with Pretty and end with Flowers e.g. PrettyPinkFlowers.

   * DaisyCutter: Petal* (1) WeedKillers (3) Pretty*Flowers

Subscribe StarTrekFan to changes to all topics that start with Star except those that end in Wars, sInTheirEyes or shipTroopers.

   * StarTrekFan: Star* - *Wars - *sInTheirEyes - *shipTroopers

Subscribe Daisy to the full content of NewsLetter whenever it has changed.

   * daisy@flowers.com: NewsLetter?

Subscribe buttercup to NewsLetter and its immediate children, even if it hasn't changed.

   * buttercup@flowers.com: NewsLetter! (1)

Subscribe GardenGroup (which includes Petunia) to all changed topics under AllNewsLetters to a depth of 3. Then unsubscribe Petunia from the ManureNewsLetter, which she would normally get as a member of GardenGroup:

   * GardenGroup: AllNewsLetters? (3)
   * petunia@flowers.com: - ManureNewsLetter

Subscribe IT:admins (a non-Foswiki group defined by an alternate user mapping) to all changes to Web* topics.

   * 'IT:admins' : Web*

A user may be listed many times in the WebNotify topic. Where a user has several lines in WebNotify that all match the same topic, they will only be notified about changes in that topic once (though they will still receive individual mails for news topics).

If a group is listed for notification, the group will be recursively expanded to the email addresses of all members.

Warning: Because an email address is not linked to a user name, there is no way for Foswiki to check access controls for subscribers identified by email addresses. A subscriber identified by an email address alone will only be sent change notifications if the topic they are subscribed to is readable by guest users. You can limit which email addresses can be used in WebNotify, or even block use of emails altogther, using the {MailerContrib}{EmailFilterIn} setting in configure.

Tip: List names in alphabetical order to make it easier to find the names.

Note for System Administrators: Notification is supported by an add-on to the Foswiki kernel called the MailerContrib. See the MailerContrib topic for details of how to set up this service.

Note: If you prefer a news feed, point your reader to WebRss (for RSS 1.0 feeds) or WebAtom (for ATOM 1.0 feeds). Learn more at WebRssBase and WebAtomBase, respectively.

---

Related topics: Main.WikiUsers, UserRegistration

WebSearch - search the site

WebSearch is a flexible search facility, part of the core feature set. WebSearchAdvanced offers more options, including:

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

See also: SearchHelp for help; Macros and FormattedSearch for including hard-coded searches in text.

WebChanges - what's new

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

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

%SEARCH{ "1" web="%BASEWEB%" type="query" nosearch="on"
  order="modified" reverse="on" limit="50"
}%

WebRss and WebAtom - news feeds on recent changes

You can point your news reader at WebRss and WebAtom to find out what is new in a web. WebRssBase and WebAtomBase have the details. Like WebChanges, this is based on a %SEARCH{}%.

WebIndex - list of topics

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

%SEARCH{"1" scope="topic" type="query" nosearch="on" }%

WebStatistics - site statistics

See SiteToolStatistics for detailed configuration and customization information.

Introduction

Statistics of visits to pages in a web can be generated manually or automatically, on a per-web basis. Statistics are compiled as a running total for each month.They include 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. Statistics from previous months are saved, and a new row is written to the table at the beginning of each month.

• You can create a WebStatistics link using %STATISTICSTOPIC%

Statistics are compiled by a script that processes the Foswiki event log. The script can be run two ways:

• Manually, by an authorized user from a browser URL
• Automatically by a shell script, usually run as a cron job

Manually running statistics

The following form can be used to run statistics and create the WebStatistics topics for selected or all webs.

Note: The current user - Main.WikiGuest must have access rights to read/write the WebStatistics topics, and if missing, must have authority to create the WebStatistics in the selected webs.

Run statistics on a list of one or more webs

Enter a comma separated list of webnames. Enter a subweb by specifying ParentWeb/SubWeb/ Web names must follow web naming rules and start with an upper case letter.

Additional Settings

Autocreate missing WebStatistics

Select this option if you want the Statistics script to auto-create the WebStatistics if it is missing. (Note: this operation must be enabled in the configuration).

Process sub-webs

Process any subwebs of the requested webs. If this is not selected, then sub-webs must be explicitly listed in the list of webs.

Specify date to process

Specify the date of the logs to process in YYYYMM format. Example: 201203 to request March 2012.

Log Files

Foswiki generates an event log which is used by the statistics script

• The directory for the log file is defined by the {Log}{Dir} setting in configure
• The file name is events.log Old events are archived as events.<year><month>
• Example path name: working/logs/events.log
• Each access gets logged as:
  | <time> | <wikiusername> | <action> | <web>.<topic> | <extra info> | <IP address> |
• Example log entry:
  | 26 Dec 2024 - 05:21 | Main.WikiGuest | view | System.WebRss | | 66.124.232.02 |
• By default the following actions are logged:

  Script	Action name	Extra info
  attach	attach	when viewing attach screen of previous uploaded attachment: filename
  changes	changes
  edit	edit	when editing non-existing topic: (not exist)
  login	login	Authentication failure or success
  manage	rename	when moving topic: moved to Newweb.NewTopic
  manage	move	when moving attachment: Attachment filename moved to Newweb.NewTopic
  manage	renameweb	when renaming a web: oldweb moved to newweb
  rdiff	rdiff	higher and lower revision numbers: 4 3
  register	regstart	WikiUserName, e-Mail address, LoginName: user attempts to register
  register	register	E-mail address: user successfully registers
  register	bulkregister	WikiUserName of new, e-mail address, admin ID
  save	save	when replacing existing revision: repRev 3 when user checks the minor changes box: dontNotify when user changes attributes to an exising attachment: filename.ext
  save	cmd	special admin parameter used when saving
  search	search	search string
  upload	upload	filename
  view	view	when viewing non-existing topic: (not exist) when viewing previous topic revision: r3
  n/a	logout	When authentication information is cleared

• You can disable the logging (and therefore the reporting) of individual actions using the {Log}{Action} EXPERT setting in configure.

E-mail

See also System.InstallationGuidePart2#EmailConfig

Configuring outgoing mail

Outgoing mail is required for UserRegistration and for recent changes alert.

The preferred place to configure e-mail is in the configure "Mail and Proxies" tab tool (LocalSite.cfg). The configure tool fully documents these setting.

The notify e-mail uses the default changes.tmpl template, or a skin if activated by a preference setting.

mailnotify also relies on a hidden file in each data/Web directory: .changes and a file with the Web name (one per web) in the working/work_areas/MailerContrib/ directory. Make sure both are writable by your web server process. .changes contains a list of changes; The file in the working/work_areas/MailerContrib/ directorycontains a timestamp of the last time notification was done for the web.Both files are automatically created as needed.

Legacy and current configuration

Caution: Older versions of Foswiki, and especially TWiki migrations might configure e-mail in the preference settings topic.Make sure you delete that setting if you are using a SitePreferences topic from a previous release of Foswiki.

Parameter	configure (Current)	preference settings (Legacy)	Default	Description
Global enable	{EnableEmail}	n/a	enabled	Globally enable/disable email support.
Extermal mail program	{MailProgram}	n/a	'/usr/sbin/sendmail -t -oi -oeq'	E-mail program used when Net:SMTP is unavailable
Mail relay host	{SMTP}{MAILHOST}	SMTPMAILHOST	not set	Destination SMTP Server used to receive and relay email. Net::SMTP is disabled if this is not set.
Mail sending hostname	{SMTP}{SENDERHOST}	SMTPSENDERHOST	not set	Hostname used to identify sender. Some SMTP configurations will require this.
SMTP Password	{SMTP}{Password}	not supported	not set

Setting the automatic e-mail schedule

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

% crontab -e
0 1 * * * (cd /path/to/bin; ./mailnotify -q)

The above line will run mailnotify nightly at 01:00. The -q switch suppresses all normal output.

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

On Windows: You can use a scheduled task if you have administrative privileges.

Site Permissions

• AccessControl describes how to restrict read and write access to topics and webs, by users and groups
• SitePermissions lists the permissions settings of the webs on this site

Help with crontab

The crontab command is used to schedule commands to be executed periodically.

• Wikipedia:Crontab - crontab documentation
• pycron - crontab for Windows

---

Related Topics: AdminDocumentationCategory, AdminToolsCategory

Back to top

---

Managing Topics

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

Overview

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

How to rename or move a topic

1. Select the [More topic actions] link (normally located in an action toolbar at the top or bottom of page) on the topic to be changed. Then, in the new screen, click [Rename or move topic...] or [Delete topic...]. You can now rename and/or move in one operation:
   • Move: Select the target web if other than the current web
   • Rename: Enter the new topic name - default is current name

     You'll be warned if any of the topics to be affected are locked (being edited), or if there is a name conflict.

2. Prevent updates by unchecking individual items on the list of referring links - these topics will NOT to be updated with the new name (by default, only links in the same web will be updated).
3. Click on [Rename]: the topic will be renamed and links to the topic updated as requested.
   • If any of the referring pages are locked then they will be listed: you can correct these later by again pressing [Rename].

There is a Put back feature that allows you to undo a rename/move/delete action - an instruction line and an undo link will appear under the [Rename or move topic] section of the [More topic actions] page. This allows you to revert from the last modification only.

How to delete a topic

Foswiki deletes topics by moving them to the hidden Trash web.

1. Select the [More actions] link (normally located in an action toolbar at the top or bottom of page) on the topic to be changed. Then, in the new screen, click [Delete topic...]. That will bring up the "rename" form prepopulated with the Trash web and a suitable topic name.
2. Click on [Delete]: the topic will be renamed and moved to the Trash web as requested.

How to copy a topic

1. Select the [More actions] link (normally located in an action toolbar at the top or bottom of page) on the topic to be changed.
2. On the "More actions" page, scroll down to the "Copy topic" section. In the "Name of copy" text box, enter in the new topic name. To copy the topic to another web, fully qualify the topic name with the web name, separating the two with a period (for example, Web.TopicName).
3. Select the [Copy topic] button. You will be directed to an edit page for the newly-created topic. You can save the new copy immediately, or make some changes and then save it.

Deleted topics: How to clear the trash

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

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

This can only be done from on the server, not through the browser. Be sure to recreate the empty TrashAttachments after you remove it.

Since simple FTP access to the Trash directory is all that is required for maintenance, it is possible to grant Trash admin privileges to multiple users, while strictly limiting server access.

Redirecting from an old topic

The default "new topic" screen tells the user when a topic being created used to exist, but was moved. So if anyone follows a link to a moved topic, they will be able to click through to the new name.

How rename/move works

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

How referring topics are found

First, matching topics in the current web are listed - matches are to topic. Next, all webs (including the current one) are listed that match web.topic. All webs will be searched during rename, even if NOSEARCHALL is defined on a web, though access permissions will of course be honoured.

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

Effect of user access settings

User permissions affect the 'rename' functions in various ways. To rename a topic, you need all of VIEW, CHANGE and RENAME access to that topic. To alter referring topics, you need CHANGE access. See AccessControl for information on setting up access permissions.

Special considerations

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

1. When referring links are updated, the modified topics appear in WebChanges, creating the impression that editorial changes were made. This can undermine the usefulness of WebChanges.
2. Due to current limitations, fairly heavy use of rename/move/delete functions can lead to an accumulation of minor technical problems (such as broken links) and usability issues (e.g. user confusion). If rename... is used heavily, these negatives will obviously increase, in number and effect.

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

Known issues

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

The following shows some limitations of square bracket processing.

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

Reviewing and Reverting

The previous version of this documented recommended copy/paste from the raw view of a prior version to revert. This is not recommended as it fails to revert changes to the topic metadata. Note howver that no method actually reverts attachments as they are stored separately from the topics.

Foswiki's revision control saves all topic changes. To view earlier versions of a topic, click on the History link in topic actions. If you would like to revert to an earlier version or reclaim part of an earlier version, just copy from the old topic revision to the current topic revision as follows:

1. If necessary, using the History view, find the revision number you want to restore.
2. Visit the [More topic actions] page, [Restore topic] section.
3. Enter the desired revision number and click [Restore]. This action creates a new revision from the specified version.

Caution: This action does not "rewrite history". A new revision is created, and the rollback can still be reverted. If the is some highly sensitive data that must be removed from the history, this operation will not remove the information. In order to completely expunge data from history, there are several possible options:

• Move the topic to trash, and create a new version of the topic by cut/paste from the raw view of the trashed topic.
• or the site administrator can use the cmd=delRev option of the edit script to permanently remove the last revision of a topic.
• or a server admin can remove the topic.txt,v rcs file from the file system after removing the offending information from the topic.

---

Related Topics: UserDocumentationCategory, AdminDocumentationCategory

Back to top

---

Managing Webs

What are Webs?

A Foswiki site is divided into "Webs", or groups or topics - each one represents one subject, one area of collaboration. Administrators can add, rename or delete webs.
At file level, a Web is a directory located inside the data directory, with text files as topics.
A number of Webs are fixed: System for documentation, Main to store user pages and site-wide preferences, Trash for the topic recycle bin.
Other webs can be created as needed.

Create a new web

To use this form you must be administrator.

Before you begin: consider that less webs are better than more webs. Cross-linking topics is easier, and searches are faster, if there are only a few larger webs.

Name of the new web Required

Naming rule: the name must start with an upper case letter, followed by upper or lower case letters or numbers. Examples: Learn, SupDocs, KNow3

If you are creating a sub-web (a web inside a web), use the notation Existingweb.Newweb.

More info about sub-webs ...Close info

About sub-webs

You can only create (Hierarchical) sub-webs if the {EnableHierarchicalWebs} setting in configure is enabled. sub-webs are currently enabled (default) .

You might not need sub-webs. Foswiki topics already have a parent/child relationship within a web, which is shown in the breadcrumb. Try to keep the number of webs to a minimum in order to keep search and cross-referencing simple.

Summary

Enter a short description of the web. This description will be used in the SiteMap. If you are using links: write Web.TopicName instead of just TopicName for correct linking.

Additional Settings

Leave these settings as default if you do not understand what they mean.

Template web

_default _empty System

Base the new web on an existing web.

More info about template webs ...Close info

About template webs

There are two methods used to create a new web.
First you can use a specially designed TemplateWeb. This is an invisible web that begins with an underscore "_" character (for example _default). All topics in the template web will be copied into your new web.
The second method is to use an existing web as a template web. This may be useful if you already have a web that you would like to use as a starting point. Only topics that have names beginning with "Web..." (like "WebHome" or "WebNotify") are copied. In either case you will want to be sure to verify that your new web has all the custom modifications that you desire.

Notes:

• You must have ROOTCHANGE access to create a top-level web (one with no parent)
• A new web created using the _default or _empty template webs must have their access controls set before public use
• _empty is really empty (only has a WebPreferences topic); normally you want to choose _default.
• Only the person who created it has permission to change the WebPreferences in the new web

List on SiteMap page

show hide

Should the new web be listed on SiteMap? Even if hidden, the web will be linkable and accessible to users.

Include in global search and %WEBLIST%

include exclude

Specify if you want to exclude the web from global search, and from the %WEBLIST% macro used in the WebLeftBarWebsList.

Web color

Displayed on SiteMap and in the left bar (Pattern Skin).
Choose by clicking on the input field, or enter a System.StandardColors.

In-depth info on Webs

Subweb preferences are inherited

The preference settings of a subweb are inherited from the parent web and overridden locally. Preferences are ultimately inherited from the System.DefaultPreferences topic.

Example Preference Inheritance for Sandbox/TestWeb/SubWeb.SubWebTopic topic:

1. System.DefaultPreferences default settings
2. Main.SitePreferences site-wide settings inherits from and overrides settings in System.DefaultPreferences
3. Sandbox.WebPreferences inherits from and overrides settings in Main.SitePreferences
4. Sandbox/TestWeb.WebPreferences inherits from and overrides settings in Sandbox.WebPreferences
5. Sandbox/TestWeb/SubWeb.WebPreferences inherits from and overrides settings in Sandbox/TestWeb.WebPreferences
6. Sandbox/TestWeb/SubWeb.SubWebTopic inherits from and overrides settings in Sandbox/TestWeb/SubWeb.WebPreferences

Subweb navigation

The default Pattern skin indicates Subwebs by indenting them in the sidebar relative to their level in the hierarchy.

Renaming or Deleting a Web

Rename a web via the Tools section in each WebPreferences topic. You may delete a web by moving it into a Trash web.

Permissions

You may only rename a web if you have the following permissions

• You must be allowed to rename and changes topics in the web you want to rename
• You must be allowed to rename topics in the parent web of the web you want to rename
• If the web is a root web (i.e. it has no parent web) then you must have permission to both create and rename root webs. These permissions are controlled by the ALLOWROOTCHANGE preference, which can be set in Main.SitePreferences.
• If you move the web to another parent web you must be allowed to create and change topics in the new parent web. When you rename a web Foswiki will try and update all links that refer to the old web. You should note that links only get updated in topics that you are allowed to edit. If you use access rights in the Foswiki installation it is generally best to let an administrator rename webs to avoid too many broken links.

Renaming the webs in the distribution

It is possible, though not recommended, to change the names of the webs in the distribution. If you plan to rename the Main web, remember that Foswiki stores user topics in this web. That means that every WikiName signature - Main.SomeUserName - points to it and would need updating (unless the macro style %USERSWEB%.SomeUserName, is used throughout). This potentially large change can be performed automatically if you rename the web from the Tools section of WebPreferences, as described above.

If you want to rename the System or Main webs, remember they are referred to in the Foswiki configuration. You will need to change the {SystemWebName}, {UsersWebName} and/or {LocalSitePreferences} settings in the configuration using the configure interface.

Renaming the webs in the distribution is not recommended because it makes upgrades much more complicated.

Related Topics: AdminDocumentationCategory, AdminToolsCategory

Back to top

---

Manage Users

Register users on your Foswiki site; change/reset/install passwords; remove user accounts

Some of the features below may be disabled, depending on your Foswiki configuration.

Authentication and Access Control

• UserAuthentication describes your options for user authentication
• AccessControl describes how to define groups and how to restrict access to content

Register User

You don't have to have user home pages in Foswiki for Authentication to work - see UserAuthentication for details.

• UserRegistration is used when you want new users to individually register with Foswiki by filling out a form
• You can create a custom versions of System.NewUserTemplate and System.UserForm
• BulkRegistration is used by administrators to register multiple users at the same time

Change, Reset and Install Passwords

Note that the below features are only relevant when you use an internal password manager where Foswiki can set and reset passwords.

• ChangePassword is for users who can remember their password and want to change it
• ResetPassword is for users who cannot remember their password; a system generated password is e-mailed to them
• BulkResetPassword is for administrators who want to reset many passwords at once
• ChangeEmailAddress changes the hidden email address stored in the password file

Changing User Account Names

To change the user's WikiName:

• Rename the user's Foswiki homepage in the Main web, such as from JaneSmith to JaneMiller.
  • Fix backlinks in the Main web only
  • Make sure the group topics are updated (if any.)
• Edit the Main.WikiUsers topic and move the user's entry so that the list is in proper alphabetical order.
• Recreate the old topic with a pointer to the new topic, so that links in other webs work properly. Example content:
  

  %M% Jane Smith is now known as JaneMiller

If external authentication is used and you want to change the login name:

• The login name needs to be changed in the authentication server (e.g. Active Directory)
• In Foswiki's Main.WikiUsers topic, fix the mapping from login name to WikiName:
     * JaneSmith - jsmith - 13 Sep 2006
  to:
     * JaneMiller - jmiller - 13 Sep 2006

Removing User Accounts

To remove a user account (FredQuimby, who logs in as "fred"):

1. If you are using a .htpasswd file, edit the .htpasswd file to delete the line starting fred:
   • Warning: Do not use the Apache htpasswd program with .htpasswd files generated by Foswiki! htpasswd wipes out email addresses that Foswiki plants in the info fields of this file.
2. Remove the FredQuimby - fred line from the Main.WikiUsers topic
3. Remove FredQuimby from all groups and from all the ALLOWWEB/ALLOWTOPIC... declarations, if any.
   Note: If you fail to do this you risk creating a security hole, as the next user to register with the wikiname FredQuimby will inherit the old FredQuimby's permissions.
4. [optional] Delete their user topic Main.FredQuimby (including attachments, if any.)

Note: Consider leaving the user topic file in place so their past signatures and revision author entries don't end up looking like AnUncreatedTopic. If you want to make it clear the user is no longer around, replace the topic content with a note to that effect. The existence of the UserName topic should also prevent that user name from being re-used, sealing the potential security hole regarding inherited permissions..

Other registration controls

Registration process is configured at https://wiki.bacchus-env.eu/bin/configure#Registration$SecurityAndAuthentication

Confirmation

Registration can be configured to require a confirmation via the registered email address:

• An email is sent to the email address entered by the new user with a confirmation code.
• The user must enter the confirmation code into a dialog on the wiki to confirm the registration.
• The pending registration lifetime defaults to 6 hours. If the user does not confirm within that time, the pending registration will be removed.

Registration Email Requirements

Normally Foswiki does not require unique email addresses. Multiple users can register using the same email address. Enable the setting {Register}{UniqueEmail} to prevent use of the same email by multiple users.

Normally any email domain can be used for registration. Set the expert setting {Register}{EmailFilter} to restrict the domains usable for registration. See the configure help for more details.

See the configure help at https://wiki.bacchus-env.eu/bin/configure#Registration$SecurityAndAuthentication for more details.

Customizing registration Emails.

Foswiki's Registration can send 3 emails whose output is governed by templates:

1. User registration confirmation - templates/registerconfirm.tmpl
2. User registration notification - templates/registernotify.tmpl
3. Email to notify the Wiki admin of registration - templates/registernotifyadmin.tmpl

As these are SkinTemplates, they can be customized and selected using the SKIN path setting. Because there are default .tmpl files in the templates dir, this cannot use Template topics.

These template files have a specific format that matches the raw format of emails sent via SMTP, so be careful and test your changes. It is easiest to start by copying the default templates:

cd templates
cp registernotify.tmpl registernotify.myskin.tmpl
cp registerconfirm.tmpl registerconfirm.myskin.tmpl
cp registernotifyadmin.tmpl registernotifyadmin.myskin.tmpl

then add myskin to the beginning of the SKIN setting in Main.SitePreferences.

From this point on, your myskin templates will be used for the registration emails.

To make it possible for users to modify the email contents, you could use a parameterized %INCLUDE% statement in your customized version, eg:

From: %WIKIWEBMASTERNAME% <%WIKIWEBMASTER%>
To: %FIRSTLASTNAME% <%EMAILADDRESS%>
Subject: %MAKETEXT{
   "[_1] - Registration for [_2] ([_3])"
   args="%WIKITOOLNAME%, %WIKINAME%, %EMAILADDRESS%"
}%
MIME-Version: 1.0
Content-Type: text/plain; charset=%CHARSET%
Content-Transfer-Encoding: 8bit

%INCLUDE{
    "%USERSWEB%.RegisterNotifyEmail"
    WIKINAME="%WIKINAME%"
    FIRSTLASTNAME="%FIRSTLASTNAME%"
    EMAILADDRESS="%EMAILADDRESS%"
}%

Note the use of %WIKINAME%, %FIRSTLASTNAME%, %EMAILADDRESS% passed in from the INCLUDE so that the topic below is similar to the original template

and then create a topic Main.RegisterNotifyEmail:

Welcome to %WIKITOOLNAME%.

%MAKETEXT{"Your personal [_1] topic is located at [_2]. You can customize it as you like:" args="%WIKITOOLNAME%, %SCRIPTURL{"view"}%/%USERSWEB%/%WIKINAME%"}%

   * %MAKETEXT{"Some people turn it into a personal portal with favorite links, what they work on, what help they'd like, etc."}%
   * %MAKETEXT{"Some add schedule information and vacation notice."}%

Regards
%WIKIWEBMASTERNAME%
Your Wiki Admin


%MAKETEXT{"Note:"}%
   2 %MAKETEXT{"You can change your password at via [_1]" args="%SCRIPTURL{"view"}%/%SYSTEMWEB%/ChangePassword"}%
   3 %MAKETEXT{"If you haven't set a password yet or you want to reset it, go to: [_1]" args="%SCRIPTURL{"view"}%/%SYSTEMWEB%/ResetPassword"}%

%MAKETEXT{"Submitted content:"}%
%FORMDATA%

Remember to secure the topic appropriately to prevent attackers from getting emailed sensitive passwords.

Manually approving registrations

In some installations, registration requests should be forwarded to an administrator for approval. This can be accomplished relatively easily by modifying the registration email template to send the "Verification" request to an approval address instead of returning to the user.

This will be accomplished by creating a new skin to override the templates used in the registration process. By creating a new skin, you avoid modifying any files that are replaced when Foswiki is upgraded.

Summary of steps:

1. Name a new skin for the registration email: ex. approval
2. Copy and modify the registration confirmation - templates/registerconfirm.tmpl to templates/registerconfirm.approval.tmpl
3. optional Copy and modify the registration notification - templates/registernotify.tmpl to templates/registernotify.approval.tmpl
4. optional Copy and modify the the Wiki admin notification - templates/registernotifyadmin.tmpl to templates/registernotifyadmin.approval.tmpl
5. Create a new template to override the registration response to the user: templates/messages.approval.tmpl
6. Edit your Main.SitePreferences topic and enable the new skin, and set the %REGISTRATIONAPPROVAL% and %REGISTRATIONAPPROVALEMAIL% variables
7. Enable confirmation email messages using https://wiki.bacchus-env.eu/bin/configure#Registration$SecurityAndAuthentication to enable {Register}{NeedVerification}
8. Also, set the {Register}{ExpireAfter} setting to a value long enough to ensure that the approver has a chance to process the request before it expires.

The following examples assume that Step 1 chose approval as the skin name. And the registration notifications sent to the user and Wiki admin do not need to be modified.

Registration confirmation template templates/registerconfirm.approval.tmpl (Step 2)

Copy the template: cp templates/registerconfirm.tmpl templates/registerconfirm.approval.tmpl and edit to appear as follows. This email message will be sent to the address responsible for approving registrations.

%{ This is a default template }%From: %WIKIWEBMASTERNAME% <%WIKIWEBMASTER%>
To: %REGISTRATIONAPPROVAL% <%REGISTRATIONAPPROVALEMAIL%>
CC: %WIKIWEBMASTERNAME% <%WIKIWEBMASTER%>
Subject: Registration request by %FIRSTLASTNAME% <%EMAILADDRESS%>
MIME-Version: 1.0
Content-Type: text/plain; charset=%CHARSET%
Content-Transfer-Encoding: 8bit

Registration request by %FIRSTLASTNAME% <%EMAILADDRESS%> for %WIKITOOLNAME%
needs your approval.
Verification code %VERIFICATIONCODE%

%SCRIPTURL{"register"}%?action=verify;code=%VERIFICATIONCODE%

Note The line following the Content-Transfer must be completely empty, with no spaces, or the email wil fail.

Wiki Admin notification templates/registernotifyadmin.approval.tmpl (Step 4)

This is sent to the Admin upon successful registration. This message is extended to provide confirmation to the approver that the registration succeeded.

%{ This is a default template }%From: %WIKIWEBMASTERNAME% <%WIKIWEBMASTER%>
To: %WIKIWEBMASTERNAME% <%WIKIWEBMASTER%>
Cc: %REGISTRATIONAPPROVAL% <%REGISTRATIONAPPROVALEMAIL%>
Subject: %MAKETEXT{"[_1] - Registration for [_2] ([_3])" args="%WIKITOOLNAME%, %WIKINAME%, %EMAILADDRESS%"}%

MIME-Version: 1.0
Content-Type: text/plain; charset=%CHARSET%
Content-Transfer-Encoding: 8bit

%MAKETEXT{"This is an automated e-mail notification of user registration in [_1]." args="%WIKITOOLNAME%"}%

%MAKETEXT{"[_1] has been approved and registered with e-mail [_2]" args="%WIKINAME%, %EMAILADDRESS%"}%

%MAKETEXT{"Submitted content:"}%

%FORMDATA%

%MAKETEXT{"Saved to:"}%

%SCRIPTURL{"view"}%/%USERSWEB%/%WIKINAME%

Registration response message templates/messages.approval.tmpl (Step 5)

Create a new template: templates/messages.approval.tmpl This template will override one message from the large collection of messages in templates/messages.tmpl

This "confirm" message will be returned to the user when they submit the registration request.

%TMPL:INCLUDE{"messages"}%
%TMPL:DEF{"confirm"}%
---+++ %MAKETEXT{"Thank you for registering"}%

Your request has been sent to %REGISTRATIONAPPROVAL% <%REGISTRATIONAPPROVALEMAIL%> who will normally approve your
registration within 1-2 working days.

Return to %USERSWEB%.%HOMETOPIC%
%TMPL:END%

Site preferences Main.SitePreferences (Step 6)

Edit your Main.SitePreferences topic and enable the new skin, and set the %REGISTRATIONAPPROVAL% and %REGISTRATIONAPPROVALEMAIL% variables. (Do not include the # shown in the below example.)

   * #Set SKIN=approval,pattern
   * #Set REGISTRATIONAPPROVAL=Registraions
   * #Set REGISTRATIONAPPROVALEMAIL=registrations@mycompany.com

Note Be sure to add the REGISTRATIONAPPROVAL and REGISTRATIONAPPROVALEMAIL to the Set FINALPREFERENCES line.

Edit the Registration Configuration (Steps 7-8)

{Register}{NeedVerification}

This checkbox should be enabled in the "Security and Authentication" -> "Registration" tab.

{Register}{ExpireAfter}

Set to a value that is > than the longest delay expected for approval. For ex. a "Holiday weekend" - 3-day lifetime would require 259200 seconds.

Set the pending registration timeout, in seconds. The pending registration will be cleared after this amount of time. The default is 6 hours (21600 seconds). This is only used if {Register}{NeedVerification} is enabled.

Note By default, registration expiry is done "on the fly" during the registration process. For best performance, you can set {Register}{ExpireAfter} to a negative number, which will mean that Foswiki won't try to clean up expired registrations durning registration. Instead you should use a cron job to clean up expired sessions. The standard maintenance cron script tools/tick_foswiki.pl includes this function.

Note that if you are using registration approval by 3rd party reviewers, this timer should most likely be significantly increased. 24 hours = 86400, 3 days = 259200.

Pending registration requests are stored in the {WorkingDir}/registration_approvals directory.

---

Related Topics: AdminDocumentationCategory

Back to top

---

Appendix A: Foswiki Development Time-line

Foswiki Release 1.1.9 - 19 Nov 2013

Foswiki 1.1.9 was built 18 Nov 2013. It is a release that contains 43 fixes and 4 enhancements.

Foswiki Release 1.1.8 - 28 Feb 2013

Foswiki 1.1.8 was built 28 Feb 2013. It is a release that fixes CVE-2013-1666. It contains 4 fixes.

Foswiki Release 1.1.7 - 01 Feb 2013

Foswiki 1.1.7 was built 01 Feb 2013. It is a release that fixes CVE-2012-6329 and CVE-2012-6330. It contains 20 fixes and 4 enhancements.

Foswiki Release 1.1.6 - 02 Dec 2012

Foswiki 1.1.6 was built 02 Dec 2012. It is a release that fixes some important issues including some minor security related issues. It contains 94 fixes and 27 enhancements.

Foswiki Release 1.1.5 - 10 Apr 2012

Foswiki 1.1.5 was built 10 Apr 2012. It is a release that fixes some very important issues including some security related issues. It contains 100 fixes and 20 enhancements.

Foswiki Release 1.1.4 - 20 Dec 2011

Foswiki 1.1.4 was built 20 Dec 2011. It is a release that fixes some very important including some security related issues. It contains 143 fixes and 27 enhancements. jQuery has been updated to 1.7.1.

Foswiki Release 1.1.3 - 16 Apr 2011

Foswiki 1.1.3 was built 16 Apr 2011. It is a release that fixes more than 150 bugs. jQuery has been updated to 1.4.3. The default PatternSkin has some usability improvements.

Foswiki Release 1.1.2 - 09 Nov 2010

Foswiki 1.1.2 was built 09 Nov 2010. It is a release that fixes some very important bugs incl. a security related bug. Installations running 1.1.0 and 1.1.1 should be upgraded to 1.1.2

Foswiki Release 1.1.1 - 25 Oct 2010

It is a release that fixes some important bugs that were introduced in 1.1.0. It is highly recommended that all running 1.1.0 upgrade to 1.1.1.

Foswiki Release 1.1.0 - 04 Oct 2010

Foswiki 1.1.0 was built 04 Oct 2010. It is a release with more than 270 bug fixes relative to 1.0.10 and more than 680 bug fixes relative to 1.0.0.

This release adds more than 100 enhancements. Foswiki 1.1.0 introduces jQuery Javascript user interface framework, improved topic history display, new QUERY and FORMAT macros, better user interfaces for group management, much improved WYSIWYG editor, facelift of the default skin, much improved configure tool, and much more.

Foswiki 1.1 has many improvements that end-users as well as administrators will appreciate. In addition Foswiki 1.1 comes with a lot of "under the hood" improvements to the core code, with the goal of making it easier to plug in work from other projects, such as jQuery, KinoSearch, Solr and others. Work has been made to improve the definition of internal APIs to allow other not-yet-written modules, such as store implementations. Most of these modifications should be invisible to the end user and admin, but are important to position Foswiki for the next generation of plugins. Here is a list of the most important enhancements in Foswiki 1.1.0

Foswiki Hall of Fame

The proud, free, independent Foswiki community as of the release of 1.1.0 (highlights - for full list see Foswiki:Tasks.HallOfFame)

• Top core bug fixers (10 or more fixes): Foswiki:Main.CrawfordCurrie, Foswiki:Main.SvenDowideit, Foswiki:Main.KennethLavrsen, Foswiki:Main.ArthurClemens, Foswiki:Main.GeorgeClark, Foswiki:Main.OlivierRaginel, Foswiki:Main.MichaelDaum, Foswiki:Main.WillNorris, Foswiki:Main.MichaelTempest, Foswiki:Main.GilmarSantosJr, Foswiki:Main.PaulHarvey, Foswiki:Main.AndrewJones, Foswiki:Main.AndreUlrich, Foswiki:Main.EugenMayer
• Top contributors in general on SVN (100 or more checkins): Foswiki:Main.SvenDowideit, Foswiki:Main.KennethLavrsen, Foswiki:Main.CrawfordCurrie, Foswiki:Main.ArthurClemens, Foswiki:Main.MichaelDaum, Foswiki:Main.WillNorris, Foswiki:Main.GeorgeClark, Foswiki:Main.OlivierRaginel, Foswiki:Main.PaulHarvey, Foswiki:Main.MichaelTempest, Foswiki:Main.EugenMayer, Foswiki:Main.AndrewJones, Foswiki:Main.GilmarSantosJr, Foswiki:Main.OliverKrueger
• Development Infrastructure: Foswiki:Main.SvenDowideit, Foswiki:Main.EugenMayer, Foswiki:Main.KoenMartens, Foswiki:Main.CrawfordCurrie, Foswiki:Main.KwangErnLiew, Foswiki:Main.OliverKrueger, Foswiki:Main.OlivierRaginel, Foswiki:Main.WillNorris, Foswiki:Main.ColasNahaboo, Foswiki:Main.KennethLavrsen

Foswiki Release 1.0.10 - 09 Sep 2010

Foswiki 1.0.10 was built 09 Sep 2010 as a patch release with more than 410 bug fixes relative to 1.0.0.

This release is expected to be the final bug fixing release for foswiki 1.0, and wraps up about 70 fixes found since 1.0.9.

Importantly, this release fixes an issue running configure on Perl 5.12, improves compatibility with proxy and enterprise search indexers, and updates the shipped plugins to the latest versions.

It resolves a number of issues for running foswiki on MS Windows.

Foswiki Release 1.0.9 - 17 Jan 2010

Foswiki 1.0.9 was built 17 Jan 2010. It is a patch release with more than 320 bug fixes relative to 1.0.0 and several enhancements. This release fixes many bugs in the Wysiwyg editor, bugs related to more advanced wiki applications and bugs in the Plugin API. It contains several bug fixes and enhancements related to security and spam fighting.

Foswiki Release 1.0.8 - 29 Nov 2009

Foswiki 1.0.8 was built 29 Nov 2009. It is a patch release with more than 280 bug fixes relative to 1.0.0 and some enhancements. This release fixes a short list of quite annoying old bugs incl a bug that prevented efficient use of MailerContrib for producing newsletters. The Wysiwyg editor has been upgraded with the latest Tiny MCE editor release 3.2.7.

Foswiki Release 1.0.7 - 20 Sep 2009

More than 30 new bug fixes and some enhancements.

The Wysiwyg editor has been upgraded to using Tiny MCE editor version 3.2.2 which solves many editor related bugs. The pickaxe icon has been replaced by a "Wiki Text" button as the pickaxe was hard to guess the function of.

Several bugs fixed related to the Cross-Site Request Forgery feature.

TablePlugin sorts numbers and dates better

EditTablePlugin handles SpreadSheetPlugin in footer rows correctly

Fixed a problem where Windows installations of Foswiki would create new users with non-working passwords

"Managing webs" feature redesigned for better usability

Foswiki Release 1.0.6 - 21 Jun 2009

More than 40 bugs fixed and several small enhancements.

Major security enhancement against Cross-Site Request Forgery

A central translation framework got introduced. Foswiki is already available in 20 major languages and dialects. The new translation framework will ease the translation process by allowing contributions from users.

Foswiki Release 1.0.5 - 25 Apr 2009

Additional 20 bugs fixed.

Some few minor enhancements

New security features added

Upgrade package for 1.0.5 is relative to 1.0.0.

Foswiki Release 1.0.4 - 19 Mar 2009

Small update of 1.0.3 with 33 more bugs fixed incl some severe bugs in EditTablePlugin.

Upgrade package for 1.0.4 is relative to 1.0.0.

The number of bugfixes in 1.0.4 relative to 1.0.0 is more than 100 + some bugs that were introduced and fixed in the not published 1.0.1-1.0.3. There are 5 minor enhancements.

Foswiki Release 1.0.3 - 28 Feb 2009

Both 1.0.1 ,1.0.2, and 1.0.3 were not published because they did not pass the final quality control. Another handful of bugs were fixed.

Upgrade package for 1.0.3 is relative to 1.0.0.

Foswiki Release 1.0.2 - 26 Feb 2009

Same as 1.0.1 but with a handful of additional bug fixes.

Upgrade package for 1.0.2 is relative to 1.0.0 since 1.0.1 was never published on the Foswiki website.

Foswiki Release 1.0.1 - 24 Feb 2009

Patch release containing more than 70 bug fixes and some user interface improvements of configure. Due to a bug (Item1126) the development team decide not to publish this release but instead release 1.0.2 a few days later

Bug fix highlights:

• Fixed some bugs related to expired sessions and date in session cookies.
• Fixed a number of bugs in configure related to installation of extensions
• Fixed a bug that prevented proper operation with https
• Fixed a bug related to VIEW_TEMPLATE and preview
• Enhanced the user interface of configure

Foswiki Release 1.0.0 - 09 Jan 2009

Foswiki is the old TWiki project under a new name. Restrictions on the use of the TWiki brand resulted in many of its developers continuing the project under the new Foswiki name. Foswiki is backwards compatible with all content from older TWiki installations. Foswiki 1.0.0 ships with a TWikiCompatibilityPlugin installed and activated by default, thus enabling most extensions made for TWiki to work under Foswiki.

New features and enhancements

• Foswiki 1.0.0 is built on a new platform called Foswiki Stand Alone which adds support for FastCGI and enables more optimized functionality in mod_perl and other similar runtime environments. Foswiki Stand Alone also enables future features such as running Foswiki by itself without a separate web server (for example, from a stand alone memory key). You can ensure your applications and plugins will work properly on the new platform (and thus with any future capabilities dependent on the new architecture) by testing them out now with Foswiki 1.0.0.
• A TWikiCompatibilityPlugin has been created that enables most extensions made for TWiki to work under Foswiki, and to support seamless migrations from TWiki to Foswiki.
• The PatternSkin has been given a facelift: The PatternSkin topic offers a choice of multiple themes, the sidebar can be placed either on the left or right, a frame can be added around the main content area, and a TWiki theme is available to make it easier for those upgrading from TWiki (dimensions such as the top bar size match the dimensions in the TWiki PatternSkin).
• The "Advanced Search" page now supports a query-based search.
• A new section type, "expandvariables", adds better control over macro expansion in topic templates. You can now create template topics with sections where all macros contained within the sections are expanded.
• A "Copy topic" feature is now present in the "More topic actions" tools.
• IF conditions has been expanded with an "isempty" test condition.
• viewfile script can be used as a webserver ErrorDocument enabling both more secure attachments and user focused error dialogs.

Security Updates

Foswiki is much more secure than TWiki 4.2.4.

• Foswiki 1.0.0 has secured by default the powerful but also vulnerable URLPARAM macro against cross site scripting (XSS) attacks. URLPARAM now by default encodes a short list of unsafe characters '"<>% which eliminates most XSS possibilities encountered with URLPARAM. This protects all topics using the URLPARAM macro without requiring any changes to them.
• Functions QUERYPARAMS, ORIGURL (skin macro) are secured against XSS attacks. QUERYPARAMS, like URLPARAM, is now encoded with the new, safe encoding.
• The print preview link is no longer vulnerable to XSS attacks.
• Additional security fixes have been made, based on security audits performed by the Foswiki team. Sensitive data from the topic text and web client requests are validated for safety.

Terminology changes in Foswiki

As part of the first Foswiki product release, various topics and terms were changed to avoid using the TWiki brand name and to more accurately reflect their purpose, including the following:

• The TWiki web is now called System, as it contains configuration information for the entire Foswiki installation. The TWikiCompatibilityPlugin provides backwards compatible support for references to the TWiki web, in order to facilitate migrations from TWiki to Foswiki.
• The %TWIKIWEB% and %MAINWEB% variables are now called %SYSTEMWEB% and %USERSWEB%
• Topics in the Foswiki distribution have been renamed to eliminate the TWiki word and to make the titles more readable (for example, Plugins, Skins, and so forth).
• All templates, CSS and Javascript names have been changed from twikiXxxxx to foswikiXxxxx
• Key terminology changes:

  TWiki term	Foswiki term
  TWiki variable	Macro
  preference(s) variable	preference setting, or macro when referring to expansion of same
  TWiki form	Data form
  TWiki Plugin	Plugin
  TWiki Template	Skin Template
  Topic Template	Template Topic
  TWiki Markup Language (TML)	Topic Markup Language (TML)
  TWiki Application	Wiki Application

TWiki Release 4.2.1 (Freetown) released 22 Jan 2008

Patch release following the 4.2.0

New Features and Enhancements of TWiki Release 4.2

• Easier Installation and Upgrade
  • New Internal Admin Login feature
  • The Main.WikiUsers topic is no longer distributed as a default topic in Main web
  • A new directory working which per default is located in the TWiki root which contains registration_approvals, tmp, and work_areas
  • Configure can now authenticate when connecting to local plugins repository.

• Usability Enhancements
  • New WYSIWYG editor based on TinyMCE replaces the Kupu based editor
  • New "Restore topic" feature has been added to the More Topic Actions menu to easily restore an older version of a topic

• Application Platform Enhancements
  • Enhancements to IF: allows, ingroup, istopic, and isweb

• Search Enhancements
  • New query search mode supports SQL-style queries over form fields and other meta-data

• Skins and Templates Enhancements
  • The PatternSkin which is the default skin for TWiki has got a face lift
  • The default templates have been heavily refactored to make it easier to create skins reusing the default skin.

• Miscellaneous Feature Enhancements
  • Many new functions in the API for plugin developers
  • Table of Content (TOC) feature enhanced
  • re-architected Pluggable user mapping (between login name and WikiName) to integrate with alternative authentication and Management schemes
  • Topic based User management has been extracted into a separately update-able package (WikiUsersContrib)

• Enhancements of Pre-installed Plugins
  • CommentPlugin: New templatetopic parameter to point to custom comment template topic
  • EditTablePlugin: Move and delete rows
  • MailerContrib: Allow Exclusion Of Webs
  • SpreadSheetPlugin: 6 new math formulas; formula to format time diff

• Bug Fixes
  • More than 300 bugs fixes since 4.1.2

Hall of Fame of TWiki Release 4.2

Many people have been involved in creating TWiki 4.2. Special thanks go to the most active contributors in the following areas:

• Release management led by Foswiki:Main.KennethLavrsen, ably assisted by Foswiki:Main.SvenDowideit
• Design and development driven by Foswiki:Main.CrawfordCurrie, Foswiki:Main.ArthurClemens, Foswiki:Main.KennethLavrsen and Foswiki:Main.SvenDowideit
• Testing driven by Foswiki:Main.KennethLavrsen

Many thanks also to the contributors in the following areas:

• Sponsor and facilitator: TWiki:Main.PeterThoeny
• Testing and bug fixing: Foswiki:Main.KennethLavrsen, Foswiki:Main.CrawfordCurrie, Foswiki:Main.ArthurClemens, Foswiki:Main.SvenDowideit, Foswiki:Main.SteffenPoulsen, Foswiki:Main.MichaelDaum, TWiki:Main.PeterThoeny, TWiki:Main.RichardDonkin
• Spec and code: Foswiki:Main.CrawfordCurrie (2323), Foswiki:Main.ArthurClemens (566), Foswiki:Main.SvenDowideit (507), TWiki:Main.PeterThoeny (83), Foswiki:Main.KennethLavrsen (73), Foswiki:Main.SteffenPoulsen (72), TWiki:Main.AntonioTerceiro (63) - ( 3857 changes by 20 authors )
• Templates and skins: Foswiki:Main.ArthurClemens (587), Foswiki:Main.CrawfordCurrie (130), Foswiki:Main.AndreUlrich (73), Foswiki:Main.SvenDowideit (44) - ( 869 changes by 12 authors )
• Documentation: Foswiki:Main.ArthurClemens (460), Foswiki:Main.CrawfordCurrie (377), TWiki:Main.PeterThoeny (233), Foswiki:Main.AndreUlrich (157), Foswiki:Main.SvenDowideit (118), Foswiki:Main.KennethLavrsen (68) - ( 1450 changes by 14 authors )
• Release package builds: Foswiki:Main.SvenDowideit
• Usability: Foswiki:Main.CarloSchulz, Foswiki:Main.ArthurClemens
• Translations: Coordinated by TWiki:Main.AntonioTerceiro
  • Bulgarian: TWiki:Main.KrassimirBerov
  • Danish: Foswiki:Main.SteffenPoulsen
  • Dutch: Foswiki:Main.ArthurClemens
  • Finnish: TWiki:Main.HeikkiToivonen
  • French: TWiki:Main.BenVoui
  • German: Foswiki:Main.OliverKrueger, Foswiki:Main.AndreUlrich
  • Italian: TWiki:Main.MassimoMancini
  • Portuguese: TWiki:Main.CarlinhosCecconi
  • Simplified Chinese: TWiki:Main.CheDong
  • Swedish: TWiki:Main.ErikAman
  • Traditional Chinese: TWiki:Main.CheDong
  • Ukrainian: TWiki:Main.SerhijDubyk
• Marketing: TWiki:Main.RodBeckstrom, TWiki:Main.PeterThoeny, Foswiki:Main.MichaelCorbett, Foswiki:Main.KoenMartens
• Public relations: TWiki:Main.PeterThoeny, Foswiki:Main.MichaelCorbett
• Meetups: TWiki:Main.AmirShobeiri
• TWiki.org wiki champions: TWiki:Main.PeterThoeny, Foswiki:Main.ArthurClemens, Foswiki:Main.CrawfordCurrie, Foswiki:Main.KennethLavrsen, Foswiki:Main.SvenDowideit, Foswiki:Main.MichaelDaum, Foswiki:Main.CarloSchulz, Foswiki:Main.StephaneLenclud, TWiki:Main.RichardDonkin, Foswiki:Main.KoenMartens
• Customer support: TWiki:Main.PeterThoeny, Foswiki:Main.ArthurClemens, Foswiki:Main.CrawfordCurrie, Foswiki:Main.SvenDowideit, TWiki:Main.HaraldJoerg
• System administration: Foswiki:Main.SvenDowideit, TWiki:Main.PeterThoeny, Foswiki:Main.CrawfordCurrie

If you find an omission please fix it at TWiki:System.ReleaseHistory. For the full list of contributors see ProjectContributor.

Note: Order of contributors under "Spec and code", "Templates and skins" and "Documentation" is based on number of SVN file changes for core and default extensions from March 2007 (svn rev:13046) to Jan 2008 (svn rev:16210). (Details at TWikibug:TWiki420SvnLog). Order of contributors under "Testing and bug fixing" is based on Bugs web statistics from 2007-03 to 2007-12. Order of contributors under "TWiki.org wiki champions" and "Customer support" is based on TWiki.org web statistics from 2007-02 to 2007-12.

TWiki Release 4.1 (Edinburgh), 16 Jan 2007

New Features and Enhancements of TWiki Release 4.1

• Easier Installation and Upgrade
  • Plugins can now be installed from the configure script.
  • The loading of plugin preferences settings has been moved earlier in the preferences evaluation order so that plugin settings can be redefined in Main.SitePreferences, WebPreferences and in topics. To make TWiki upgrades easier, it is recommended to set the plugin settings in Main.SitePreferences, and not to customize the settings in the plugin topic. For example, to change the TEMPLATES setting of the CommentPlugin, create a new COMMENTPLUGIN_TEMPLATES setting in Main.SitePreferences.
  • Plugin settings can now be defined in configure instead of in the plugin topic (requires that the individual plugin has implemented this). TWiki performs slightly better by not looking for preferences settings in plugin topics.
  • Configure no longer shows many unnecessary errors when run first time.
  • The webmaster email address is now defined in configure instead of TWikiPreferences.
  • Default file access rights in the distribution package have been changed to be more universally defined and in line with the default access rights for new topics.

• Usability Enhancements
  • Redesigned result page when typing incomplete topic name into the Jump box, so that it is possible to quickly navigate to a topic, also in a very large TWiki installation. For example, "I know there is a topic about Ajax somewhere in the Eng web. OK, let my type Eng.ajax into the Jump box... Here we go, the third link is the AjaxCookbook I was looking for."
  • Many user documentation improvements.
  • URL parameters maintained in Table of Contents links so you can stay in a temporary skin (e.g. print) and keep URLPARAM values when you click the TOC links
  • Attachment tables now sorted alphabetically.
  • Better printing of tables and verbatim text in PatternSkin.

• Application Platform Enhancements
  • Auto-incremented topic name on save with AUTOINC<n> in topic name; used by TWiki applications to create topic based database records.
  • The edit and save scripts support a redirectto parameter to redirect to a topic or a URL; for security, redirect to URL needs to be enabled with a {AllowRedirectUrl} configure flag.
  • CommentPlugin supports the redirectto parameter to redirect to a URL or link to TWiki topic after submitting comment.
  • The topic URL parameter also respects the {AllowRedirectUrl} configure flag so redirects to URLs can be disabled which could be abused for phishing attacks.
  • The view script supports a section URL parameter to view just a named section within a topic. Useful for simple AJAX type applications.
  • New plugin handler for content move.
  • Enhancements for Ajax based applications with Foswiki:Extensions/YahooUserInterfaceContrib and Foswiki:Extensions.TWikiAjaxContrib (available at twiki.org).

• Search Enhancements
  • METASEARCH handles a format parameter like SEARCH.
  • Topic not found / WebTopicViewTemplate search now case insensitive.
  • FormattedSearch header supporting $nop, $quot, $percnt, $dollar.
  • Add search by createdate option to SEARCH.
  • New newline option for SEARCH to protect e.g. formfields from being altered during rendering in SEARCH.

• Skins and Templates Enhancements
  • Support for templates to have text rendering affecting aspect outside of textarea.
  • Pattern skin dependence on TwistyPlugin instead of TwistyContrib (performance improvement.)
  • Don't strip newlines from the front of TMPL:DEFs.

• Miscellaneous Feature Enhancements
  • Change in WikiWord definition: Numbers are treated as lower case letters, e.g. Y2K is now a WikiWord.
  • Configurable template load path. Advanced feature for those that work with customized templates.
  • Added %VBAR% to TWikiPreferences for vertical bar symbol.
  • On topic creation, force initial letter of topic name to be upper case.
  • Allow date format in form fields.
  • Enhance REVINFO{} variable with same date qualifiers as GMTIME{}.
  • WebTopicCreator - adding ability to select a template from any topic name ending in ...Template
  • Functionality of Foswiki:Extensions.DateFieldPlugin merged into core

• Enhancements of Pre-installed Plugins
  • CommentPlugin: Supports removal of comment prompt after a comment is made.
  • EditTablePlugin: Default date format based on JSCalendarContrib instead of plugin topic.
  • InterwikiPlugin: Supports custom link formats.
  • SlideShowPlugin: Preserves URL parameters in slideshow
  • SpreadSheetPlugin: New functions $LISTRAND(), $LISTSHUFFLE(), $LISTTRUNCATE().
  • TablePlugin: New attribute cellborder.
  • TablePlugin: Highlight the sorted column with custom colors; includes also a general cosmetic update of default colors.
  • TablePlugin: Support for initsort on more than one table. A table with the initsort option is initsorted UNLESS it is sorted by clicking on a column header. If you click on a header of another table all other tables goes back to the default sort defined by initsort or not sorted if no initsort, and the new table is sorted based on the user clicking on a table header.

• Bugfixes
  • More than 200 bugs fixed since 4.0.5

Hall of Fame of TWiki Release 4.1

Although many more people have been involved in creating TWiki-4.1, special thanks go to the most active contributors in the following areas:

• Sponsor and facilitator: TWiki:Main.PeterThoeny
• Process improvement: Foswiki:Main.KennethLavrsen, TWiki:Main.PeterThoeny, Foswiki:Main.SteffenPoulsen, Foswiki:Main.CrawfordCurrie
• Release management: Foswiki:Main.KennethLavrsen
• Spec, code, testing: Foswiki:Main.CrawfordCurrie, Foswiki:Main.ArthurClemens, Foswiki:Main.SteffenPoulsen, TWiki:Main.PeterThoeny, TWiki:Main.ThomasWeigert, Foswiki:Main.KennethLavrsen, Foswiki:Main.SvenDowideit, TWiki:Main.HaraldJoerg, Foswiki:Main.MichaelDaum, TWiki:Main.MeredithLesly, Foswiki:Main.WillNorris, TWiki:Main.RafaelAlvarez, TWiki:Main.AntonioTerceiro
• Templates and skins: Foswiki:Main.ArthurClemens, Foswiki:Main.MichaelDaum, Foswiki:Main.SvenDowideit
• Documentation: TWiki:Main.PeterThoeny, Foswiki:Main.CrawfordCurrie, Foswiki:Main.ArthurClemens, Foswiki:Main.SteffenPoulsen, Foswiki:Main.KennethLavrsen
• Translations: Coordinated by TWiki:Main.AntonioTerceiro
  • Chinese: TWiki:Main.CheDong
  • Czech: TWiki:Main.IvanKuncl
  • Danish: Foswiki:Main.SteffenPoulsen
  • Dutch: Foswiki:Main.ArthurClemens
  • French: TWiki:Main.BenVoui
  • German: Foswiki:Main.AndreUlrich
  • Italian: TWiki:Main.MassimoMancini
  • Polish: TWiki:Main.ZbigniewKulesza
  • Portuguese: TWiki:Main.AntonioTerceiro, TWiki:Main.CarlinhosCecconi
  • Russian: TWiki:Main.AndreyTkachenko, TWiki:Main.SergejZnamenskij, TWiki:Main.SergeyJSinx, TWiki:Main.AlexTananaev
  • Spanish: Foswiki:Main.WillNorris, TWiki:Main.MiguelABayona
  • Swedish: TWiki:Main.ErikAman
• Public relations: TWiki:Main.PeterThoeny, TWiki:Main.TomTansy
• TWiki.org wiki champions: TWiki:Main.PeterThoeny, Foswiki:Main.CrawfordCurrie, Foswiki:Main.KennethLavrsen, Foswiki:Main.SteffenPoulsen, Foswiki:Main.ArthurClemens, TWiki:Main.ThomasWeigert, Foswiki:Main.MichaelDaum
• Customer support: TWiki:Main.PeterThoeny, Foswiki:Main.CrawfordCurrie, Foswiki:Main.ArthurClemens, Foswiki:Main.SteffenPoulsen, TWiki:Main.SteveStark, Foswiki:Main.MichaelDaum
• System administration: Foswiki:Main.SvenDowideit, TWiki:Main.PeterThoeny, Foswiki:Main.CrawfordCurrie

If you find an omission please fix it at TWiki:System.ReleaseHistory. For the full list of contributors see ProjectContributor.

Note: Sequence of contributors under "Spec, code, testing", "Templates and skins" and "Documentation" is based on number of SVN check-ins for core and default extensions from 2006-02 to 2006-12. Sequence of contributors under "TWiki.org wiki champions" and "Customer support" is based on TWiki.org web statistics from 2006-02 to 2006-12.

See more details on the TWiki 4.1 release at TWikiReleaseNotes04x01.

TWiki Release 4.0.0 (Dakar), 01 Feb 2006

Major New Features

• Much simpler install and configuration
• Integrated session support
• Webserver-independent login/logout
• Security sandbox blocking exploits for remote command execution on the server
• Edit conflict resolution with automatic merge
• Multilingual UI
• E-mail confirmations for registration
• WYSIWYG editor (beta)
• Hierarchical sub-webs (beta)

Many, many people worked on TWiki-4.0.0. The credits in the table below only list the people who worked on individual enhancements. If you find an omission please fix it at TWiki:System.ReleaseHistory. There were many other contributors; for a full list, visit ProjectContributor.

Most of the redesign, refactoring and new documentation work in Dakar release was done by Crawford Currie. Michael Sparks provided ideas and proof of concept for several improvements. Other people who gave large amounts of their time and patience to less sexy aspects of the work, such as testing, infrastructure and documentation, are AntonAylward, KennethLavrsen, LynnwoodBrown, MichaelDaum, Peter Thoeny, SteffenPoulsen, Sven Dowideit, WillNorris.

Installation & configuration	Contributor
Much simpler install and configuration	Crawford Currie, LynnwoodBrown, ArthurClemens
mod_perl safe code for better performance	Crawford Currie
Security
Security sandbox blocking exploits for remote command execution on the server	Florian Weimer, Crawford Currie, Sven Dowideit
Reworked access permission model	Crawford Currie
Internationalization & localization
User Interface Internationalisation	AntonioTerceiro
Chinese translation	CheDong
Danish translation	SteffenPoulsen
Dutch translation	ArthurClemens
French translation	BenVoui
German translation	AndreUlrich
Italian translation	MassimoMancini
Polish translation	ZbigniewKulesza
Portuguese translation	AntonioTerceiro, CarlinhosCecconi
Spanish translation	WillNorris, MiguelABayona
Swedish translation	Erik Åman
New features for users
Edit conflict resolution with automatic merge	Crawford Currie
Fine grained change notification on page level and parent/child relationship	Crawford Currie
WYSIWYG editor	Crawford Currie, ColasNahaboo, DamienMandrioli, RomainRaugi
Integrated session support	GregAbbas, Crawford Currie
Webserver-independent login/logout	Crawford Currie
Registration process with e-mail confirmation	MartinCleaver
Tip of the Day box in TWiki Home	PaulineCheung, Peter Thoeny, AntonAylward
ATOM feeds	Peter Thoeny
"Force New Revision" check box for topic save	WillNorris
New features for Wiki administrators and wiki application developers
Improved preferences handling	ThomasWeigert, Crawford Currie
Named include sections	RafaelAlvarez
Create topic names with consecutive numbers	Sven Dowideit
Parameterized includes	Crawford Currie
Dynamic form option definitions of DataForms with FormattedSearch	MartinCleaver
SEARCH enhancements with new parameters excludeweb, newline, noempty, nofinalnewline, nonoise, recurse, zeroresults	Crawford Currie, ArthurClemens, Peter Thoeny, ThomasWeigert
FormattedSearch enhancements with $changes, $count, $formfield(name, 30, ...), $summary(expandvar), $summary(noheaders), $summary(showvarnames)	ColasNahaboo, Crawford Currie, Peter Thoeny, Sven Dowideit
New TWikiVariables ACTIVATEDPLUGINS, ALLVARIABLES, AUTHREALM, EMAILS, FAILEDPLUGINS, HTTP, HTTPS, ICONURL, ICONURLPATH, IF, LANGUAGES, LOCALSITEPREFS, LOGIN, LOGOUT, MAKETEXT, META, PLUGINDESCRIPTIONS, QUERYSTRING, STARTSECTION/ENDSECTION, SESSION_VARIABLE, SESSIONID, SESSIONVAR, SPACEOUT, USERLANGUAGE, WIKIHOMEURL	ArthurClemens, AntonioTerceiro, Crawford Currie, GregAbbas, Peter Thoeny, Sven Dowideit, WillNorris and many more
TWiki form with hidden type and other form enhancements	LynnwoodBrown, ThomasWeigert
Support topic-specific templates for TWiki applications	ThomasWeigert
Direct save feature for one-click template-based topic creation	LynnwoodBrown, Crawford Currie, ThomasWeigert
Automatic Attachments showing all files in the attachment directory	MartinCleaver
Rename, move or delete webs	PeterNixon
Hierarchical subwebs (beta)	PeterNixon
New features for Plugin developers
REST (representational state transfer) interface for Plugins	RafaelAlvarez, TWiki:Main.MartinCleaver, Sven Dowideit
New and improved Plugins APIs	Crawford Currie, ThomasWeigert
Improvements in the TWiki engine room
Major OO redesign and refactoring of codebase	Crawford Currie
Automatic build system	Crawford Currie
Extensive test suite, unit tests and testcases	Crawford Currie
TWiki:Codev.DevelopBranch , DEVELOP branch Bugs system	Sven Dowideit
Documentation, logo artwork, skins:
Documentation	Crawford Currie, LynnwoodBrown, Peter Thoeny, Sven Dowideit and others
Design of TWikiLogos with big "T" in a speech bubble	ArthurClemens, Peter Thoeny
Improved templates and PatternSkin	ArthurClemens

See more details at TWikiReleaseNotes04x00

01-Sep-2004 Release (Cairo)

Major New Features

• Automatic upgrade script, and easier first-time installation
• Attractive new skins, using a standard set of CSS classes, and a skin browser to help you choose
• New easier-to-use save options
• Many improvements to SEARCH
• Improved support for internationalisation
• Better topic management screens
• More pre-installed Plugins: CommentPlugin, EditTablePlugin, RenderListPlugin, SlideShowPlugin, SmiliesPlugin, SpreadSheetPlugin, TablePlugin
• Improved Plugins API and more Plugin callbacks
• Better support for different authentication methods
• Many user interface and usability improvements
• And many, many more enhancements

Details of New Features and Enhancements of 01-Sep-2004 Release	Developer, Sponsor
Install: Ship with an automatic upgrade script to facilitate TWiki upgrades. Details	TWiki:Main.MartinGregory Foswiki:Main.SvenDowideit
Install: New testenv function to change the locks in the TWiki database to the web server user id (automates installation step). Details	TWiki:Main.MattWilkie Foswiki:Main.SvenDowideit
Install: The shipped .htaccess.txt now needs to be edited before it is valid, to help reduce chances of error. Details	Foswiki:Main.CrawfordCurrie Foswiki:Main.SvenDowideit
Install: Configurable password file handling for different types of encryption. Details	TWiki:Main.PavelGoran Foswiki:Main.SvenDowideit
Install: Remove office locations from registration. Details	TWiki:Main.PeterThoeny
Install: Changes to support shorter URLs with Apache Rewrite rules. Details	TWiki:Main.AntonioBellezza TWiki:Main.WalterMundt
Install: Remove the Know web from the distribution. Details	TWiki:Main.PeterThoeny
Internationalization: Support use of UTF-8 URLs for I18N characters in TWiki page and attachment names. Details	TWiki:Main.RichardDonkin
Authentication: Authenticate users when creating new topic in view restricted web. Details	TWiki:Main.JonathanGraehl Foswiki:Main.SvenDowideit
Preferences: TWiki Preferences need to be secured properly. Details	TWiki:Main.PeterThoeny
Preferences: Use TWiki Forms to set user preferences. Details	TWiki:Main.JohnTalintyre
Skins: New pre-installed skins PatternSkin and DragonSkin. Details	Foswiki:Main.ArthurClemens TWiki:Main.PeterThoeny
Skins: New skin browser to choose from installed skins. Details	TWiki:Main.PeterThoeny
Skins: Documented set of CSS classes that are used in standard skins. Details	Foswiki:Main.ArthurClemens Foswiki:Main.SvenDowideit
Skins: Added CSS class names to Diff output. Details	Foswiki:Main.SvenDowideit
Skins: Templates can now be read from user topics, as well as from files in the templates diretcory. Details	Foswiki:Main.CrawfordCurrie TWiki:Main.WalterMundt
Skins: Ensure that the default template gets overridden by a template passed in. Details	TWiki:Main.MartinCleaver TWiki:Main.WalterMundt
Skin: Convey an important broadcast message to all users, e.g. scheduled server downtime. Details	TWiki:Main.PeterThoeny
Skin: Balanced pastel colors for TWiki webs. Details	Foswiki:Main.ArthurClemens
Rendering: Use exclamation point prefix to escape TWiki markup rendering. Details	Foswiki:Main.ArthurClemens
Rendering: Ordered lists with uppercase & lowercase letters, uppercase & lowercase Roman numerals. Details	TWiki:Main.DanBoitnott TWiki:Main.PeterThoeny
Rendering: Allow custom styles for the "?" of uncreated topics. Details	Foswiki:Main.SvenDowideit
Rendering: Render IRC and NNTP as a URL. Details	TWiki:Main.PeterThoeny
Rendering: Make acronym linking more strict by requiring a trailing boundary, e.g. excluding TLAfoobar. Details	Foswiki:Main.CrawfordCurrie Foswiki:Main.SvenDowideit
Rendering: TWiki Form with Label type. Details	TWiki:Main.PeterThoeny
Rendering: Web names can now be WikiWords. Details	TWiki:Main.PeterThoeny
Rendering: New syntax for definition list with dollar sign and colon. Details	TWiki:Main.AdamTheo TWiki:Main.PeterThoeny
Rendering: Table with multi-span rows, functionality provided by Table Plugin. Details	TWiki:Main.WalterMundt
Variables: New title parameter for TOC variable. Details	TWiki:Main.PeterThoeny Foswiki:Main.ArthurClemens
Variables: New REVINFO variable in templates supports flexible display of revision information. Details	TWiki:Main.PeterThoeny Foswiki:Main.SvenDowideit
Variables: Set times to be displayed as gmtime or servertime. Details	TWiki:Main.SueBlake Foswiki:Main.SvenDowideit
Variables: Properly encode parameters for form fields with ENCODE variable. Details	TWiki:Main.PeterThoeny
Variables: Expand USERNAME and WIKINAME in Template Topics. Details	TWiki:Main.PeterThoeny
Variables: Expand same variables in new user template as in template topics. Details	TWiki:Main.PeterThoeny
Variables: Optionally warn when included topic does not exist; with the option to create the included topic. Details	TWiki:Main.PeterThoeny
Variables: In topic text show file-types of attached files as icons. Details	TWiki:Main.PeterThoeny
Variables: New variable FORMFIELD returns the value of a field in the form attached to a topic.. Details	TWiki:Main.DavidSachitano Foswiki:Main.SvenDowideit
Variables: Meta data rendering for form fields with META{"formfield"}. Details	TWiki:Main.PeterThoeny
Variables: New PLUGINVERSION variable. Details	TWiki:Main.PeterThoeny
Variables: URLPARAM now has a default="..." argument, for when no value has been given. Details	TWiki:Main.PeterThoeny
Variables: URLPARAM variable with newline parameter. Details	TWiki:Main.PeterThoeny
Variables: URLPARAM variable with new multiple=on parameter. Details	TWiki:Main.PaulineCheung TWiki:Main.PeterThoeny
Search: New switch for search to perform an AND NOT search. Details	TWiki:Main.PeterThoeny
Search: Keyword search to search with implicit AND. Details	TWiki:Main.PeterThoeny
Search: Multiple searches in same topic with new multiple="on" paramter. Details	TWiki:Main.PeterThoeny
Search: Remove limitation on number of topics to search in a web. Details	TWiki:Main.PeterThoeny
Search: Exclude topics from search with an excludetopic parameter. Details	TWiki:Main.PeterThoeny
Search: Expand Variables on Formatted Search with expandvariables Flag. Details	TWiki:Main.PeterThoeny
Search: Formatted Search with Web Form variable to retrieve the name of the form attached to a topic. Details	TWiki:Main.FrankSmith TWiki:Main.PeterThoeny
Search: Formatted Search with Conditional Output. Details	TWiki:Main.PeterThoeny
Search: Formatted Search with $parent token to get the parent topic. Details	TWiki:Main.PeterThoeny
Search: New separator parameter to SEARCH supports better SEARCH embedding. Details	TWiki:Main.PeterThoeny
Search: Improved search performance when sorting result by topic name. Details	TWiki:Main.PeterThoeny
Search: New scope=all search parameter to search in topic name and topic text at the same time. Details	TWiki:Main.PeterThoeny
Search: New topic parameter for AND search on topic text and topic name. Details	TWiki:Main.PeterThoeny
Search modules uses Perl-style keyword parameters (code cleanup). Details	TWiki:Main.PeterThoeny
Search: New $wikiname variable in format parameter of formatted search. Details	Foswiki:Main.ArthurClemens
Search: Sort search by topic creation date. Details	TWiki:Main.PeterThoeny
Search: Topic creation date and user in Formatted Search. Details	TWiki:Main.CoreyFruitman Foswiki:Main.SvenDowideit
Search: Increase levels of nested search from 2 to 16. Details	TWiki:Main.PeterThoeny
Plugins: New pre-installed Plugins CommentPlugin, EditTablePlugin, RenderListPlugin, SlideShowPlugin, SmiliesPlugin, SpreadSheetPlugin, TablePlugin. Details	TWiki:Main.PeterThoeny
Plugins: New callback afterSaveHandler, called after a topic is saved. Details	TWiki:Main.WalterMundt
Plugins: New callbacks beforeAttachmentSaveHandler and afterAttachmentSaveHandler, used to intervene on attachment save event. Details	TWiki:Main.MartinCleaver TWiki:Main.WalterMundt
Plugins: New callbacks beforeCommonTagsHandler and afterCommonTagsHandler. Details	TWiki:Main.PeterThoeny
Plugins: New callback renderFormFieldForEditHandler to render form field for edit. Details	TWiki:Main.JohnTalintyre
Plugins: New callback renderWikiWordHandler to custom render links. Details	TWiki:Main.MartinCleaver TWiki:Main.WalterMundt
Plugins: New function TWiki::Func::formatTime to format time into a string. Details	Foswiki:Main.SvenDowideit
Plugins: New function TWiki::Func::getRegularExpression to get predefined regular expressions. Details	TWiki:Main.RichardDonkin
Plugins: New functions TWiki::Func::getPluginPreferences* to get Plugin preferences. Details	TWiki:Main.WalterMundt
Plugins: New function TWiki::Func::extractParameters to extract all parameters from a variable string. Details	TWiki:Main.PeterThoeny
Plugins: New function TWiki::Func::checkDependencies to check for module dependency. Details	Foswiki:Main.CrawfordCurrie Foswiki:Main.SvenDowideit
Plugins: A recommendation for where a Plugin can store its data. Details	TWiki:Main.PeterThoeny
UI: Show tool-tip topic info on WikiWord links. Details	TWiki:Main.PeterThoeny
UI: Save topic and continue edit feature. Details	TWiki:Main.ColasNahaboo
UI: Change topic with direct save (without edit/preview/save cycle) and checkpoint save. Details	TWiki:Main.MattWilkie Foswiki:Main.SvenDowideit
UI: In attachment table, change 'action' to 'manage'. Details	TWiki:Main.PeterThoeny Foswiki:Main.ArthurClemens
UI: Smaller usability enhancements on the file attachment table. Details	TWiki:Main.PeterThoeny Foswiki:Main.ArthurClemens
UI: Removes anchor links from header content and places them before the text to fix 'header becomes link'. Details	Foswiki:Main.ArthurClemens
UI: Improved functionality of the More screen. Details	TWiki:Main.PeterThoeny Foswiki:Main.ArthurClemens
UI: Quick reference chart of most used markup is now listed on the edit screen. Details	Foswiki:Main.ArthurClemens
UI: Flag for edit script to avoid overwrite of existing topic text and form data. Details	TWiki:Main.NielsKoldso TWiki:Main.PeterThoeny
UI: Disable Escape key in IE textarea to prevent it cancelling work. Details	Foswiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny
UI: Improved warning message on unsaved topic. Details	TWiki:Main.MartinGregory Foswiki:Main.SvenDowideit
UI: Reverse order of words in page title for better multi-window/tab navigation. Details	Foswiki:Main.ArthurClemens
UI: Provides a framework to create and modify a topic without going through edit->preview->save sequence. Details	Foswiki:Main.AndreUlrich Foswiki:Main.SvenDowideit
UI: Set the topic parent to none in More screen, e.g. remove the current topic parent. Details	TWiki:Main.PeterThoeny
UI: Use templates to define how file attachments are displayed. Was previously hard-coded. Details	Foswiki:Main.CrawfordCurrie Foswiki:Main.SvenDowideit
UI: Topic diff shows unified diff with unchanged context. Details	Foswiki:Main.SvenDowideit
UI: Diff feature shows TWiki form changes in nice tables. Details	Foswiki:Main.SvenDowideit
Code refactoring: The log entry for a save now has a dontNotify flag in the extra field if the user checked the minor changes flag. Details	TWiki:Main.PeterThoeny
Code refactoring: Server-side include of attachments accelerates INCLUDE. Details	Foswiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny
Code refactoring: Move functionality out of bin scripts and into included modules. Details	Foswiki:Main.CrawfordCurrie Foswiki:Main.SvenDowideit
Code refactoring: Move bin script functionality into TWiki::UI modules. Details	Foswiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny
Code refactoring: Optimize preferences handling for better performance. Details	TWiki:Main.PavelGoran TWiki:Main.WalterMundt
Code refactoring: Refactor variable expansion for edit and register. Details	Foswiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny
Code refactoring: Move savemulti script into TWiki::UI::Save. Details	TWiki:Main.MattWilkie Foswiki:Main.SvenDowideit
Code refactoring: Topic search is done natively in Perl, it does not depend anymore on system calls with pipes. Details	TWiki:Main.PeterThoeny
Code refactoring: Fix logical error in upload script which prevented MIME filename from being used. Details	TWiki:Main.WalterMundt

Bug Fixes of 01-Sep-2004 Release	Developer, Sponsor
Fix: Consistently create headings with empty anchor tags. Details	TWiki:Main.PeterThoeny
Fix: TOC does not work for headings containing & without spaces surrounding it. Details	TWiki:Main.PeterThoeny
Fix: Backslash line break breaks TWiki form definitions. Details	Foswiki:Main.CrawfordCurrie TWiki:Main.PeterThoeny
Fix: Rename fixes unrelated topic references. Details	TWiki:Main.RichardDonkin
Fix: Bug with infinite recursion in search. Details	TWiki:Main.PeterThoeny
Fix: Can't send mail with full 'From' address. Details	TWiki:Main.PeterThoeny
Fix: All scripts change to $bin before execute (for mod_perl2). Details	TWiki:Main.PeterThoeny
Fix: Several RSS readers do not show all entries seen in the WebChanges list; repeated updates to the same topics get lost. Details	Foswiki:Main.ArthurClemens
Fix: TWiki::Access::checkAccessPermission function improperly handles Main and TWiki webs. Details	Foswiki:Main.SvenDowideit
Fix: Topic save returns error CI Date precedes date in revision. Details	TWiki:Main.PeterThoeny
Fix: Double quotes got replaced by " in TWiki forms. Details	TWiki:Main.MichaelSparks TWiki:Main.PeterThoeny
Fix: Duplicated Wiki name in .htpasswd entry for sha1 encoding. Details	TWiki:Main.PeterThoeny
Fix: When viewing a previous version of a topic, the view script substitutes only one occurrence of the variable EDITTOPIC. Details	TWiki:Main.PeterThoeny
Fix: Form default values are not working for text fields. Details	TWiki:Main.ThomasWeigert Foswiki:Main.SvenDowideit
Fix: Formatted searches using a $pattern which unbalanced parenthesis crash TWiki. Details	TWiki:Main.PeterThoeny
Fix: Formatted Search uses title but should use name for formfield parameter. Details	TWiki:Main.PeterThoeny
Fix: GMTIME variable returns unwanted GMT text. Details	Foswiki:Main.SvenDowideit
Fix: Include from other Web links ACRONYMS. Details	TWiki:Main.PeterThoeny
Fix: Including an HTML file is very slow. Details	TWiki:Main.JohnTalintyre
Fix: includeUrl() mess up absolute URLs. Details	Foswiki:Main.SvenDowideit
Fix: Filter out fixed font rendering in TOC to avoid unrendered = equal signs in TOC. Details	TWiki:Main.PeterThoeny
Fix: The initializeUserHandler is broken for session Plugins. Details	TWiki:Main.JohnTalintyre
Fix: SEARCH fails with very large webs. Details	TWiki:Main.PeterThoeny
Fix: Security alert: User could gain view access rights of another user. Details	TWiki:Main.KimCovil TWiki:Main.PeterThoeny
Fix: 'print to closed file handle' error of log files are not writable. Details	TWiki:Main.MartinGregory Foswiki:Main.SvenDowideit
Fix: Meta data handler can't process CR-LF line endings. Details	TWiki:Main.PeterThoeny
Fix: METAFIELD meta data is not shown in view raw=on mode. Details	TWiki:Main.PeterThoeny
Fix: Minor XHTML non-compliance in templates and code. Details	TWiki:Main.PeterThoeny
Fix: Getting pages from virtual hosts fails. Details	TWiki:Main.JohnTalintyre
Fix: Create new web fails if RCS files do not exist. Details	TWiki:Main.ClausBrunzema Foswiki:Main.SvenDowideit
Fix: Metacharacters can be passed through to the shell in File Attach. Details	TWiki:Main.PeterThoeny
Fix: Ability to delete non-WikiWord topics without confirmation. Details	TWiki:Main.PeterThoeny
Fix: + symbol in password reset fails. Details	TWiki:Main.PeterThoeny
Fix: Pathinfo cleanup for hosted sites. Details	TWiki:Main.MikeSalisbury Foswiki:Main.SvenDowideit
Fix: Software error in SEARCH if regular expression pattern has unmached parenthesis. Details	TWiki:Main.PeterThoeny
Fix: Pipe chars in the comment field of the attachment table are not escaped. Details	TWiki:Main.PeterThoeny
Fix: Link escaping in preview fails for not quoted hrefs. Details	TWiki:Main.TedPavlic TWiki:Main.PeterThoeny
Fix: Preview expands variables twice. Details	TWiki:Main.PeterThoeny
Fix: Using a proxy with TWiki fails; no proxy-HTTP request, minimal request not HTTP 1.0, requests marked 1.1 are at best 1.0. Details	TWiki:Main.MichaelSparks TWiki:Main.JohnTalintyre
Fix: Runaway view processes with TWiki::Sore::RcsLite. Details	Foswiki:Main.SvenDowideit
Fix: Regex Error in WebTopicList with topics that have meta characters in the name. Details	TWiki:Main.PeterThoeny
Fix: Rename script misses some ref-by topics. Details	TWiki:Main.JohnTalintyre
Fix: Links to self within the page being renamed are not changed. Details	Foswiki:Main.SvenDowideit
Fix: Rename topic does 'Main.Main.UserName' for attachments. Details	TWiki:Main.PeterThoeny
Fix: Revision date is set to Jan 1970 when using RCS Lite. Details	Foswiki:Main.SvenDowideit
Fix: The new dynamically-created SiteMap is very nice, but somewhat slow. Details	TWiki:Main.PeterThoeny
Fix: The makeAnchorName function did not produce the same results if called iteratively, resulting in problems trying to link to headers.. Details	TWiki:Main.WalterMundt
Fix: Statistics page does not provide links to non-wikiword topics. Details	TWiki:Main.PeterThoeny
Fix: Make TOC link URI references relative. Details	TWiki:Main.MartinGregory TWiki:Main.PeterThoeny
Fix: TWiki hangs when used on Apache 2.0. Details	Foswiki:Main.SvenDowideit
Fix: TOC incorrectly strips out links in headers. Details	TWiki:Main.PeterThoeny
Fix: The HTML tags that are generated by TOC do not close properly. Details	TWiki:Main.PeterThoeny
Fix: TOC on INCLUDEd topic ignores STOPINCLUDE. Details	Foswiki:Main.WillNorris TWiki:Main.PeterThoeny
Fix: Quotes in tooltip message can break a TWiki form. Details	TWiki:Main.PeterThoeny
Fix: Better error message if the file attachment directory is not writable. Details	Foswiki:Main.CrawfordCurrie Foswiki:Main.SvenDowideit
Fix: Image size of PNG files. Details	Foswiki:Main.ArthurClemens
Fix: The testenv script distinguishes between real user ID and effective user ID. Details	TWiki:Main.RichardDonkin
Fix: Variables in square bracket links dont work in form fields. Details	Foswiki:Main.SvenDowideit
Fix: Variable with Parameters in Form Fields Disappear. Details	TWiki:Main.PeterThoeny
Fix: Verbatim tag should escape HTML entities. Details	TWiki:Main.PeterThoeny
Fix: Field names of TWiki Forms can be WikiWords, this is used to link to a help topic. Details	TWiki:Main.PeterThoeny
Fix: Clean up the WebRssBase INCLUDES to use VARIABLES set in TWikiPreferences. Details	Foswiki:Main.SvenDowideit
Fix: Resolving variables in included topics. Details	Foswiki:Main.OliverKrueger Foswiki:Main.SvenDowideit

01-Feb-2003 Release (Beijing)

• 18 Jan 2003 - TWiki:Main.PeterThoeny
  • Support for /bin/view/Web.TopicName topic view URL (besides the default /bin/view/Web/TopicName URL); useful for InterwikiPlugin links like TWiki:Codev.ReadmeFirst
• 31 Dec 2002 - TWiki:Main.PeterThoeny
  • Enhanced Plugin API to manipulate topic data with new functions in Func.pm: readTopicText, saveTopicText, setTopicEditLock, checkTopicEditLock
• 31 Dec 2002 - TWiki:Main.PeterThoeny
  • New %NOAUTOLINK% setting in the DefaultPreferences to disable the auto-linking of WikiWords
• 29 Dec 2002 - TWiki:Main.AndreaSterbini, TWiki:Main.PeterThoeny, TWiki:Main.RichardDonkin, Foswiki:Main.SvenDowideit
  • New Plugin hooks registrationHandler, beforeEditHandler, afterEditHandler, beforeSaveHandler, writeHeaderHandler, redirectCgiQueryHandler, getSessionValueHandler, setSessionValueHandler
• 30 Nov 2002 - TWiki:Main.RichardDonkin
  • Internationalization ('I18N') support for international characters in WikiWords, such as ISO-8859-15, KOI8-R - also supports Chinese, Japanese, etc.
• 25 Nov 2002 - TWiki:Main.PeterThoeny
  • Include previous topic revision with %INCLUDE{ "OtherTopic" rev="1.2" }%
• 15 Nov 2002 - TWiki:Main.PeterThoeny
  • The Go box understands also URLs, useful for special TWikiSkins handling
• 08 Nov 2002 - TWiki:Main.ColasNahaboo, TWiki:Main.RichardDonkin
  • In WebNotify, if only the WikiName is specified, the e-mail is taken from the user's home page; if the WikiName is a group name, a notification is sent to all members of the group
• 30 Oct 2002 - TWiki:Main.PeterThoeny
  • New %NOP{}% variable in TWikiTemplates topic gets removed at topic creation time; useful to write protect template topics
• 28 Sep 2002 - TWiki:Main.PeterThoeny
  • The %URLPARAM{}% variable in TWikiTemplates topic gets expanded at topic creation time; useful for dynamic content creation
• 28 Sep 2002 - TWiki:Main.PeterThoeny
  • New $logDir introduced in TWiki.cfg to set the log directory
• 13 Sep 2002 - TWiki:Main.PeterThoeny
  • Renamed the Test web to Sandbox
• 03 Aug 2002 - TWiki:Main.RichardDonkin
  • New setlib.cfg file in the bin directory to set the TWiki library path
• 02 Aug 2002 - TWiki:Main.PeterThoeny, TWiki:Main.RyanFreebern
  • Support for outbound HTTP proxy when including URLs based on new %PROXYHOST and %PROXYPORT% settings in the DefaultPreferences
• 12 Jul 2002 - TWiki:Main.PeterThoeny
  • The page logo is configurable with new %WIKILOGOIMG%, %TWIKILOGOURL% and %WIKILOGOALT% variables in DefaultPreferences; replacing $wikiHomeUrl in TWiki.cfg
• 12 Jun 2002 - TWiki:Main.PeterThoeny
  • New %WIKITOOLNAME% variable in DefaultPreferences; replacing $wikiToolName in TWiki.cfg
• 31 May 2002 - TWiki:Main.PeterThoeny
  • New %EDITBOXSTYLE% preferences setting which sets the edit box width automatically to the window width
• 17 May 2002 - TWiki:Main.PeterThoeny
  • New %URLENCODE{}% variable to encodes a string for using in a URL parameter, e.g. %URLENCODE{"spaced name"}% returns spaced%20name
• 17 May 2002 - TWiki:Main.PeterThoeny
  • FormattedSearch can be nested
• 05 May 2002 - TWiki:Main.PeterThoeny
  • New user home pages are now based on the NewUserTemplate, replacing the /twiki/templates/register.tmpl template file
• 26 Apr 2002 - TWiki:Main.PeterThoeny
  • New markup to exclude heading from a %TOC% table of content, e.g. ---+!! This heading is not shown in a TOC
• 13 Apr 2002 - TWiki:Main.PeterThoeny
  • Form and script to create new webs, see ManagingWebs
• 01 Apr 2002 - TWiki:Main.JohnTalintyre
  • New data storage framework that lets you use external RCS commands for revision control, or a new native Perl implementation that does not depend on the external RCS commands
• 28 Mar 2002 - TWiki:Main.RichardDonkin
  • Fixed IE5/IE6-specific problem whereby going back from preview sometimes removes all edit changes
• 23 Mar 2002 - TWiki:Main.JohnTalintyre
  • New AND search; with regular expression enabled, use the semicolon ";" as the AND operator in %SEARCH{}% variable, FormattedSearch and WebSearch
• 21 Mar 2002 - TWiki:Main.ColasNahaboo, TWiki:Main.RichardDonkin
  • Fixed cache issue where the edit page showed outdated content
• 06 Mar 2002 - TWiki:Main.RichardDonkin
  • Improved statistics script which uses less memory to process large log files
• 09 Jan 2002 - TWiki:Main.JohnTalintyre
  • Variables inside <verbatim> tags are no longer expanded

01-Dec-2001 Release (Athens)

• 25 Oct 2001 - TWiki:Main.PeterThoeny
  • Added FormattedSearch to %SEARCH{}% variable for database like reporting.

01-Sep-2001 Release

• 30 Aug 2001 - TWiki:Main.JohnTalintyre
  • Easier install for Windows, including auto detection in TWiki.cfg
• 30 Aug 2001 - TWiki:Main.JohnTalintyre
  • Ability to move attachments between topics, see FileAttachments
• 21 Aug 2001 - TWiki:Main.PeterThoeny
  • Convert to XHTML 1.0 function: first step to XHTML-ifying TWiki
• 26 Jun 2001 - TWiki:Main.JohnTalintyre
  • Category information to forms using the TWikiMetaData format, see TWikiForms
• 07 Jun 2001 - TWiki:Main.PeterThoeny
  • New topic templates as topics instead of templates. Customize by editing the topic. Retired notedited.tmpl, notext.tmpl and nofoswiki.tmpl templates. More in TWikiTemplates.
• 07 Jun 2001 - TWiki:Main.PeterThoeny
  • New %TOPICLIST{"format"}% and %WEBLIST{"format"}% variables to get a formatted topic index and web index, respectively. More in TWikiVariables.
• 01 Jun 2001 - TWiki:Main.PeterThoeny
  • New %URLPARAM{"name"}% variable to query URL parameters. More in TWikiVariables.
• 01 Jun 2001 - TWiki:Main.AndreaSterbini
  • API to extend TWiki, see TWikiPluginAPI
• 01 Jun 2001 - TWiki:Main.KlausWriessnegger, TWiki:Main.AndreaSterbini
  • Forms to change/reset/install passwords, see ChangePassword & ResetPassword
• 01 May 2001 - TWiki:Main.AndreaSterbini
  • The Main.AdminGroup (or other group) can be enabled as a SuperAdminGroup. Members have browser edit access to all locked topics.
• 01 May 2001 - TWiki:Main.JohnTalintyre
  • Meta information format, see TWikiMetaData
• 01 May 2001 - TWiki:Main.JohnTalintyre
  • Attachment under revision control See FileAttachment
• 01 May 2001 - TWiki:Main.JohnTalintyre
  • Ability to rename/move topics, ManagingTopics
• 27 Mar 2001 - TWiki:Main.PeterThoeny
  • The table syntax has been enhanced to (i) render | *bold* | cells as table headers, (ii) render space padded cells | center aligned | and | right aligned |, (iii) span multiple columns using | empty cells |||. More in TextFormattingRules.
• 25 Mar 2001 - TWiki:Main.PeterThoeny
  • Security fix Questionable files like PHP scripts (executables) and .htaccess files that are attached to a topic get a .txt suffix appended to the file name. See also TWiki:Codev/FileAttachmentFilterSecurityAlert
• 28 Feb 2001 - TWiki:Main.AndreaSterbini, TWiki:Main.PeterThoeny
  • New Wiki rule for headings, i.e. ---++ My Title; and new %TOC% variable to build a table of content from headings in a topic. More in TWikiVariables.
• 28 Feb 2001 - TWiki:Main.PeterThoeny
  • New Wiki rule to specify arbitrary text for external links (i.e. [[http://TWki.org][TWiki]]) and internal links (i.e [[WikiSyntax][syntax]]). More in TWikiVariables.
• 28 Feb 2001 - TWiki:Main.PeterThoeny
  • New Wiki rule for named anchors, e.g. links within a topic. Define a named anchor with #MyAnchor at the beginning of a line, and link to it with [[#MyAnchor]]. More in TWikiVariables.
• 25 Feb 2001 - TWiki:Main.NicholasLee, TWiki:Main.PeterThoeny
  • Use Net::SMTP module instead of sendmail if installed.
• 01 Feb 2001 - TWiki:Main.PeterThoeny
  • Added <verbatim> ... </verbatim> tags to show source code "as is". Unlike the <pre> ... </pre> tags, it also shows <, >, & characters "as is".
• 01 Feb 2001 - TWiki:Main.PeterThoeny
  • Fixed TWiki:Codev/CreateLinkToAttachedFileBug.
• 21 Jan 2001 - TWiki:Main.PeterThoeny
  • Added a "Minor change, don't notify" checkbox in preview. More in DontNotify.
• 21 Jan 2001 - TWiki:Main.PeterThoeny
  • Added Bold Fixed formatting using double-equal signs, e.g. write ==Bold Fixed== to get Bold Fixed.
• 20 Jan 2001 - TWiki:Main.PeterThoeny
  • Format changed of %GMTIME{"..."}% and %SERVERTIME{"..."}% variables. Format is now "$hour:$min" instead of "hour:min". More in TWikiVariables. Attention: Check your existing topics when you upgrade TWiki!
• 18 Jan 2001 - TWiki:Main.PeterThoeny
  • WebChanges, WebSearch and e-mail notification indicate also the revision number of a topic (i.e. 18 Jan 2001 16:43 r1.5), or NEW for a new topic (i.e. i.e. 18 Jan 2001 16:43 NEW ).
• 16 Jan 2001 - TWiki:Main.PeterThoeny
  • New variable %STARTINCLUDE% and %STOPINCLUDE% variables to control what gets included of a topic. More in TWikiVariables.
• 16 Jan 2001 - TWiki:Main.PeterThoeny
  • TWiki skins Define a different page layout with a customized header and footer layout, i.e. a print skin for a printable view of a topic. More in TWikiSkins and TWiki:Codev/TWikiSkins.
• 07 Jan 2001 - TWiki:Main.StanleyKnutson
  • Better error handling when saving a topic.
• 05 Jan 2001 - TWiki:Main.PeterThoeny
  • View authorization based on groups. Define who is allowed to see a TWiki web. More in AccessControl and TWiki:Codev/AuthenticationBasedOnGroups.
• 05 Dec 2000 - TWiki:Main.PeterThoeny
  • Improved include handling. Infinite recursion of includes are prevented; new variables %BASEWEB%, %INCLUDINGWEB%, %BASETOPIC% and %INCLUDINGTOPIC% to have more control over include handling. More in TWikiVariables and TWiki:Codev/IncludeHandlingImprovements.
• 03 Dec 2000 - TWiki:Main.PeterThoeny
  • New noheader="on" switch in %SEARCH{...}% to suppress table header. More in TWikiVariables.

01-Dec-2000 Release

• 03 Nov 2000 - TWiki:Main.PeterThoeny
  • Flag $doHidePasswdInRegistration in wikicfg.pm to hide plain text password in registration e-mail.
• 01 Nov 2000 - TWiki:Main.PeterThoeny
  • New variable %VAR{"NAME" web="Web"}% to get web-specific preferences. More in TWikiVariables.
• 01 Nov 2000 - TWiki:Main.PeterThoeny
  • Added a "Cancel" link in edit that releases the edit lock.
• 23 Oct 2000 - TWiki:Main.PeterThoeny
  • Authorization based on groups. Define fine graned control who is allowed to change or create topics. More in AccessControl and TWiki:Codev/AuthenticationBasedOnGroups.
• 05 Oct 2000 - TWiki:Main.PeterThoeny
  • Remember user by IP address so that view "knows" the user once authenticated in edit. More in TWikiUserAuthentication.
• 26 Sep 2000 - TWiki:Main.AlWilliams, TWiki:Main.PeterThoeny
  • Fixed TWiki:Codev/UppercaseAttachments bug and added png image support.
• 26 Sep 2000 - TWiki:Main.HaroldGottschalk, TWiki:Main.AndreaSterbini, TWiki:Main.PeterThoeny
  • Allow nesting of variables, i.e. %INCLUDE{"%SYSTEMWEB%.TWikiWebsTable"}%. More in TWiki:Codev/BetterTWikiTagTemplateProcessing.
• 20 Sep 2000 - TWiki:Main.ManpreetSingh
  • New -q switch in mailnotify to suppress all normal output.
• 19 Sep 2000 - TWiki:Main.PeterThoeny
  • Fixed TWiki:Codev/AttachedNotificationLinksBug.
• 18 Sep 2000 - TWiki:Main.ManpreetSingh, TWiki:Main.PeterThoeny
  • Added forced internal links. Write [[text formatting FAQ]] to get the link text formatting FAQ that points to topic TextFormattingFAQ.
• 19 Aug 2000 - TWiki:Main.PeterThoeny
  • Ref-By link searches all webs (not just the current web.)
• 16 Aug 2000 - TWiki:Main.PeterThoeny
  • New TWikiPreferences settings %HTTP_EQUIV_ON_VIEW% , %HTTP_EQUIV_ON_EDIT% and %HTTP_EQUIV_ON_PREVIEW% that define the <meta http-equiv="..."> meta tags for the TWiki templates. This can be used for example to set a document expiration time.
• 29 Jul 2000 - TWiki:Main.PeterThoeny
  • New variables %GMTIME{"..."}% and %SERVERTIME{"..."}% . More in TWikiVariables.
• 23 Jul 2000 - TWiki:Main.PeterThoeny
  • Changed include syntax from %INCLUDE{"Web/TopicName.txt"}% to %INCLUDE{"Web.TopicName"}% . Legacy syntax still supported.
• 23 Jul 2000 - TWiki:Main.PeterThoeny
  • BookView search allows you show a set of topics for easy printing.
• 22 Jul 2000 - TWiki:Main.PeterThoeny
  • More forgiving syntax for *bold*, italic, __bold italic__ and fixed , where it is not necessary anymore to have a trailing space before .,;:?! characters.
• 22 Jul 2000 - TWiki:Main.PeterThoeny
  • Split the TWiki.Main web into TWiki.Main (users, company data) and TWiki.TWiki (TWiki related documentation, registration)
• 07 Jul 2000 - TWiki:Main.PeterThoeny
  • Added an "Release edit lock" checkbox in preview to let other people edit the topic immediately without the one hour lock.
• 07 Jul 2000 - TWiki:Main.PeterThoeny
  • Fixed problem of losing carriage returns when editing topics with KDE KFM browser or W3M browser.
• 21 Jun 2000 - TWiki:Main.PeterThoeny
  • Fixed problem that a page redirect on some server environments is not working (host name is needed in URL).
• 21 Jun 2000 - TWiki:Main.CrisBailiff, TWiki:Main.PeterThoeny
  • Fixed security issue to prevent a server side %INCLUDE% of arbitrary files.
• 29 May 2000 - TWiki:Main.PeterThoeny
  • New %GMTIME% variable that shows the current GM time.
• 28 May 2000 - TWiki:Main.PeterThoeny
  • Lock warning shows remaining lock time in minutes.
• 15 May 2000 - TWiki:Main.PeterFokkinga
  • Each topic can have its own template file. TWikiTemplates has more.
• 02 May 2000 - TWiki:Main.KevinKinnell, TWiki:Main.PeterThoeny
  • Advanced search features like search multiple webs; sort by topic name / modified time / author; limit the number of results returned. More in TWikiVariables.

01-May-2000 Release

• 21 Apr 2000 - TWiki:Main.PeterThoeny
  • New TWikiVariables %HTTP_HOST% , %REMOTE_ADDR% , %REMOTE_PORT% and %REMOTE_USER% .
• 21 Apr 2000 - TWiki:Main.JohnAltstadt, TWiki:Main.PeterThoeny
  • TWikiRegistration is done separately for Intranet use (depends on remote_user) or Internet use (depends on .htpasswd file).
• 20 Mar 2000 - TWiki:Main.PeterThoeny
  • Uploading a file (topic file attachment) will optionally create a link to the uploaded file at the end of the topic. The preference setting %ATTACHLINKBOX% controls the default state of the link check box in the attach file page.
• 11 Mar 2000 - TWiki:Main.PeterThoeny
  • Better security with taint checking ( Perl -T option )
• 25 Feb 2000 - TWiki:Main.PeterThoeny
  • New preference settings %EDITBOXWIDTH% and %EDITBOXHEIGHT% to specify the edit box size.
• 25 Feb 2000 - TWiki:Main.PeterThoeny
  • Edit preferences topics to set TWiki variables. There are three level of preferences Site-level (TWikiPreferences), web-level (WebPreferences in each web) and user-level preferences (for each of the Main.WikiUsers). With this, discontinue use of server side include of wikiwebs.inc , wikiwebtable.inc , weblist.inc , webcopyright.inc and webcolors.inc files.
• 11 Feb 2000 - TWiki:Main.PeterThoeny
  • New variable %SCRIPTSUFFIX% / $scriptSuffix containing an optional file extension of the TWiki Perl script. Templates have been changed to use this variable. This allows you to rename the Perl script files to have a file extension like for example ".cgi".
• 11 Feb 2000 - TWiki:Main.PeterThoeny
  • New variable %SCRIPTURLPATH% / $scriptUrlPath containing the script URL without the domain name. Templates have been changed to use this variable instead of %SCRIPTURL% . This is for performance reasons.
• 07 Feb 2000 - TWiki:Main.PeterThoeny
  • Changed the syntax for server side include variable from %INCLUDE:"filename.ext"% to %INCLUDE{"filename.ext"}% . (Previous syntax still supported. Change was done because of inline search syntax)
• 07 Feb 2000 - TWiki:Main.PeterThoeny
  • Inline search. New variable %SEARCH{"str" ...}% to show a search result embedded in a topic text. TWikiVariables has more on the syntax. Inline search combined with the category table feature can be used for example to create a simple bug tracking system.
• 04 Feb 2000 - TWiki:Main.PeterThoeny
  • Access statistics. Each web has a WebStatistics topic that shows monthy statistics with number of topic views and changes, most popular topics, and top contributors. (It needs to be enabled, CompleteDocumentation has more.)
• 29 Jan 2000 - TWiki:Main.PeterThoeny
  • Fixed bug where TWiki would not initialize correctly under certain circumstances, i.e. when running it under mod_perl. Sub initialize in wiki.pm did not handle $thePathInfo correctly.
• 24 Jan 2000 - TWiki:Main.PeterThoeny
  • Fixed bug where an e-mail address starting with a WikiName was rendered as an internal Wiki link instead of an e-mail address, i.e. SomeWikiName@somewhere.test .
• 10 Jan 2000 - TWiki:Main.PeterThoeny
  • No more escaping for '%' percent characters. (Number of consecutive '%' entered and displayed is identical.)
• 03 Oct 1999 - TWiki:Main.PeterThoeny
  • Limit the number of revisions shown at the bottom of the topic. Example
    Topic ReleaseHistory . { ..... Diffs r1.10 > r1.9 > r1.8 > r1.7 >... }
    Additional revisions can be selected by pressing the >... link.

01-Sep-1999 Release

• 31 Aug 1999 - TWiki:Main.PeterThoeny
  • Fixed Y2K bug. (Date in year 2000 had wrong format.)
• 08 Aug 1999 - TWiki:Main.PeterThoeny
  • New text formatting rule for creating tables. Text gets rendered as a table if enclosed in " " vertical bars. Example line as it is written and how it shows up
• 03 Aug 1999 - TWiki:Main.PeterThoeny
  • Online registration of new user using web form in TWikiRegistration. Authentication of users.
• 22 Jul 1999 - TWiki:Main.PeterThoeny
  • Flags $doLogTopic* in wikicfg.pm to selectively log topic view, edit, save, rdiff, attach, search and changes to monthly log file.
• 21 Jul 1999 - TWiki:Main.PeterThoeny
  • Flag $doRemovePortNumber in wikicfg.pm to optionally remove the port number from the TWiki URL. Example www.some.domain:1234/twiki gets www.some.domain/twiki .
• 15 Jul 1999 - TWiki:Main.PeterThoeny
  • Search path for include files in %INCLUDE:"file.inc"% variable. Search first in the current web, then in parent data directory. Useful to overload default include text in the data directory by web-specific text, like for example webcopyright.inc text.
• 07 Jul 1999 - TWiki:Main.ChristopheVermeulen
  • Link a plural topic to a singular topic in case the plural topic does not exist. Example TestVersion / TestVersions , TestPolicy / TestPolicies , TestAddress / TestAddresses , TestBox / TestBoxes .

01-Jul-1999 Release

• 23 Jun 1999 - TWiki:Main.PeterThoeny
  • New TextFormattingRules to write bold italic text by enclosing words with double underline characters.
• 23 Jun 1999 - TWiki:Main.PeterThoeny
  • Separate wiki.pm into configuration (wikicfg.pm) and TWiki core (wiki.pm) . This is to ease the upgrade of TWiki installations, it also allows customized extensions to TWiki without affecting the TWiki core.
• 21 May 1999 - TWiki:Main.DavidWarman
  • Externalize copyright text at the bottom of every page into a web-specific webcopyright.inc file. This is to easily customize the copyright text.
• 20 May 1999 - TWiki:Main.PeterThoeny
  • Added meta tag so that robots index only /view/ of topics, not /edit/, /attach/ e.t.c. Tag <META NAME="ROBOTS" CONTENT="NOINDEX">
• 20 May 1999 - TWiki:Main.PeterThoeny
  • New variables %WIKIHOMEURL% (link when pressing the icon on the upper left corner) and %WIKITOOLNAME% (the name of the wiki tool BACCHUS Wiki ).
• 15 Apr 1999 - TWiki:Main.PeterThoeny
  • Topic locking Warn user if a topic has been edited by an other person within one hour. This is to prevent contention, e.g. simultaneous topic updates.
• 26 Mar 1999 - TWiki:Main.PeterThoeny
  • File attachments Upload and download any file as a topic attachment by using the browser. FileAttachment has more.
• 26 Mar 1999 - TWiki:Main.PeterThoeny
  • New variables %PUBURL% (Public directory URL) and %ATTACHURL% (URL of topic file attachment).
• 09 Feb 1999 - TWiki:Main.PeterThoeny
  • New text formatting rule for creating fixed font text . Words get showns in fixed font by enclosing them in "=" equal signs. Example Writing =fixed font= will show up as fixed font .
• 09 Feb 1999 - TWiki:Main.PeterThoeny
  • No new topic revision is created if the same person saves a topic again within one hour.
• 03 Feb 1999 - TWiki:Main.PeterThoeny
  • Possible to view complete revision history of a topic on one page. Access at the linked date in the Changes page, or the Diffs link at the bottom of each topic, e.g.
    Topic TWikiHistory . { Edit Ref-By Diffs r1.3 > r1.2 > r1.1 }
    Revision r1.3 1998/11/10 01:34 by PeterThoeny
• 04 Jan 1999 - TWiki:Main.PeterThoeny
  • Fixed bug when viewing differences between topic revisions that include HTML table tags like <table>, <tr>, <td>.

1998 Releases

• 08 Dec 1998 - TWiki:Main.PeterThoeny
  • Signature is shown below the text area when editing a topic. Use this to easily copy & paste your signature into the text.
• 07 Dec 1998 - TWiki:Main.PeterThoeny
  • Possible to add a category table to a TWiki topic. This permits storing and searching for more structured information. Editing a topic shows a HTML form with the usual text area and a table with selectors, checkboxes, radio buttons and text fields. CompleteDocumentation has more on setup. The TWiki.Know web uses this category table to set classification, platform and OS version.
• 18 Nov 1998 - TWiki:Main.PeterThoeny
  • Internal log of topic save actions to the file data/logYYYYMM.txt, where YYYYMM the year and month in numeric format is. Intended for auditing only, not accessible from the web.
• 10 Nov 1998 - TWiki:Main.PeterThoeny
  • The e-mail notification and the Changes topic have now a topic date that is linked. Clicking on the link will show the difference between the two most recent topic revisions.
• 10 Nov 1998 - TWiki:Main.PeterThoeny
  • View differences between topic revisions. Each topic has a list of revisions (e.g. r1.3) and differences thereof (e.g. >) at the bottom
    Topic TWikiHistory . { Edit Ref-By r1.3 > r1.2 > r1.1 }
    Revision r1.3 1998/11/10 01:34 by TWiki:Main.PeterThoeny
• 26 Oct 1998 - TWiki:Main.PeterThoeny
  • Added preview of topic changes before saving the topic. This was necessary to prevent unneeded revisions.
• 26 Oct 1998 - TWiki:Main.PeterThoeny
  • Added revision control using RCS. Each topic has now a list of revisions at the bottom and a revision info, e.g.
    Topic TWikiHistory . { Edit Ref-By r1.3 r1.2 r1.1 }
    Revision r1.3 1998/10/26 01:34:00 by TWiki:Main.PeterThoeny
• 14 Oct 1998 - TWiki:Main.PeterThoeny
  • Refered-By Find out which topics have a link to the current topic. Each topic has a Ref-By link for that. Note Only references from the current web are shown, not references from other webs.
• 13 Oct 1998 - TWiki:Main.PeterThoeny
  • Alphabetical topic index in WebSearch.
• 24 Sep 1998 - TWiki:Main.PeterThoeny
  • Corrected templates for automatic e-mail notification so that MS Outlook can display attachment as an HTML file.
• 13 Aug 1998 - TWiki:Main.PeterThoeny
  • WikiNotation allows also numbers after the AaA sequence, e.g. AaA1 is a valid TWikiTopics name, but not Aa1.
• 07 Aug 1998 - TWiki:Main.PeterThoeny
  • Automatic e-mail notification when something has changed in a TWiki web. Each web has a topic WebNotify where one can subscribe and unsubscribe.
• 06 Aug 1998 - TWiki:Main.PeterThoeny
  • Added server side include of files. Syntax is %INCLUDE:"filename.ext"%
• 05 Aug 1998 - TWiki:Main.PeterThoeny
  • Signature and date is inserted automatically when creating a new topic.
• 04 Aug 1998 - TWiki:Main.PeterThoeny
  • Separate templates for text of non existing topic and default text of new topic. (template file templates/Web/notedited.tmpl)
• 04 Aug 1998 - TWiki:Main.PeterThoeny
  • Warn user if new topic name is not a valid Wiki name. (template file templates/Web/nofoswiki.tmpl)
• 31 Jul 1998 - TWiki:Main.PeterThoeny
  • Support for quoted text with a '>' at the beginning of the line.
• 28 Jul 1998 - TWiki:Main.PeterThoeny
  • Added TWiki variables, enclosed in % signs %TOPIC% (Topic name), %WEB% (web name), %SCRIPTURL% (script URL), %DATE% (current date), %WIKIWEBMASTER% (Wiki webmaster address), %WIKIVERSION% (Wiki version), %USERNAME% (user name), %WIKIUSERNAME% (Wiki user name).
• 28 Jul 1998 - TWiki:Main.PeterThoeny
  • Topic WebChanges shows Wiki username instead of Intranet username, e.g. PeterThoeny instead of thoeny in case the Wiki username exists. Implementation Automatic lookup of Wiki username in topic Main.WikiUsers.
• 28 Jul 1998 - TWiki:Main.PeterThoeny
  • Topic index. (Technically speaking a simple '.*' search on topic names.)
• 28 Jul 1998 - TWiki:Main.PeterThoeny
  • Topic WebSearch allows full text search and and topic search with/without regular expressions.
• 27 Jul 1998 - TWiki:Main.PeterThoeny
  • Added automatic links to topics in other TWiki webs by specifying <web name>.<topic name>, e.g. Know.WebSeach .
• 23 Jul 1998 - TWiki:Main.PeterThoeny
  • Installed initial version, based on the JOS Wiki. See WikiWikiClones for details.

Dev Flow

The typical TWiki development flow...

• TWiki:Codev.FeatureBrainstorming: open forum for new ideas
• TWiki:Codev.FeatureEnhancementRequest: specific detailed request
• TWiki:Codev.FeatureToDo: prioritized to up-next dev status
• TWiki:Codev.FeatureUnderConstruction: currently in development
• TWiki:Codev.FeatureDone: completed and implemented
• TWiki:Codev.DocRequest: request for documentation
• TWiki:Codev.DocsToDo: feature documentation pending
• TWiki:Codev.FeatureDocumented: documented feature
• ReferenceManual: reference manual for the latest TWiki

Back to top

---

Appendix B: Encode URLs With UTF8

Use internationalised characters within WikiWords and attachment names

Current Status

To simplify use of internationalised characters within WikiWords and attachment names, Foswiki supports UTF-8 URLs, converting on-the-fly to virtually any character set, including ISO-8859-*, KOI8-R, EUC-JP, and so on.

Support for UTF-8 URL encoding avoids having to configure the browser to turn off this encoding in URLs (the default in Internet Explorer, Opera Browser and some Mozilla Browser URLs) and enables support of browsers where only this mode is supported (e.g. Opera Browser for Symbian smartphones). A non-UTF-8 site character set (e.g. ISO-8859-*) is still used within Foswiki, and in fact pages are stored and viewed entirely in the site character set - the browser dynamically converts URLs from the site character set into UTF-8, and Foswiki converts them back again.

System requirements are updated as follows:

• ASCII or ISO-8859-1-only sites do not require any additional CPAN modules to be installed.
• Perl 5.8 sites using any character set do not require additional modules, since CPAN:Encode is installed as part of Perl.
• This feature still works on Perl 5.005_03 as per SystemRequirements, or Perl 5.6, as long as CPAN:Unicode::MapUTF8 is installed.

The following 'non-ASCII-safe' character encodings are now excluded from use as the site character set, since they interfere with Foswiki markup: ISO-2022-*, HZ-*, Shift-JIS, MS-Kanji, GB2312, GBK, GB18030, Johab and UHC. However, many multi-byte character sets work fine, e.g. EUC-JP, EUC-KR, EUC-TW, and EUC-CN. In addition, UTF-8 can already be used, with some limitations, for East Asian languages where EUC character encodings are not acceptable.

It's now possible to override the site character set defined in the {SiteLocale} setting in configure - this enables you to have a slightly different spelling of the character set in the server locale (e.g. 'eucjp') and the HTTP header sent to the browser (e.g. 'euc-jp').

Details of Implementation

URLs are not allowed to contain non-ASCII (8th bit set) characters: http://www.w3.org/TR/html4/appendix/notes.html#non-ascii-chars

UTF-8 URL translation to virtually any character set is supported, but full UTF-8 support (e.g. pages in UTF-8) is not supported yet.

The code automatically detects whether a URL is UTF-8 or not, taking care to avoid over-long and illegal UTF-8 encodings that could introduce security issues (tested against a comprehensive UTF-8 test file, which IE 5.5 fails quite dangerously, and Opera Browser passes). Any non-ASCII URLs that are not valid UTF-8 are then assumed to be directly URL-encoded as a single-byte or multi-byte character set (as now), e.g. EUC-JP.

The main point is that you can use Foswiki with international characters in WikiWords without changing your browser setup from the default, and you can also still use Foswiki using non-UTF-8 URLs. This works on any Perl version from 5.005_03 onwards. You can have different users using different URL formats transparently on the same server.

UTF-8 URLs are automatically converted to the current {Site}{Charset}, using modules such as CPAN:Encode if needed.

Foswiki generates the whole page in the site charset, e.g. ISO-8859-1 or EUC-JP, but the browser dynamically UTF-8 encodes the attachment's URL when it's used. Since Apache serves attachment downloads without Foswiki being involved, Foswiki's code can't do its UTF-8 decoding trick, so Foswiki URL-encodes such URLs in ISO-8859-1 or whatever when generating the page, to bypass this URL encoding, ensuring that the URLs and filenames seen by Apache remain in the site charset.

Back to top

---

Appendix C: CSS

Listing of CSS class names emitted from Foswiki core code and standard extensions.

Who should read this document?

Skin builders and others who want to change the appearance of the default installation or any of the skins can use this document to see what styles can be created for these html elements.

Naming conventions

1. All Foswiki class names have the prefix foswiki - for example: foswikiAlert, foswikiToc. This makes it less likely that our CSS classes will get in conflict with other Style Sheets. Remember that CSS class names are case sensitive - Foswiki CSS uses lowercase foswiki.
2. If you define your own CSS classes, it is preferable that you do not use the foswiki prefix to prevent undesired overriding effects.

A wide range of standard styles are used in the Foswiki core code and topics, and more are used in extensions. The following is an exhaustive list of all styles defined by Foswiki. For the most part, the names are the only documentation of the purpose of the style. For more information on how these styles are used, read the code (sorry!)

CSS class names

Structural elements

.foswikiPage	The container for the complete page contents, just below the body tag (only used by default templates)
.foswikiMain	The container for the main contents, usually including the header (only used by default templates)
.foswikiTopic	The container for the topic contents
.foswikiTable	Tables, for instance used by TablePlugin
.foswikiForm	Container for data form in topic, including header; see also Data Forms below
.foswikiAttachments	Container for attachments table, including header
table#foswikiAttachmentsTable	Identifier for the attachment table
.foswikiFormSteps	Container around a form that contains a number of separate 'steps'; each 'step' in a separate row
.foswikiFormStep	Form step row
.foswikiLast	Last step (always in combination with foswikiFormStep); sometimes used as last table row
.foswikiHorizontalList	Container around horizontal bullet list (.foswikiHorizontalList ul)
li.foswikiLast	Last element of a horizontal list
.foswikiBroadcastMessage	Site-wide message block; contents set in System.DefaultPreferences; custom set in Main.SitePreferences
.foswikiNotification	Temporary alert, for instance after user actions; used as wrapper around %FLASHNOTE%
.foswikiMessage	Permanent/semi-permanent message.
.foswikiContentHeader	Optional container around text placed above topic text
.foswikiContentFooter	Optional container around text placed below topic text
.foswikiFooterNote	Text below topic text; for instance with parent or "topic moved" message
#foswikiLogin	Login box
#foswikiLogo	Logo
.foswikiPreviewArea	Container around topic preview
.foswikiTopicActions	Topic Actions list
.foswikiTopicInfo	Topic Info section containing REVINFO
.foswikiTopicText	The rendered Topic text
.foswikiTabs	Container for tabs (styled bullet list, .foswikiTabs ul)
li.foswikiActiveTab	Active tab
.foswikiTabContent	Container for content below tabs

General appearance

.foswikiLeft	Left float
.foswikiRight	Right float
.foswikiClear	Clear float; usually written as <div class="foswikiClear"></div>
.foswikiAlert	Warnings and alert messages; general red text
.foswikiHelp	Help text block
.foswikiGrayText	Grayed out text; text of less importance
.foswikiToc	Table of Contents block
.foswikiTocTitle	Title text of Table of Contents
.foswikiHidden	Hidden elements
.foswikiSmall	Small text
.foswikiSmallish	Somewhat less smaller text; inbetween normal and small
.foswikiLarge	Large text, for instance for introduction paragraphs
.foswikiNoBreak	Causes whitespace not to create a linebreak; for instance with the dates in the attachment table
.foswikiJs	Added to the html tag if the browser has javascript enabled.
.foswikiMakeVisible	For elements that should only be visible with JavaScript on: default set to hidden, is made visible by JavaScript
.foswikiMakeVisibleInline	DEPRECATED as of Foswiki 1.1.0: use span.foswikiMakeVisible. For span elements that should only be visible with JavaScript on: default set to hidden, is made visible by JavaScript
.foswikiMakeVisibleBlock	DEPRECATED as of Foswiki 1.1.0: use div.foswikiMakeVisible. For div elements that should only be visible with JavaScript on: default set to hidden, is made visible by JavaScript
.foswikiMakeHidden	For elements that should be hidden with JavaScript on: no default style, is made hidden by JavaScript
.foswikiImage	Holder form images; for instance to create a border around an <img> element
.foswikiUserName	Container around user name links (not used much yet)

Links

.foswikiCurrentWebHomeLink	Used by Render.pm if a link points to the web's home topic
.foswikiCurrentTopicLink	Used by Render.pm if a link points to the current topic
.foswikiEmulatedLink	Used in the preview screen to make fake links appear as links
.foswikiLinkLabel	Text part of a link; used if a link contains more than a text label, for instance an icon
.foswikiUnvisited	Makes link appear as not visited (ignores the visited link state)
.foswikiRequiresChangePermission	To mark links to actions that the user does not have permissions for (for instance to hide action links)

Tables

.foswikiFirstCol	Leftmost column
.foswikiLastCol	Rightmost column
.foswikiSortedCol	Sorted column
.foswikiSortedAscendingCol	Sorted column, ascending
.foswikiSortedDescendingCol	Sorted column, descending
.foswikiTopRow	First row in search results; also used for styling first table rows (td.foswikiTopRow)
.foswikiTableEven	Even numbered rows
.foswikiTableOdd	Odd numbered rows
.foswikiTableCol + column number	Unique column identifier, for instance: foswikiTableCol0
.foswikiTableRow + type + row number	Unique row identifier, for instance: foswikiTableRowdataBg0
.tableSortIcon	Holder (span) for the table column sort icon

Data Forms

.foswikiForm	Container for data form in topic, including header
.foswikiFormHolder	Outer container for the data form in edit; contains the textarea width
.foswikiFormTable	Table container for (editable) form elements
.foswikiFormTableHRow	Table container for (editable) form elements
.foswikiFormTableRow	Table container for form elements
.foswikiFormTableFooter	Table container for form elements
.foswikiEditForm	Edit state of data form
.foswikiMandatory	Indication of mandatory field
.foswikiAddFormButton	"Add form" button on edit screen

HTML Forms

.foswikiPageForm	Container for the form on the page
.foswikiButton	Normal button
.foswikiButtonDisabled	Disabled normal button
.foswikiSubmit	Submit button
.foswikiSubmitDisabled	Disabled submit button
.foswikiButtonCancel	Cancel button
.foswikiInputField	Text input field
.foswikiInputFieldDisabled	Disabled text input field
.foswikiInputFieldReadOnly	Read-only text input field
.foswikiInputFieldFocus	Text input field with insert focus; for Internet Explorer that does not recognize the :focus pseudo class selector
.foswikiInputFieldBeforeFocus	The color of the input text field when not clicked in the field; usually a grayed text color with a hint, for instance "Search"
.foswikiRadioButton	Radio button
.foswikiCheckbox	Checkbox
.foswikiSelect	Select dropdown menu
.foswikiSelectDisabled	Disabled dropdown menu
.foswikiOption	Dropdown option element
.foswikiTextarea	Textarea
.foswikiTextareaRawView	Raw topic view textarea

Search

.foswikiSearchResults	List of search results
.foswikiSearchResult	Search result with title, summary, author and date
.foswikiSearchResultsHeader	Search results header with search string, number of hits
.foswikiSearchResultsPager	Search results pagination
.foswikiSummary	Summary of search results
.foswikiSummary em	Highlighted search term in summary
.foswikiNew	Identifier of new topics: topics without a revision history
.foswikiTopRow	First row in search results; also used for styling first table rows (td.foswikiTopRow)
.foswikiBottomRow	Last row in search results
.foswikiSRRev	Revision number in search results listing
.foswikiSRAuthor	Author in search results listing
.foswikiSearchResultCount	Search results count
#foswikiNumberOfResultsContainer	See Behaviour classes below
.foswikiWebSearchForm	Container around the search form

History

.foswikiDiffTable	Revision table
.foswikiMarker	Demarkation of part
.foswikiDiffDeletedMarker	Demarkation of part that has been deleted
.foswikiDiffDeletedText	Demarkation of part that has been deleted
.foswikiDiffAddedHeader	Demarkation of part that has been added
.foswikiDiffAddedMarker	Demarkation of part that has been added
.foswikiDiffAddedText	Demarkation of part that has been added
.foswikiDiffChangedHeader	Demarkation of part that has been changed
.foswikiDiffChangedText	Demarkation of part that has been changed
.foswikiDiffUnchangedMarker	Demarkation of part that has been unchanged
.foswikiDiffUnchangedText	Demarkation of part that has been unchanged
.foswikiDiffUnchangedTextContents	Demarkation of part that has been unchanged
.foswikiDiffLineNumberHeader
.foswikiDiffDebug
.foswikiDiffDebugRight
.foswikiDiffDebugLeft

Behaviour classes

Markers to invoke behaviour with unobtrusive JavaScript.

.foswikiFocus	Behaviour marker so a field can be given input focus. As of Foswiki 1.2 this also requires to add %JQREQUIRE{"focus"}% to the page.
.foswikiChangeFormButton	"Replace form" button; clicking calls JavaScript function suppressSaveValidation
#foswikiNumberOfResultsContainer	Container identifier to write the number of search results into
input[type="text"].foswikiDefaultText	Behaviour marker so the field will contain default text that disappears when clicked into. The visual style is set with foswikiInputFieldBeforeFocus and foswikiInputFieldFocus. The default text is provided by the title attribute of the form field.
.foswikiPopUp	Behaviour marker so a popup-window can be invoked. DEPRECATED as of Foswiki 1.1: use %POPUPWINDOW{"topic"}% instead.

Troubleshooting behaviour classes

.foswikiFocus

• Test for loading error of focus plugin (no message means ok):
• Test foswikiFocus

Various classes

.foswikiWebIndent	Used by %WEBLIST% to indent sub-web names
.foswikiAccessKey	Access key demarkation
.foswikiSeparator	Separator element between sequential elements; usually a pipe character
.foswikiActionFormStepSign	Indicator for each form step (see foswikiFormStep)
.foswikiEditboxStyleMono	Gives the edit textarea monospaced font (not used with WYSWIWYG)
.foswikiEditboxStyleProportional	Gives the edit textarea proportional font (not used with WYSWIWYG)
p.foswikiAllowNonWikiWord	Message "Allow non WikiWord for the new topic name"
.foswikiIcon	Span around icon image

Tips

PatternSkin makes extensive use of CSS in its templates. Read the PatternSkin topic and PatternSkinCss to learn more about creating your own CSS-based skin.

Practical introduction to CSS: http://www.w3.org/Style/LieBos2e/enter/

---

Related Topics: Skins, PatternSkin, DeveloperDocumentationCategory, AdminDocumentationCategory

Back to top