TWiki Reference Manual (TWiki-6.0.2, Sun, 29 Nov 2015, build 29687)

TWiki Installation Guide

The following is installation instructions for the TWiki-6.0 production release on an Apache web server on Linux. Visit TWiki:TWiki.InstallingTWiki for the latest updates to this guide and supplemental information for installing or upgrading TWiki, including notes on installing TWiki on different platforms, environments and web hosting sites.

If you are upgrading from a previous version of TWiki, you probably want to read TWikiUpgradeGuide instead.

Preparing to install TWiki

Before attempting to install TWiki, you are encouraged to review the AdminSkillsAssumptions. This guide assumes you have, at a minimum, basic knowledge of server administration on the system on which TWiki is to be installed. While it is possible to install TWiki 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).

To help setup a correct Apache configuration, you are very much encouraged to use the automatic tool TWiki:TWiki.ApacheConfigGenerator which generates the contents for an Apache config file for TWiki based on your inputs.

While this installation guide specifically describes installation on an Apache web server on Linux, TWiki should work fine with any web server and OS that meet the system requirements (see below). For additional notes on installing TWiki on other systems, see TWiki:TWiki.InstallingTWiki#OtherPlatforms.

If you are installing TWiki without Unix/Linux root (administrator) privileges (for example, on a hosted domain), see "Notes on Installing TWiki on Non-Root Account" below for supplemental instructions to the basic steps presented below.

If you are upgrading from an earlier major version of TWiki such as Cairo (TWiki-3) or TWiki 4.x you will need the information found at TWikiUpgradeGuide.

One of the more difficult tasks is installation of additional CPAN libraries. See TWiki:TWiki.HowToInstallCpanModules for detailed information on how to install CPAN libraries.

If you need help, ask a question in the TWiki:Support.WebHome web or on TWiki:Codev.TWikiIRC (irc.freenode.net, channel #twiki).

Basic Installation

1. Download the TWiki distribution from http://TWiki.org/. (Example - download TWiki-6.0.1.tgz for Linux)
2. Copy the downloaded package into the directory where you want to install TWiki (Example: /var/www). Unpack the distribution in it (Example: tar xvfz TWiki-6.0.1.tgz). The unpack will create a directory called twiki which contains the TWiki package. In the rest of this document we assume this directory is called twiki.
   • Note: TWiki does not allow spaces in directory names. Especially on Windows make sure to use a directory path without spaces.
3. Setup access file and directory rights to enable the webserver user (the user Apache runs the CGI scripts as) to read and write inside the twiki directory.
   • Warning: Do not just run a chmod -R 770 twiki. The access rules have different meaning for files and directories. This is the most common mistake installers make.
   • The distribution tgz has the file and directory access rights setup to work with a reasonable security level that will work for all types of installations including shared hosting.
   • The ownership of the twiki directory tree is normally set to the user that unpacked the tgz and will have to be changed to the webserver user using the command chown -R user:group /path/to/twiki. The webserver username varies from Distributions. Examples for some major distributions:
     • RedHat, Fedora, CentOS, Gentoo, Mandriva : chown -R apache:apache /path/to/twiki
     • debian/Ubuntu/Kubunto : chown -R www-data:www-data /path/to/twiki
     • Suse : chown -R wwwrun:www /path/to/twiki
   • If you mistakenly change the access rights in a way that makes TWiki stop working, simply run the script found at TWiki:TWiki.SettingFileAccessRightsLinuxUnix to set the access rights of the entire TWiki tree back to the defaults in the distribution.
   • It is possible to define tighter access rules than the ones given by default after the installation is complete. But how tight they should be depends on your distribution and local needs. Typically you may want to limit all access from world if the webserver machine has login access for other users than root and the web server administrator. For a dedicated web server made just for running TWiki with limited login access the default access rights are reasonable.
4. Check the Perl installation and CPAN dependencies. Ensure that Perl 5 and the Perl CGI library are installed on your system.
   • The default location of Perl is /usr/bin/perl. If it's somewhere else, change the path to Perl in the first line of each script in the twiki/bin directory.
   • Check if required modules listed in TWikiSystemRequirements are present; install modules as needed. For example, Ubuntu does not have the Perl CGI library, you need to install it with apt-get install libcgi-pm-perl. If needed, learn how to install CPAN modules.
   • Some systems require a special extension on perl scripts (e.g. .cgi or .pl). This is normally only needed under Windows and only where perl scripts are only recognized by file extension. Linux and Unix users should normally never need to do this. If necessary, rename all files in twiki/bin (i.e. rename view to view.pl etc). If you do this, make sure you set the ScriptSuffix option in configure (Step 6).
5. Create the file LocalLib.cfg located as twiki/bin/LocalLib.cfg
   • There is a template for this file in twiki/bin/LocalLib.cfg.txt. Simply copy LocalLib.cfg.txt to LocalLib.cfg. Make sure the ownership and access rights of the copy are the same as LocalLib.cfg.txt
   • The file twiki/bin/LocalLib.cfg must contain a setting for $twikiLibPath, which must point to the absolute directory path of your twiki/lib e.g. /var/www/twiki/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 webserver user has to be able to read those files as well.
6. Choose best configuration method for your webserver. There are two ways to configure Apache: 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 TWiki configuration in ONE file (typically named twiki.conf). Performance is much better with a config file, and makes setting up a correct and safe installation easier. However using a config file requires that you can restart Apache which again means that you need root or sudo access to stop and start Apache. The TWiki apache config file is included from the main Apache config file httpd.conf. 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). If you use a virtual host setup in Apache you should include the twiki.conf file from inside the desired virtual host config in your Apache configuration.
   • .htaccess files: This option should only be used when you cannot use a config file. Performance is slowed down because Apache has to look through all directories in search of possible .htaccess files each time someone views a page in TWiki. Normally this is the only way to control Apache in a shared host environment where you have no root or sudo privileges.
