This guide covers upgrading from a previous version of Foswiki to Foswiki 2.x.
-upgrade-
version of the Foswiki package, and follow the Release Notes for the new
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 typical customizations. Unless otherwise stated in the release notes, we do not recommend upgrading between major or minor versions using the patch (For ex. 1.1.9 to 2.0). A re-installation is recommended.
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).
Main
web files not shipped in upgrade package data/Main/AdminGroup.txt
data/Main/AdminUser.txt
data/Main/NobodyGroup.txt
data/Main/PatternSkinUserViewTemplate.txt
data/Main/ProjectContributor.txt
data/Main/RegistrationAgent.txt
data/Main/SitePreferences.txt
data/Main/UnknownUser.txt
data/Main/UserHomepageHeader.txt
data/Main/UserListByDateJoined.txt
data/Main/UserListByLocation.txt
data/Main/UserListHeader.txt
data/Main/UserList.txt
data/Main/WebAtom.txt
data/Main/WebChanges.txt
data/Main/WebCreateNewTopic.txt
data/Main/WebHome.txt
data/Main/WebIndex.txt
data/Main/WebLeftBarExample.txt
data/Main/WebNotify.txt
data/Main/WebPreferences.txt
data/Main/WebRss.txt
data/Main/WebSearchAdvanced.txt
data/Main/WebSearch.txt
data/Main/WebTopicList.txt
data/Main/WikiGuest.txt
Sandbox
web files not shipped in upgrade package data/Sandbox/CommentPluginExampleComments.txt
data/Sandbox/CommentPluginExamples.txt
data/Sandbox/CommentPluginTemplateExample.txt
data/Sandbox/CompareRevisionsAddOnDemoTopic.txt
data/Sandbox/PluginTestEmptyPlugin.txt
data/Sandbox/WebAtom.txt
data/Sandbox/WebChanges.txt
data/Sandbox/WebCreateNewTopic.txt
data/Sandbox/WebHome.txt
data/Sandbox/WebIndex.txt
data/Sandbox/WebLeftBarExample.txt
data/Sandbox/WebNotify.txt
data/Sandbox/WebPreferences.txt
data/Sandbox/WebRss.txt
data/Sandbox/WebSearchAdvanced.txt
data/Sandbox/WebSearch.txt
data/Sandbox/WebTopicList.txt
System
web files not shipped in upgrade package data/System/InterWikis.txt
data/System/NewUserTemplate.txt
data/System/WebPreferences.txt
data/System/WebTopicEditTemplate.txt
data/_default/WebHome.txt
data/_default/WebLeftBar.txt
data/_default/WebPreferences.txt
data/Trash/TrashAttachment.txt
data/Trash/WebPreferences.txt
data/TWiki/WebPreferences.txt
index.html
robots.txt
?refresh=all
The following is a high level view of the upgrade procedure:
tools/rewriteshebang.pl
to fix up the Perl locations
Main
web in the new installation, including all user topics.
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. 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.
Theconfigure
page mentioned in this document is accessible via your web browser at http://yourdomain/<newwiki>/bin/configure .
.js
, .css
files:
If you are using Expires tags, (you should be!) it is very important to take the longest expiration time into consideration. Clients will locally cache JavaScript and CSS until the time expires, unless they clear their cache. There are significant changes to the JavaScript and CSS files shipped with Foswiki 2.0. Clients using locally cached data will not operate correctly.
ExpiresDefault "access plus 11 days"
, change it to ExpiresDefault "access plus 1 hour"
If these steps are not done, users will have to clear their browser cache to get the most recent CSS and JavaScript..
perl tools/dependencies
Review the Release Notes 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. iso-8859-1
encoding (The "Latin Alphabet 1, intended for US and Western European languages).
UTF-8
encoding, which provides better support for international character sets.
cp-1252
instead of iso-8859-1
. cp-1252
contains windows specific high-ASCII characters including typographic "smart" quotes, alternative bullets and the emdash character. For more information
see Foswiki:Support.Utf8MigrationConsiderations.
{Store}{Encoding}
and you intend to use, (or have existing) high-bit characters in attachment filenames
(such as umlauts and accents) then links to these attachments on Foswiki pages will not work. This is because Foswiki works internally using UNICODE, but
the store saves files to disk using your chosen {Store}{Encoding}. The solution is to convert your store to UTF8 at the earliest opportunity.
utf-8
encoding. Character set conversion is not needed. Proceed to chosing your store.
iso-8859-1
or any other common encoding. All topics are consistent with this encoding. You have three options: bulk_copy.pl
script to migrate your existing 1.1.x store over to Foswiki 2.0. Each topic will be converted from the 1.1.x {Site}{CharSet}
encoding to the 2.0 {Store}{Encoding}
. We recommend you leave 2.0 {Store}{Encoding}
as undefined (utf-8
). or
{Store}{Encoding}
to match your 1.1.x {Site}{Encoding}
and copy the data into Foswiki 2.0 unmodified.
-r
(repair) option, the tool attempts to detect the encoding and can convert individual topics based upon their content. This is rather unpredictable and may require manual intervention.
bulk_copy.pl
script does not modify existing topics but is unable to handle some legacy configuratino..
perl -I lib tools/bulk_copy.pl --help
for more information on conversion. bulk_copy.pl
is not compatible. You must migrate to Foswiki before converting the Store.
* Set ALLOWTOPICxxxx = *
wildcard allow rules. Use perl tools/convertTopicSettings.pl -help
for further information on the conversion process.
configure
page. <oldwiki>/lib/LocalSite.cfg
file to <newwiki>/lib/LocalSite.cfg
in order to preserve your existing configuration settings (Not recommended). Alternatively, you can reconfigure the new installation from scratch (you can use your old LocalSite.cfg
file as a reference).
configure
page, including any new settings added in the new version. Save the configuration after you have completed your changes.
<newwiki>/lib/LocalSite.cfg
file and visit your default view
URL. From there follow the link to configure
.
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).
bulk_copy.pl
to change Stores, you should select the RcsStoreContrib in the configuration.
Once topic history has been created with the wrong store, it has to either be removed, or old data should be migrated with bulk_copy.pl
.
If Foswiki encounters mixed RCS and PlainFile topic history, it will "die" to prevent topic history corruption.{Store}{Encoding}
must match the 1.1.9 {Site}{CharSet}
{AccessControlACL}{EnableDeprecatedEmptyDeny}
setting should be enabled.
{Htpasswd}{CharacterEncoding}
should match your 1.1.9 {Site}{CharSet}
{RCS}{TabularChangeFormat}
should be enabled for compatible .changes file format.
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.
configure
page to review installed extensions, search for extensions or all available extensions 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).
Check the plugin topics from your old Foswiki installation and transfer the plugin settings to the 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 SitePreferences
topic in the new site.
Commonly-customized plugin settings include the following: CommentPlugin
- DEFAULT_TYPE
EditTablePlugin
Deprecated! Replaced with EditRowPlugin - CHANGEROWS, QUIETSAVE, EDITBUTTON
InterwikiPlugin
- RULESTOPIC
InterWikis
- If you added your own rules, make sure you copy over the rules to the new installation. Use of a local rules topic is the preferred way to customize the links.
SlideShowPlugin
- If you changed the embedded 'Default Slide Template', then copy your customized 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
configure
.
working
directory foswiki/working/work_areas
directory.
Extensions use it to store persistent information critical to operation. For example, the MailerContrib
directory contains the timestamps of the last notification email run per web.
If not copied, the next mailnotify
run will notify all recorded changes.
This is the most common data that should be copied. Review other non-default extensions to determine if anything else should be copied.
.htpasswd
file .htpasswd
file may require conversion. If users have registered using "high ascii" characters in their WikiNames (e.g. Ä, ä, Ë, ë, Ï, ï, Ö, ö, Ü, ü) then conversion will be
required. Foswiki does not provide a tool to convert .htpasswd
. Consider command line tools such as iconv
or recode
. See
this StackOverflow article for more details.
If you are using an external authentication source, such as LDAP, this step does not apply.
tools/bulk_copy.pl
/var/www/f119
/var/www/f120
bulk_copy.pl
tool to migrate your data:
cd /var/www/f120/tools perl bulk_copy.pl --xweb System --xweb _default --xweb _empty --latest '*.WebStatistics' /var/www/f119/bin /var/www/f120/binThis will copy all webs, topics and attachments except for the contents of the System web. This is the recommended solution.
bulk_copy.pl
has limitations! It uses the Foswiki Store API to copy topic and attachments. If the store doesn't recognize a topic or attachment, it won't be copied. _myfile
. Frequently used by extensions as cache type files. Could also have been directly uploaded.
.htaccess
files.
{RCS}{AutoAttachPubFiles}
feature is not enabled.
{Site}{CharSet}
was changed after history exists, the history will not convert correctly and the copy may fail.
bulk_copy.pl
can be very slow converting topics with extensive histories. Each revision of a topic is separately converted. Any errors in the history can cause the conversion to fail.
bulk_copy.pl
executes the code and APIs of the older Foswiki release. Older versions of Foswiki may fail on the latest versions of Perl due to language
changes. If you encounter this issue, you could try an upgrade of the 1.1.x system to Foswiki 1.1.10, or use the CharsetConverterContrib to complete the migration.
bulk_copy.pl
is not compatible with Foswiki 1.0.x versions. If you
are copying data from Foswiki 1.0.x, there are two options: Copy content from non-default webs in old installation to the new installation
Be sure to select an "RCS Store"RcsWrap
orRcsLite
on the new installation. The PlainFile store is not compatible with topic history written on previous versions of Foswiki. If you have created or updated topics using PlainFileStore, you should either start over, or plan to to remove all,pfv
directories from the system so that there is no history in the PlainFileStore format. Copy your local webs over to the data and pub directories of the new installation. Do not copy the default webs: <old_system_web> System, Main, Trash, Sandbox, _default, and _empty.If needed, convert the character encoding of each web before attempting to access it from the web. The following CharsetConverterContrib command will "inspect" a single web and report any conversion issues. Remove the
- It may be preferable to copy and convert one web at a time.
- 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.-i
option to proceed with the actual conversion. Do not run the actual conversion more than once on a web!Verify that existing topics are operational and (if you converted to
perl convert_charset.pl -i -web=<Webname> -encoding=cp-1252
UTF-8
) that any international characters have been properly converted and are displayed correctly.Copy users, user topics, and site customizations to
Copy all topics and attachments from <old_users_web>: copy all files fromMain
web<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.Use the CharsetConverterContrib to convert the new Main as described above. Copy over any topics and attachments you want to preserve from the Sandbox web in the old installation: copy the desired files from
- 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 theconfigure
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.
- If your old installation did not customize
{LocalSitePreferences}
on theconfigure
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.<oldwiki>/data/Sandbox/
to<newwiki>/data/Sandbox
and from<oldwiki>/pub/Sandbox/
to<newwiki>/pub/Sandbox
. Some pages you may wish to preserve are theWebHome
topic and theWebLeftBar
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.
Main.WikiUsers
topic: Main.WikiUsers
, using the corresponding entries in Foswiki:System.UsersTemplate as an example. <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.
DENYTOPIC
rules will be ignored by Foswiki 2.0. You must change them to the equivalent ALLOWTOPIC *
rules. The tools/convertTopicSettings.pl
utility will scan the Webs & Topics, and will perform several optional conversions on the topics. convertTopicSettings
perl tools/convertTopicSettings.pl -help
perl tools/convertTopicSettings.pl
perl tools/convertTopicSettings.pl -fixdeny -update
perl tools/convertTopicSettings.pl -fixdeny -convert -update Sandbox
perl tools/convertTopicSettings.pl -fixdeny -convert -all -update Sandbox Customer
convertTopicSettings
saves the modified topics, they will be saved by user UnknownUser.
{LegacyFormfieldNames}
in
the configuration. Fühler
would be stored as Fhler
.
Fühler
.
{LegacyFormfieldNames}
, then you will need to find and update the META:FIELD
definitions in the topics. This would need to be done external to Foswiki.
%META:FIELD{name="Fhler" title="Fühler" value="123"}%would need to be changed to
%META:FIELD{name="Fühler" title="Fühler" value="123"}%
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.)
(These should have been copied when your Main was migrated.)
If, in your old installation, you customized the default preferences in <old_system_web>.DefaultPreferences
, then transfer your customizations from this topic to the SitePreferences 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 have any old extensions that use settings from the "System.<Extension>" topic, these settings should also be copied to the
SitePreferences. Topics in the System should never be edited!
<oldwiki>/<old_system_web>/
directory as a reference.
cd <path-to-foswiki-installation> sudo -u www-data tools/configure -check sudo -u www-data perl tools/configure -check {DataDir} -method validate_permissions sudo -u www-data perl tools/configure -check {PubDir} -method validate_permissions ... also can be run on: {LocalesDir} {ScriptDir} {TemplateDir} {ToolsDir} {WorkingDir}
Execute your test plan to validate the Wiki applications and other key functionality that need to be up and running after the upgrade.
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.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 fromhttp://yourdomain/wiki/
. You can use one of the following approaches to make the new installation accessible using the same URL prefix: <newwiki>/
directory to wiki/
(renaming the directory of your old installation if necessary).
wiki/
that points to <newwiki>/
(renaming the directory of your old installation if necessary).
/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.