7. Configure the webserver
   • Unless you are an Apache expert setting up the webserver can be quite difficult. But TWiki has three resources that make setting up Apache easier.
     • The best and easiest way is to use webpage TWiki:TWiki.ApacheConfigGenerator which contains a tool that can generate a safe and working config file for TWiki on Apache.
     • In the twiki installation you find an example config file misc/twiki_httpd_conf.txt (nevertheless, it is better to use the generator).
   • In case you do not have root privileges on the server:
     • In the root of the twiki installation and in the twiki/bin directory you find example .htaccess files you can copy and modify. The files contains help text explaining how to set them up. In twiki/bin you find .htaccess.txt which can be copied to .htaccess and defined access to the CGI scripts.
     • In the TWiki misc directory you find pub-htaccess.txt which you can copy to pub/.htaccess, subdir-htaccess.txt which you can copy to all directories as .htaccess except bin and pub, and you find root-htaccess.txt which you can copy to .htaccess in the twiki root directory. But again only use .htaccess files if you do not have root privileges.
   • If you are unsure about how to do this on your system, see TWiki:TWiki.InstallingTWiki#OtherPlatforms for links to information about various server setups.
   • Note: When you use config files you need to restart Apache each time you change a setting to make the new setting active.
8. Run the configure script from your browser (enter http://yourdomain/do/configure into your browser address bar)
   • Specify and reenter a password. This is your configure password, as well as the admin user password once TWiki is running.
     • Note: In case you forgot the password, you can reset it by deleting $TWiki::cfg{Password} from LocalSite.cfg file from {TWIKI_ROOT}/lib directory.
   • When you run configure for the first time, you can only edit the General Path Settings section. Save these settings, and then return to configure to continue configuration.
   • Resolve any errors or warnings it tells you about.
   • If your webserver can be accessed by more than one domain name make sure to add the additional alternative URLs to {PermittedRedirectHostUrls}
   • When you return to configure you now need to setup Mail and Proxies. Especially the {WebMasterEmail}, and {SMTP}{MAILHOST} must be defined to enable TWiki to send administrative emails, such as for registration and notification of topic changes. Many ISPs have introduced authentication when sending emails to fight spam so you may also have to set {SMTP}{Username} and {SMTP}{Password}. If you do not want to enable mailing or want to enable it later you can uncheck {EnableEmail}.
   • If you want administrative e-mails to be signed, see S/MIME setup instructions below.

You now have a basic, unauthenticated installation running. At this point you can just point your web browser at http://yourdomain.com/do/view and start TWiki-ing away!

Important Server Security Settings

Before you continue any further there are some basic and very important security settings you have to make sure are set correctly.

1. You absolutely must turn off any kind of PHP, Perl, Python, Server Side Includes etc in the pub directory. TWiki has some built-in protection which renames files with dangerous file names by appending .txt to the file name. But this is a secondary security measure. The essential action that you must take is to turn off any possible execution of any of the attached files.
   Most Linux distributions have a default Apache installation which has PHP and server side include (SSI) enabled.
2. Don't put the whole twiki distribution into an HTML document enabled directory. Apache needs to be aware of only two directories: The bin directory should be script enabled, and the pub directory should be HTML document enabled.
   For those who do not have access to the Apache config files, a sample misc/subdir-htaccess.txt file can be copied as .htaccess to the data, lib, locale, templates, tools and working directories.
3. Attachments are not secured by default to the access control setting of the topic. In other words, anyone can read them if they know the direct URL of the attachment, which includes name of the web, topic and attachment. You can configure TWiki to secure attachments.

The TWiki:TWiki.ApacheConfigGenerator as well as the example misc/twiki_httpd_conf.txt and example misc/htaccess.txt files include the needed settings that protect against all 3 security elements.

Next Steps

Once you have TWiki installed and running, you might consider the following optional steps for setting up and customizing your TWiki site. Many of the references below refer to topics within your TWiki installation. For example, TWiki.TWikiSkins refers to the TWikiSkins topic in your TWiki web. Easy way to jump directly to view the pages is to open your own TWiki in your browser and write TWiki.TWikiSkins in the Jump test box to the right in the top bar and hit Enter. You can find these topics in the on-line reference copy at the official TWiki website: TWiki-6.0 Release.

Enable Authentication of Users

This step provides for site access control and user activity tracking on your TWiki site. This is particularly important for sites that are publicly accessible on the web. This guide describes only the most common of several possible authentication setups for TWiki and is suitable for public web sites. For information about other setups, see TWikiUserAuthentication, and TWiki:TWiki.TWikiUserAuthenticationSupplement.

These are the steps for enabling "Template Login" which asks for a username and password in a web page, and processes them using the Apache 'htpasswd' password manager. Users can log in and log out.

1. Under the Security Settings pane of configure :
   1. Select TWiki::LoginManager::TemplateLogin for {LoginManager}.
   2. Select TWiki::Users::HtPasswdUser for {PasswordManager}.
   3. Save your configure settings.
   4. Register yourself using the TWikiRegistration topic.
      Check that the password manager recognizes the new user. Check that a new line with the username and encrypted password is added to the data/.htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
2. Edit a topic (by clicking on the Edit link at beginning or end of topic) to check if authentication works.

You are strongly encouraged to read TWikiUserAuthentication, TWiki:TWiki.TWikiUserAuthenticationSupplement, and TWiki:TWiki.SecuringTWikiSite for further information about managing users and security of your TWiki site.

Note: The other LoginManager option TWiki::LoginManager::ApacheLogin uses a basic Apache type authentication where the browser itself prompts you for username and password. Most will find the TemplateLogin looking nicer. But ApacheLogin is required when you use Apache authentication methods like mod_ldap where all authentication is handled by an Apache module and not by the TWiki perl code. When you use ApacheLogin the apache configuration must be set up to require authentication of the some but not all the scripts in the bin directory. This section in the Apache config (or .htaccess) controls this

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

The TWiki:TWiki.ApacheConfigGenerator includes this section when you choose ApacheLogin. In the example misc/twiki_httpd_conf.txt and bin/.htaccess.txt files this section is commented out with #. Uncomment the section when you use ApacheLogin. It is important that this section is commented out or removed when you use TemplateLogin.

Define the Administrator User(s)

Administrators have read and write access to any topic in TWiki, regardless of TWiki access controls. When you install TWiki one of the first things you will want to do is define yourself as an administrator. You become an administrator simply by adding yourself to the TWikiAdminGroup. It is the WikiName and not the login name you add to the group. Editing the Main.TWikiAdminGroup topic requires that you are an administrator. So to add the first administrator you need to login using the internal TWiki admin user login and the password you defined in configure.

• Navigate to the Main.TWikiAdminGroup topic
• Follow carefully the steps TWikiAdminGroup of how to become an admin
• Note that if you use ApacheLogin you have to be registered and logged in before you use the internal admin login

Set TWiki Preferences

Preferences for customizing many aspects of TWiki are set simply by editing a special topic with TWiki.

• TWikiPreferences. Read through it and identify any additional settings or changes you think you might need. You can edit the settings in TWiki.TWikiPreferences but these will be overwritten when you later upgrade to a newer TWiki version. Instead copy any settings or variables that you want to customize from TWiki.TWikiPreferences and paste them into Main.TWikiPreferences. When you later upgrade TWiki simply avoid overwriting the data/Main/TWikiPreferences.txt file and all your settings will be kept. Settings in Main.TWikiPreferences overrides settings in both TWiki.TWikiPreferences and any settings defined in plugin topics. See notes at the top of TWiki.TWikiPreferences for more information.

Enable Email Notification

Each TWiki 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 in the Configure interface.
2. Setup a cron job (or equivalent) to call the tools/mailnotify script as described in the MailerContrib topic.

Enable Signed Email Notification

TWiki administrative e-mails 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 TWiki to sign administrative e-mails:

1. Enable e-mail as described above
2. If necessary, convert your certificate and key files to PEM format ( openssl has all the necessary utilities)
3. 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
4. Place the key file in a secure location that only the webserver can read. It must not be readable by anyone else, and must not be served by the webserver.
5. Using the configure script, change the following settings under Mail and Proxies:
   1. Follow the directions under {MailProgram} to enable an external mail program such as sendmail. Net::SMTP is not supported.
   2. Enter the full path to the certificate file in the {SmimeCertificateFile} configuration variable
   3. Enter the full path to the private key file in the {SmimeKeyFile} configuration variable
   4. Save the configuration
6. Re-run the configure script an resolve any errors that it identifies

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

Enable WebStatistics

You can generate a listing manually, or on an automated schedule, of visits to individual pages on a per web basis. For information on setting up this feature, see the TWikiSiteTools topic.

Automate removal of expired sessions and lease files

Per default TWiki cleans out expired session and lease files each time any topic is viewed. This however comes at a cost of lower performance. It is an advantage to define a negative value in configure for {Sessions}{ExpireAfter} (turn on expert mode to see it), and install a cronjob to run the tools/tick_twiki.pl script. Read The topic TWikiScripts#tick_twiki_pl for details how to do this.

Enable Localization

TWiki now supports displaying of national (non-ascii) characters and presentation of basic interface elements in different languages. To enable these features, see the Localization section of configure. For more information about these features, see TWiki:TWiki.InternationalizationSupplement.

Tailor New User Profile Topic

When a new users registers on your TWiki, a user profile topic is created for them based on the NewUserTemplate topic (and its UserForm). It contains additional resources you can use to:

• Localize the user topic.
• Add and remove fields defined in the UserForm

If you choose to tailor anything you are strongly advised to copy NewUserTemplate and UserForm to the Main web and tailor the Main web copies. TWiki will look for the NewUserTemplate in the Main web first and if it does not exist TWiki uses the default from the TWiki web. By creating a Main.NewUserTemplate and its Main.UserForm you will not loose your customization next time you upgrade TWiki.

If you added or removed fields from the user form you may also want to tailor TWikiRegistration.

Custom Start Web and Homepage

By default the TWiki home is Main.WebHome. Users tend to create content starting from the homepage. In most cases it is better to create a new web (workspace) for default content. That way the Main web can be kept clean and used just for users and TWiki groups. For example, you could create an "Intranet" web if TWiki is primarily used as an intranet, or a "KB" web if used as a knowledge base, etc.

If you have a dedicated web as a starting point you obviously want users start at the home of that web. This can be configured in two places: 1. Redirect from site home to web home, and 2. Set the wiki logo URL.

1. Redirect from site home to web home

When a user enters the domain name of your TWiki she expects to see the homepage. You can do that either with an Apache rewrite rule or an HTML meta redirect to redirect from / to /do/view/Intranet/WebHome. Here is an example index.html containing an HTML meta redirect you can use: Customize it and put it in your HTML document root on your TWiki sever:

<html>
<head>
<meta http-equiv="refresh" content="0;/do/view/Intranet/WebHome" />
</head>
<body>
Redirecting to <a href="/do/view/Intranet/WebHome">Intranet home</a>...
</body>
</html>

2. Set the wiki logo URL

When a user clicks on the logo in the upper left or on the "Home" link in the top-bar she expects to navigate to the new homepage. You can do that by defining and customizing the following setting in Main.TWikiPreferences as described in the Set TWiki Preferences section:

URL of the logo:
   * Set WIKILOGOURL = %SCRIPTURLPATH{view}%/Intranet/WebHome

Customize the Look of Your TWiki!

The real power of TWiki lies in its flexibility to be customized to meet your needs. You can easily change the look of the default skins (called TopMenuSkin and PatternSkin) by reading the PatternSkinCustomization.

At the official TWiki website you can find more resources. A good place to start exploring what's possible is TWiki:TWiki.TWikiAdminCookBook which offers tips and tricks for customizing your TWiki site. Many of these are appropriate to implement immediately after installing TWiki and before adding content so now's a good time to look at these.

Customize Special Pages

Some pages are meant to be customized after choice of authentication. If you do not use the internal TWiki password manager the topics that contains the features for changing and resetting passwords and changing the email address should be changed to a note describing how to perform these tasks in your organization. The topics are:

• ChangePassword
• ResetPassword
• ChangeEmailAddress

Install Plugins

TWiki:Plugins.WebHome is an extensive library of plugins for TWiki, that enhance functionality in a huge number of ways. A few plugins are pre-installed in the TWiki distribution. For more information on these, see InstalledPlugins.

You activate installed plugin in the Plugins section of configure. In this section you also find a Find More Extensions button which opens an application which can install additional plugins from the TWiki.org website. If you are behind a firewall or your server has no access to the Internet it is also possible to install plugins manually. Manual installation instructions for the plugins can be found in the plugin topics on TWiki.org. Additional documentation on TWiki plugins can be found at TWiki:TWiki.TWikiPluginsSupplement.

Some plugins require that you define their settings in configure. You fill find these under the Extensions section of configure.

WYSIWYG And Raw Edit

From TWiki release 4.2.0 on the WYSIWYG editor has been replaced by a much better and more powerful editor and it was decided that WYSIWYG would be the default edit mode. An Edit Raw link is available for those that have a need or preference for this mode.

However you may prefer to have the same user interface as in TWiki 4.1 where Edit was the raw text editor and you had a WYSIWYG button. This is possible by adding the following setting in the Main.TWikiPreferences, WebPreferences or user hompages:

• Set EDITMETHOD = raw

Copyright, License and Classification Statements

At the bottom of each topic you will find a default copyright message saying "Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors." The WEBCOPYRIGHT setting defines this. This is often not adequate.

• If your TWiki is used in a commercial application without public access you should replace this by your normal copyright notice. You should also consider adding classifications (e.g. For Internal Use Only) so people do not have to add this manually to every new topic.
• If your TWiki is public with public access you need to decide which copyright and license the contributions should be covered by. For open source type applications licenses such as the GNU Free Documentation License, FreeBSD Documentation License, and Creative Commons license are possible licenses to consider. Remember that once people have started contributing it is difficult and not correct to change or impose licenses on existing contributions.

You change the copy right statement globally by taking these steps.

• Copy the setting WEBCOPYRIGHT from TWiki.TWikiPreferences to Main.TWikiPreferences and alter the copied text to your need.
• You can create a unique message for each web by adding the WEBCOPYRIGHT setting to WebPreferences in each web. E.g. adding a confidencial classification to a very restricted web.
• The WEBCOPYRIGHT in TWiki.WebPreferences covers the documentation that comes with TWiki and is covered by the original TWiki Copyright and GPL License. You will normally leave this unchanged.

Troubleshooting

The first step is to re-run the configure script and make sure you have resolved all errors, and are satisfied that you understand any warnings.

If, by any chance, you forget the "admin" password, the same used in "configure" script, then please login to the server. Delete $TWiki::cfg{Password}= ' ...';. Set the new password using "configure" script.

Failing that, please check TWiki:TWiki.InstallingTWiki on TWiki.org, the supplemental documentation that help you install TWiki on different platforms, environments and web hosting sites. For example:

• For Unix or Linux, check TWiki:Codev.TWikiOnUnix and TWiki:Codev.TWikiOnLinux.
• For Windows, check the TWiki:Codev.WindowsInstallCookbook.
• For MacOS X, check TWiki:Codev.TWikiOnMacOSX.

It is also advisable to review TWiki:Codev/KnownIssuesOfTWiki06x00.

If you need help, ask a question in the TWiki:Support web or on TWiki:Codev/TWikiIRC (irc.freenode.net, channel #twiki)

Appendices

TWiki System Requirements

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

Server Requirements

TWiki is written in Perl 5, uses a number of shell commands, and requires RCS (Revision Control System), a GNU Free Software package. TWiki is developed in a basic Linux/Apache environment. It also works with Microsoft Windows, and should have no problem on any other platform that meets the requirements.

Resource	Required Server Environment *
Perl	5.8.0 or higher (5.8.4 or higher is recommended)
RCS	5.7 or higher (including GNU diff) Optional, TWiki includes a pure Perl implementation of RCS that can be used instead (although it's slower)
GNU diff	GNU diff 2.7 or higher is required when not using the all-Perl RcsLite. Install on PATH if not included with RCS (check version with diff -v) Must be the version used by RCS, to avoid problems with binary attachments - RCS may have hard-coded path to diff
GNU df	Used by the site statistics to record disk usage statistics, optional. The df command is pre-installed on Linux and OS-X. On Windows install the CoreUtils for Windows.
GNU patch	For upgrades only: GNU patch is required when using the TWiki:Codev.UpgradeTWiki script
GNU fgrep, egrep	Modify command line parameters in configure if you use non-GNU grep programs
zip	Zip archive command line utility. Used by the BackupRestorePlugin to create and restore from backups.
Cron/scheduler	• Unix: cron • Windows: cron equivalents <-- SMELL: Macintosh version? -->
Web server	Apache is well supported; see TWiki:TWiki.InstallingTWiki#OtherWebServers for other servers

Required CPAN Modules

Most of the CPAN libraries listesd below are part of a standard Perl installation so you most likely have them all!

See TWiki:TWiki.HowToInstallCpanModules for detailed information on how to install CPAN libraries

The following Perl CPAN modules are used by TWiki:

Optional CPAN Modules

The following Perl modules may be used by TWiki:

See TWiki:TWiki.HowToInstallCpanModules for detailed information on how to install CPAN libraries

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"'

<--
SMELL: perhaps put download link to TWiki:Plugins.CpanContrib? (which 
also includes prebuilt versions of all of the CPAN modules used by 
all of the plugins checked into SVN)
-->

Client Requirements

The TWiki standard installation has relatively low browser requirements:

• HTML 3.2 compliant
• Cookies, if persistent sessions are required

CSS and Javascript are used in most skins, although there is a low-fat skin (Classic skin) available that minimizes these requirements. Some skins will require more recent releases of browsers. The default skin (Pattern) is tested on IE 6, Safari, and Mozilla 5.0 based browsers (such as Firefox).

<--
SMELL: what are some actual known good version number requirements for these browsers (eg, FireFox 1.0, or 1.0.3, or 1.0.7, or ???), etc.
-->

You can easily select a balance of browser capability versus look and feel. Try the installed skins at TWikiSkinBrowser and more at TWiki:Plugins.SkinPackage.

Important note about TWiki Plugins

• Plugins can require just about anything - browser-specific functions, stylesheets (CSS), Java applets, cookies, specific Perl modules,... - check the individual Plugin specs.

Notes on Installing TWiki on Non-Root Account

The following supplemental notes to the Basic Installation instructions apply to installing TWiki on a system where you don't have Unix/Linux root (administrator) privileges, for example, on a hosted Web account or an intranet server administered by someone else.

Referring to the Basic Installation steps presented above:

• Step 2: If you cannot unpack the TWiki distribution directly in your installation directory, you can unpack the distribution on your local PC and then 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 TWiki 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 twiki/lib directory at the same level as the twiki/bin directory (e.g. because CGI bin directories can't be under your home directory and you don't have root access). You can create this directory elsewhere and configure the twiki/bin/LocalLib.cfg file (done in Step 2).

    TWiki dir:	What it is:	Where to copy:	Example:
    twiki/	TWiki package	TWiki root directory, should be secure from public access	/home/smith/twiki/
    twiki/bin/	CGI bin	move to script-enabled dirctory	/home/smith/cgi/twiki/
    twiki/lib/	library files	leave in TWiki root	/home/smith/twiki/lib/
    twiki/locale/	language files	leave in TWiki root	/home/smith/twiki/locale/
    twiki/pub/	public files	move to HTML document enabled directory	/home/smith/html/twiki-pub/
    twiki/data/	topic data	leave in TWiki root	/home/smith/twiki/data/
    twiki/templates/	web templates	leave in TWiki root	/home/smith/twiki/templates/
    twiki/tools/	TWiki utlilities	leave in TWiki root	/home/smith/twiki/tools/
    twiki/working/	Temporary and internal files	leave in TWiki root	/home/smith/twiki/working/

• Step 3: Files in the pub directory must be readable as a url. This means that directory permissions should be set to 755 (or 775 ) and file permissions should be set to 644 (or 664). If you can run a chmod command, you can accomplish this in two quick steps by running these commands from the root direct:
  • chmod -R 755 pub
  • chmod 644 `find pub -type f -print`
  • In addition, you should create a .htaccess file in the pub directory, using the template included in the distribution entitled misc/pub-htaccess.txt.
  • Note: This setup does not provide for absolute security for TWiki attachments. For more information, see TWiki:Codev.SecuringYourTWiki.

• Step 6: In order to run the configure script, create a file called .htaccess in the bin directory that includes the following single line: SetHandler cgi-script . This informs the server to treat all the perl scripts in the bin directory as scripts.

For additional information about installing TWiki on a hosted accounts, see TWiki:TWiki.InstallingTWiki#WebHostingSites

Installing Manually Without Configure

It is highly recommended to use run configure from the browser when setting up TWiki. Configure does a lot of the hard work for you.

But there may be instances where you do not want to use configure or where configure simply won't run because of a missing dependency.

The manual steps you have to take are:

• Copy the file lib/TWiki.spec to lib/LocalSite.cfg
• Remove the comment # in front of $TWiki::cfg{DefaultUrlHost}, $TWiki::cfg{ScriptUrlPath}, $TWiki::cfg{PubUrlPath}, $TWiki::cfg{PubDir}, $TWiki::cfg{TemplateDir}, $TWiki::cfg{DataDir}, $TWiki::cfg{LocalesDir}, and $TWiki::cfg{OS} and make sure these settings have the correct values.
• Make sure to define at least these settings: $TWiki::cfg{LoginManager}, $TWiki::cfg{WebMasterEmail}, $TWiki::cfg{SMTP}{MAILHOST}, $TWiki::cfg{SMTP}{SENDERHOST}.

TWiki Upgrade Guide

This guide covers upgrading from a previous version of TWiki (such as TWiki-5.1) to TWiki-6.0

Overview

TWiki-6.0.0 is a major release that has a shiny new dashboard look. It brings many usability enhancements, strengthens TWiki as an application platform, and scales to very large deployments with thousands of webs and a million pages. Use this guide to upgrade a previous TWiki release to TWiki-6.0. Use the TWikiInstallationGuide if you do not have data to carry forward.

Upgrade Requirements

• Please review the AdminSkillsAssumptions before you upgrade TWiki
• Review supplemental document TWiki:TWiki.TWikiUpgradeTo06x00 for latest information and experience notes.
• To upgrade from a release prior to TWiki Release 01-Sep-2004, start with TWiki:TWiki.UpgradingTWiki on TWiki.org
• To upgrade from a standard TWiki Release 01-Sep-2004 to the latest TWiki-6.0 Production Release, follow the instructions below
• 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. Make sure you take a backup!

Major Changes Compared to Earlier TWiki Releases

See TWikiReleaseNotes04x00, TWikiReleaseNotes04x01, TWikiReleaseNotes04x02, TWikiReleaseNotes04x03, TWikiReleaseNotes05x00, TWikiReleaseNotes05x01, TWikiReleaseNotes06x00

New Upgrade Option with BackupRestorePlugin

TWiki now has a new solution to backup, restore and upgrade TWiki sites. It can be used via browser and on the command line. The BackupRestorePlugin is pre-installed in TWiki-5.1 and later releases; it can be installed in older TWiki releases as low as TWiki-2001-09-01 (Athens Release) to easily create a backup that can be restored on a new TWiki release. This offers an easy upgrade path for TWiki. The plugin is currently in Beta, check TWiki:Plugins.BackupRestorePlugin for updates.

Upgrade Procedure

The following steps are a rough guide to upgrading only. It is impossible to give detailed instructions, as what you have to do may depend on whether you can configure the webserver or not, and how much you have changed distributed files in your current TWiki release.

The main steps are:

1. Install the new TWiki version, configure it, and get it to work similar to the old version
2. Install additional extensions (plugins) -- make sure to use the latest versions
3. Copy all the non-default webs from the old installation to the new
4. Copy the users from old installation to the new including all their topics from Main
5. Apply customizations to your skin (logos, menu bars etc)
6. Apply preferences from old installation
7. Switch-over

After the extensions are installed (or upgraded) in step 2, take a "golden" backup. That will come in handy for your next patch or upgrade: By checking the differences between the golden copy and your production copy, you will be able to identify all the modifications that you have applied to the core or extensions.

Installation

• Follow the installation instructions at TWiki:TWiki.TWikiInstallationGuide. Install the new release in a new directory. Do not install on top of the old release.
• Use the configure script to configure TWiki.
  • If you are upgrading from a 4.x.x release, you can carry over the configure settings from the old release.
  • You need to run configure and save the configuration once when you upgrade as this will update the altered and added settings.
  • You can also choose to start with a fresh configuration and walk through all the settings using your old twiki/lib/LocalSite.cfg as a reference. This way you will not have old obsolete settings in the new LocalSite.cfg.
  • If at any time during the installation you want to start over from fresh, delete the LocalSite.cfg file and re-run configure.
• Additional resources
  • TWiki:TWiki.InstallingTWiki#OtherPlatforms
  • TWiki:TWiki.ApacheConfigGenerator
  • TWiki:TWiki.SettingFileAccessRightsLinuxUnix
  • If you upgrade from an older TWiki your lib/TWiki.cfg from the old TWiki installation is a good resource for some of the settings you will need but you cannot reuse the old TWiki.cfg.
• Make sure you have a working basic TWiki before you continue

Install Extensions

• From TWiki-4.1.0 and on, the configure script which you ran during installation supports installation of additional plugins.
• Manual installation is possible. Follow the instruction on the plugin page at twiki.org.
• Check the plugin topics from your old TWiki installation. There may be plugin settings that you want to transfer to the new TWiki installation.
  Hint: For an easier upgrade later on, set the plugin preferences settings in the Main.TWikiPreferences topic, not in the plugin topic. To identify the plugin, prefix the name of the setting with the capitalized name of the plugin. For example, to change the DEFAULT_TYPE setting of the CommentPlugin, create a COMMENTPLUGIN_DEFAULT_TYPE setting in Main.TWikiPreferences.
• Typical plugin settings you may have altered.
  • CommentPlugin - Set DEFAULT_TYPE
  • EditTablePlugin - Set CHANGEROWS, Set QUIETSAVE, and Set EDITBUTTON
  • InterwikiPlugin - Set RULESTOPIC
  • InterWikis - If you added your own rules you should save this topic and not overwrite it.
  • SlideShowPlugin - Make sure you did not change the embedded 'Default Slide Template' If you did you should save it. It is a bad idea to do. It is better to define your own slide show templates as separate topics that do not get overwritten when you upgrade.
  • SmiliesPlugin - Did you add your own smileys?
  • TablePlugin - Set TABLEATTRIBUTES.
• Remember that a plugin must be activated in configure.
• To avoid having to re-apply plugin settings each time you upgrade a plugin or TWiki itself, define the altered plugin settings in Main.TWikiPreferences instead.

Copy your old webs to new TWiki

• Webs come in pairs, such as twiki/data/Engineering (for page content) and twiki/pub/Engineering (for attachments).
• When upgrading from 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 install. Do not copy the default webs: TWiki, Main, Trash, Sandbox, _default, and _empty.
• Make sure all data and pub files and directories are owned by the webserver user.
• Note: TWiki's WebChanges topics depend on the file timestamp. If you touch the .txt files make sure to preserve the timestamp, or to change them in the sequence of old file timestamps.

Copy Users And Their Topics From Main Web

• Copy all the topics from the Main web and corresponding pub/Main directories from the old TWiki to the new TWiki but do not overwrite any of the new topics already inside the new Main directory!
• Manually merge all the users from the old Main.TWikiUsers topic to the new TWiki. If you upgrade from Cairo you can simply use the old file and add the missing new system users to the list of users. If you upgrade from TWiki-4.0.x simply use the old topic. Starting from 4.2.0 TWiki no longer ships with a Main.TWikiUsers topic. When you register the first user TWiki now checks for an existing Main.TWikiUsers and if it does not exist it gets created.
  • If you want users to be able to use a login ID other than their WikiName, such as when using LDAP or SSO authentication, set the configure setting {Register}{AllowLoginName} to 1.
• If you use data/.htpasswd for authentication copy this file from the old TWiki to the new.
  • If you upgrade from Cairo and you are using the Htpasswd login manager, then note that email addresses for users have moved out of user topics and into the password file. There is a script that performs this extra upgrade step for you - see tools/upgrade_emails.pl.
• The old Sandbox web may have a lot of useful topic and users may use it actively for drafts. Manually select the topics (remember the corresponding pub directories) from the old Sandbox web and copy them to the one of the new TWiki. Decide if you want to overwrite the sandbox homepage and left menu bar or keep the new.
• If you added or removed fields from the user topic form you may also have tailored TWiki.TWikiRegistration. Make sure you either reuse the registration topic from the old installation or apply the same field changes to the new TWiki.TWikiRegistration topic.
• Starting from 4.2.0 TWiki ships with NewUserTemplate and UserForm in the TWiki web. If you choose to tailor anything you are strongly advised to copy NewUserTemplate and UserForm to the Main web and tailor the Main web copies. TWiki will look for the NewUserTemplate in the Main web first and if it does not exist it uses the default from the TWiki web. By creating a Main.NewUserTemplate and its Main.UserForm you will not loose your tailorings next time you upgrade TWiki.
• Make sure all data and pub files and directories are owned by the webserver user.

Apply Customizations To The Skin

• Add Logos, update top bar and left bar as required.
• Apply any desired changes to style sheets and templates. The default TopMenuSkin is based on the PatternSkin.
• Additional resources:
  • TWiki:TWiki.UpgradingTWiki04x00PatchReleases
  • PatternSkinCustomization
  • PatternSkinCssCookbook

Apply Preferences From Old Installation

• Transfer any customized and local settings from TWiki.TWikiPreferences to the topic pointed at by {LocalSitePreferences} (Main.TWikiPreferences). Per default this is Main.TWikiPreferences. This avoids having to write over files in the distribution on a later upgrade.
• If you changed any of the topics in the original TWiki distribution, you will have to transfer your changes to the new install manually. There is no simple way to do this, though a suggestion is to use 'diff' to find changed files in the data/TWiki of the old and new TWiki installation, and transfer the changes into the new TWiki install. If you can run a GUI on your server, you may find that using a visual diff tool like WinMerge, meld, kdiff3, xxdiff, etc. is helpful.
• Compare the WebPreferences topics in the old TWiki Installation with the default from the new TWiki installation and add any new Preferences that may be relevant.
• Compare the WebLeftBar topics in the old TWiki Installation with the default from the new TWiki installation and add any new feature that you desire.

Switch-Over

Once you have tested the new TWiki you can switch over to the new site.

If the same domain and URL is used:

• Update the DNS settings of the TWiki domain with the IP address of the new TWiki server.
• Keep in mind that the updated DNS is not seen immediately by all users at the same time. The DNS propagation can take several hours and depends on the time to live (TTL) setting. Because of this it is recommended to disable content update on the old server. You could simply rename or move all scripts in twiki/bin that allow content update, such as attach, edit, manage, rename, save, upload, rest. Alternatively, if you have a recent TWiki version on the old server you can set a READONLYSKINMODE = 1 setting in Main.TWikiPreferences to turn the skin into read-only mode.

If the domain or URL changes:

• Add a DNS setting for the new TWiki domain if needed.
• Redirect users visiting the old TWiki to the new TWiki. The TWiki:Plugins.MovedSkin has been designed for that task. Install it on your old TWiki, and configure it with the proper URL of the new TWiki. After that, users on the old TWiki will see a yellow box informing them of the move, with a link to the new URL of the page visited.

Customization of Special Pages

Some pages in the TWiki web are meant to be customized after choice of authentication. If you do not use the internal TWiki password manager the topics that contains the features for changing and resetting passwords and changing the email address should be changed to a note describing how to perform these tasks in your organization. If you have made such customizations remember to replace these topics in the TWiki web with the tailored versions from your old installation. The topics are:

• TWiki.ChangePassword
• TWiki.ResetPassword
• TWiki.ChangeEmailAddress

Upgrading from Cairo to TWiki-4 (additional advice)

Favicon

TWiki-4's PatternSkin introduces the use of the favicon feature which most browsers use to show a small icon in front of the URL and for bookmarks.

In TWiki-4 it is assumed that each web has a favicon.ico file attached to the WebPreferences topic. When you upgrade from Cairo to TWiki-4 you do not have this file and you will get flooded with errors the error log of your web server. There are two solutions to this.

• Attach a favicon.ico file to WebPreferences in each web.
• Preferred: Change the setting of the location of favicon.ico in TWikiPreferences so all webs use the favicon.ico from the TWiki web. This is the fastest and easiest solution.

To change the location of favicon.ico in TWikiPreferences to the TWiki web add the following setting to Main.TWikiPreferences:

   * Set FAVICON = %PUBURLPATH%/%SYSTEMWEB%/%WEBPREFSTOPIC%/favicon.ico

TWikiUsers topic in Main web

Your old Main.TWikiUsers topic will work in the new TWiki but you will need to ensure that the following four users from the TWikiUsersTemplate topic are copied to the existing TWikiUsers topic in proper alphabetical order:

   * TWikiContributor - 2005-01-01
   * TWikiGuest - guest - 1999-02-10
   * TWikiRegistrationAgent - 2005-01-01
   * UnknownUser - 2005-01-01

What these users are:

• TWikiContributor - placeholder for a TWiki developer, and is used in TWiki documentation
• TWikiGuest - guest user, used as a fallback if the user can't be identified
• TWikiRegistrationAgent - 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

You additionally need to ensure that TWikiUsers has the Set ALLOWTOPICCHANGE = TWikiAdminGroup, TWikiRegistrationAgent access control setting. Otherwise people will not be able to register.

Important Changes since TWiki-4.0.5

Supported Perl version

TWiki 4.0.5 worked on Perl version 5.6.X. Reports from users has shown that unfortunately TWiki 4.1.0 does not support Perl versions older then 5.8.0. It is the goal that TWiki should work on at least Perl version 5.6.X but none of the developers have had access to Perl installations older than 5.8.0.

Since TWiki 4.1.0 has some urgent bugs the development team decided to release TWiki 4.1.1 without resolving the issue with Perl 5.6.X. We will however address this and try and resolve it for a planned 4.1.2 release. The TWiki community is very interested in contributions from users that have fixes for the code which will enable TWiki to run on older versions of Perl.

See the WhatVersionsOfPerlAreSupported topic to keep up to date with the discussion how to get back support for earlier Perl versions.

Template spec changed

Until TWiki 4.0.5 TWikiTemplates the text inside template definition blocks (anything between %TMPL:DEF{"block"}% and %TMPL:END% was stripped of leading and trailing white space incl new lines.

This caused a lot of problems for skin developers when you wanted a newline before or after the block text.

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

It is not difficult. The general rule is - if you get mysterious blank lines in your skin, the newline after the %TMPL:DEF{"block"}% needs to be removed. Ie. the content of the block must follow on the same line as the TMPL:DEF.

The spec change have the same impact on CommentPlugin templates where you may have to remove the first line break after the TMPL:DEF. See the CommentPluginTemplate for examples of how comment template definitions should look like in TWiki-4.1.X

An example: A CommentPlugin template that adds a comment as appending a row to a table. Before the spec change this would work.

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

From Twiki 4.1.0 the old template definition will add an empty line before the new table row. To fix it simply remove the new line before the table.

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

The advantage of the spec change is that now you can add leading and trailing white space including new lines. This was not possible before.

Important Changes since TWiki-4.1.0

New location for session and other temporary files

An upgrader upgrading to 4.1.1 should note the following important change

The directory for passthrough files and session files have been replaced by a common directory for temporary files used by TWiki. Previously the two configure settings {PassthroughDir} and {Sessions}{Dir} were by default set to /tmp. These config settings have been replaced by {TempfileDir} with the default setting value /tmp/twiki. If the twiki directory does not exist twiki will create it first time it needs it.

It is highly recommended no longer to use the tmp directory common to other web applications and the new default will work fine for most. You may want to delete all the old session files in /tmp after the upgrade to 4.1.1. They all start with cgisess_. It is additionally highly recommended to limit write access to the {TempfileDir} for security reasons if you have non-admin users with login access to the webserver just like you would do with the other webserver directories.

Important Changes since TWiki-4.1.2

New WYSIWYG Editor

TWiki now ships with a new WYSIWYG editor based on TinyMCE which replaces the Kupu based editor. TinyMCE is not a perfect Wysiwyg editor but it is magnitudes better than the previously used Kupu editor.

The WysiwygPlugin that drives the engine behind both TinyMCE has additionally been heavily improved so that fewer TWiki Applications are negatively affected by editing in WYSIWYG mode.

When TinyMCEPlugin is enabled, the Edit button by default becomes WYSIWYG editing mode. A new Raw Edit link has been added to enable application developers to edit the good old way.

The WYSIWYG button has been removed.

NEWTOPICLINKSYMBOL removed

The NEWTOPICLINKSYMBOL preference which was deprecated in 4.1 has now been removed from the code. If you want to control the appearance of new links, you can use NEWLINKFORMAT.

UserForm and NewUserTemplate Customization

When a new user registers on TWiki his user topic is created based on the NewUserTemplate and UserForm.

The NewUserTemplate was located in the TWiki web and the UserForm in the Main web. When upgrading TWiki these were some of the topics you had to take care not to overwrite.

From 4.2.0 the UserForm and NewUserTemplate are distributed in the TWiki web. If you create the two in the Main web the Main web version will be used instead. So if you tailor the user topic format or the form then you should always copy the two files to the Main web and modify the ones in the Main web. When you later upgrade TWiki your tailored template and form will not be overwritten.

TWikiUsers no longer distributed

The Main.TWikiUsers topic contains all the registered users. It is a topic you do not want to overwrite when you upgrade TWiki.

From 4.2.0 this file is no longer included in the TWiki distribution. When you register the first time TWiki creates the Main.TWikiUsers topic in the Main web if it does not exist already. This means that you can now upgrade TWiki without risk of overwriting the important TWikiUsers topic.

• For new installers this makes no difference at all
• For upgraders this is one less problem to worry about as your important Main.TWikiUsers topic now no longer gets overwritten when upgrading.

New working directory

A new working directory which by default is located in the twiki root, has been introduced which contains:

• registration_approvals - with 4.2.0 it is moved to here from the data directory.
• tmp - so we now avoid having to fight with special access rights and /tmp directory that gets cleaned out when booting.
• work_areas - with 4.2.0 it is moved to here from the pub directory. Configure automatically moved the directory when you upgrade.

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

The configure setting {WorkingDir} defines the container directory for temporary files, extensions' work areas, and intermediate registration data. The default is working under your installation root.

Take care for that change if you run your own routine to delete obsolete session files, which will now be found under working/tmp/cgisess*.

New Internal Admin Login

TWiki 4.2 introduces a new Internal Admin Login feature which uses "admin" (configurable) as username and the password used for configure to become temporary administrator. When you do a new installation you need to use this feature as Main.TWikiAdminGroup is now access restricted by default to avoid security attacks during the hours an installation may take. From configure there is a link to the TWikiAdminGroup topic and on TWikiAdminGroup the step by step instructions are written in a yellow box. Our advice is not to remove this help text in case you need it later.

Important Changes since TWiki-5.0.0

New TopMenuSkin

The TopMenuSkin adds pulldown menus for better usability and corporate/modern look&feel. This skin is based on the PatternSkin, which used the WebLeftBar in each web for navigation. The TopMenuSkin has a new WebTopBar that defines the menu structure in each web. A default menu is shown in case WebTopBar is missing in a web, so you do not need to add a WebTopBar topic to all your existing webs. See TopMenuSkin#WebSpecific instructions in case you need a customized menu structure in a specific web.

Important Changes since TWiki-5.1.0

New Page Bookmarks Feature

A new bookmark feature has been introduced that replaces the personal left-bar links. Bookmarking a page is now a simple point and click operation: In the Account pulldown menu, select "Bookmark this page...". Existing bookmarks can be managed with an edit table in Main.<wikiname>Bookmarks topic, accessible via the "----- Bookmarks -----" pulldown menu of the Account pulldown.

The personal left-bar topics such as JohnSmithLeftBar are no longer used. Ask users to select the "----- Bookmarks -----" pulldown menu of the Account pulldown to initially create the bookmarks topic, then to either bookmark pages, or to manually copy & paste old left-bar links to the bookmarks topic.

User Profile Pages Tailored for Workplace

Previous user profile pages had a bare bones look and the form fields were more tailored for public TWiki sites. TWiki-5.1 brings a more visual/modern page layout with profile picture selector, as well as default form fields tailored for the workplace.

Changes to the TWiki.UserForm:

Renamed:

• FirstName to First Name (no change in %META:FIELD name)
• LastName to Last Name (no change in %META:FIELD name)
• OrganisationName to Organization
• OrganisationURL to URL
• Profession to Titles
• VoIP to Skype ID
• State to Region

• Address
• InstantMessaging (IM)
• HomePage
• Comment

• Department
• Status Update

When upgrading user profile pages pay attention to the renamed and removed fields.

Important Changes since TWiki-6.0.0

Spec Change for Empty DENYTOPICVIEW

From TWiki 4.0 and prior to 6.0, the syntax * Set DENYTOPICVIEW = (nothing) in a topic means deny nobody the topic view. The reason for this behavior is that it allows public access to a topic in a restricted web, e.g. having * Set ALLOWWEBVIEW = Main.VipGroup in WebPreferences. This is not symmetric with the fact that an empty DENYWEBVIEW is the same as an undefined DENYWEBVIEW, hence confusing.

From TWiki 6.0 on, an empty DENYTOPICVIEW means the same as not defined. To open up a topic in a restricted web, you need to use * Set ALLOWTOPICVIEW = Main.AllUsersGroup. The Main.AllUsersGroup is new. It is a pseudo group containing all authenticated and unauthenticated users. You can use Main.AllAuthUsersGroup if you want to specify all authenticated users.

To keep publicly accessible topics in restricted webs publicly accessible, the tools/eliminate_emptydenytopic script is provided, which replaces * Set DENYTOPIC<action> = with * Set ALLOWTOPIC<action> = Main.AllUsersGroup in all topics in all webs.

Note: See more changes since TWiki-6.0.0 in TWikiReleaseNotes06x00.