Foswiki Release 1.1.10

Foswiki - The Free and Open Source Wiki

Foswiki is an enterprise collaboration and information sharing tool targeted for professional use in many types of organizations: from small businesses to multi-nationals, from one-product open source groups, to worldwide research networks.

Foswiki is a wiki: fundamentally, a website with editable web pages. It looks like a normal web site but it encourages contributions, edits, updates, questions, and answers from its users. It's a powerful way of enabling a community to communicate asynchronously using intranet and public internet websites. Foswiki is simple to learn and use. It aims to provide a transparent way for you to publish and exchange your ideas with others over the web and eliminates the one-webmaster syndrome of outdated intranet content.

Foswiki is a structured wiki with tools that enable users without programming skills to build powerful yet simple applications to process information and support workflows. Developers can extend the functionality of Foswiki with plugins.

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.1 ships with a TWikiCompatibilityPlugin, thus enabling most extensions made for TWiki to work under Foswiki. Since the start of the Foswiki project there have been several releases of TWiki, However there have been very few functionality changes, and the useful changes have all been tracked in Foswiki, so topics and wiki applications supported by TWiki should also work with Foswiki.

Foswiki is released under the GNU General Public License.

Foswiki Releases

• 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. And the 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 userinterfaces for groups, much improved WYSIWYG editor, facelift of the default skin, much improved configure tool, and many more enhancements.
• Foswiki 1.1.1 was built 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 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 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 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 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 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 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 1.1.8 was built 28 Feb 2013. It is a release that fixes CVE-2013-1666. It contains 4 fixes.
• Foswiki 1.1.9 was built 18 Nov 2013. It is a release that contains 44 fixes and 4 enhancements.
• Foswiki 1.1.10 was built 23 Nov 2015. It is a release that contains 8 fixes and 8 enhancements.

Foswiki 1.1.10 is indended to be the final patch release in the Foswiki 1.1 Release stream.

Pre-installed Extensions

Foswiki 1.1 ships with the following:

• Plugins: AutoViewTemplatePlugin, CommentPlugin, EditTablePlugin, EmptyPlugin, HistoryPlugin, InterwikiPlugin, JQueryPlugin, PreferencesPlugin, RenderListPlugin, SlideShowPlugin, SmiliesPlugin, SpreadSheetPlugin, TablePlugin, TinyMCEPlugin, TwistyPlugin, WysiwygPlugin
• Contribs: CompareRevisionsAddOn, FamFamFamContrib, JSCalendarContrib, MailerContrib, PatchFoswikiContrib, TipsContrib, TopicUserMappingContrib
• Skins: PatternSkin
• Compatibility support - TWikiCompatibilityPlugin

Important changes in Foswiki 1.1.10 (This release)

Foswiki 1.1.10 is a compatibility release for sites unable to upgrade to Foswiki 2.0. It contains fixes for Perl and CPAN compatibility issues that can arise after a system upgrade. It has been tested with perl versions 5.8.8 thru 5.23. It also contains backports of important Foswiki 2.0 features necessary for compatibility with extensions released for Foswiki 2.0.

This release refreshes all default extensions to the version shipped with Foswiki 2.0, with the exception of TopicUserMappingContrib and PatternSkin. The new version of these extensions are not compatible with Foswiki 1.1.

Foswiki 1.1.10 does not contain fixes for security issues fixed in the Foswiki 2.0.x releases. Upgrade to the latest Foswiki release is strongly recommended.

ACL Changes

Foswiki 1.1.10 backports the new wildcard ACL. ALLOW and DENY rules can now be set to "*" asterisk, which means always match. In Foswiki 2.0, this is used to deprecate the old "Empty" deny rule. Foswiki 1.1.10 still supports the empty deny rules, but also supports the "ALLOW *" for allow all.

SpreadSheetPlugin changes

The CALC and CALCULATE macros now encode < and > as entities, which prevents some paths used to insert script tags. If your user's topics require CALC or CALCULATE to generate HTML, then you must enable the following setting:

• Set SPREADSHEETPLUGIN_ALLOWHTML=1

This setting can be set in the topic, web, user or site perferences.

Important changes in Foswiki 1.1.9

Release 1.1.9 fixes a number of important bugs. Several are security related and we strongly recommend that sites upgrade to this release.

• The %TOPICLIST% macro now omits topics that cannot be read by the user. Foswiki should not reveal the presence of topics to users who don't have the authority to view the topic.
• Login using url parameters has been restricted. Details below..

Release 1.1.9 addresses several issues that impact sites that have upgraded or will upgrade to newer versions of perl and CPAN modules. We strongly recommend that foswiki be upgraded to 1.1.9 prior to updating to a new release of perl or CPAN modules.

Two serious performance issues have been corrected. The TablePlugin amassed CSS from all visited topics, growing with each view. And an error in SEARCH caused exponential growth of the search expressions which could cause out of memory issues on the server. These could be especially severe for sites using FastCGI or Mod_Perl.

See #Rel01x01x09Details for details.

JQuery upgrade

This release ships with several upgraded versions of JQuery, and changes the default release to version 1.8.3. It also replaces the deprecated JQuery Tooltip plugin with the new UI::Tooltip. Upgraders should visit bin/configure and make the following changes to the Jquery configuration:

• Update {JQueryPlugin}{JQueryVersion} to version 1.8.3
• Disable {JQueryPlugin}{Plugins}{Tooltip}{Enabled} and
• Enable {JQueryPlugin}{Plugins}{'UI::Tooltip'}{Enabled}

Note that although the jquery autocomplete plugin was replaced with ui::autocomplete back in Foswiki release 1.1.4, recent changes to jquery required some additional changes to some UI::Autocomplete examples. See Revision 17042 for details of this change.

Changes to login using URL parameters

All versions of foswiki previously allowed the username and password parameters to be provided on the URL. For ex: bin/view/Myweb/SomeTopic?username=JoeUser;password=SEcrET. Foswiki 1.1.9 has been changed to further restrict login:

• username and password will only be accepted on POST type operations. a simple GET url with username and password will not accept the supplied credentials.
  • The previous behaviour can be restored by enabling $Foswiki::cfg{Session}{AcceptUserPwParamOnGET} in the configuration
• username and password will only be accepted as login credentials on the view, viewauth and login scripts.
  • Other scripts can be authorized by configuring $Foswiki::cfg{Session}{AcceptUserPwParam}

Improved compatibility with Perl 5.18+

Foswiki 1.1.9 has been tested with perl 5.18+. Perl 5.18 has made a very significant change in how hash tables are randomized and stored. See 5.18 perldelta for more information. The change has had some minor impact on Foswiki, most of which were test failures, not core code issues, and were fixed in Item12616. It did however result in discovery of some core bugs that were also fixed.

Sites upgrading to perl 5.18 should carefully test foswiki and review the open tasks at https://foswiki.org/Tasks/PlatformPerl518. Please report any new issues there.

The following differences have been noticed when running under Perl 5.18, and have not been corrected:

• The order of search results order when the requested sort has duplicates is unpredictable. Ex: When sorting by "modified", the order of multiple topics modified at the exact same time will be unpredictable. (Task Item12618)
• The order of groups presented by %USERINFO and %GROUPINFO macros is unpredictable. As a result, the order of groups listed by the WikiGroups topic change on each page view. (Task Item12635)
• The order of data in a perl formatted %QUERY result is unpredictable. (No plan to fix)

Any data internally stored by Foswiki or extensions using a perl hash array will be presented in unpredictable order.

Important changes in Foswiki 1.1.8

Release 1.1.8 fixes a Critical Security Vulnerability. All previous releases of Foswiki are vulnerable to a security issue in Locale::Maketext. It is described further in SecurityAlert-CVE-2013-1666. It is expected that this will be the last release in the Foswiki 1.1 series. The next major release will be a feature release: Foswiki 2.0

Release 1.1.8 also includes a configuration checker that will report an error if a vulnerable version of Locale::Maketext is installed.

See #Rel01x01x08Details

Important changes in Foswiki 1.1.7

Release 1.1.7 fixes a Critical Security Vulnerability. All previous releases of Foswiki are vulnerable to a security issue in Locale::Maketext. It is described further in SecurityAlert-CVE-2012-6329. A 2nd vulnerability in the Foswiki %MAKETEXT% macro was also discovered, and is described further in SecurityAlert-CVE-2012-6330 . It is expected that this will be the last release in the Foswiki 1.1 series. The next major release will be a feature release: Foswiki 2.0

Release 1.1.7 also includes a security fix for configure that reduces exposure of important passwords in confirmation and log messages.

See #Rel01x01x07Details

Module version strings and new module dependency in 1.1.6 and 1.1.7

The Foswiki and default extension version strings have been changed from a developer oriented string Foswiki-1.1.5, Tue, 10 Apr 2012, build 14595, to a simple perl version string - "v1.1.6". The "RELEASE" string will continue to be more descriptive and can be displayed with a new macro %WIKIRELEASE%.

This adds a new dependency on version 0.77 - the Perl module version class.

• Sites using Perl 5.10.1 or newer have the correct version of version.
• Sites on older versions of perl should install the latest version using CPAN or their system's package manager.

Before upgrading to Foswiki 1.1.6 or 1.1.7, verify that the installed version of CPAN:version is at least version 0.77. If not, upgrade CPAN:version before attempting to upgrade Foswiki! For example:

 perl -Mversion -e 'print "$version::VERSION\n"'
0.9901

Note: Extensions may not have been upgraded to use the new 'dotted-decimal' version string format for dependency checking. If an extension includes a dependency on an SVN-style revision, Foswiki 1.1.6 assumes that the dependency is satisfied by a 'dotted-decimal' version.

Wysiwyg / TinyMCE Editor changes

Release 1.1.6 changed the editor to treat all links as real HTML links in TMCE. This had an annoying side effect: when a user changes the link text displayed in-line, the editor only updated the link text, and the target page was not changed. This even including auto-linked WikiWords. The editor will now save the original WikiWord. During the save, if the new link text is still a WikiWord, and the link target still points to the original WikiWord, it will also be updated to match the new WikiWord..

• Ex. if a InlineWikiWord is changed to ADifferentWikiWord, the link will now point to ADifferentWikiWord, which is probably what the user intended.

Note: This change required a setting change to the TinyMCEPlugin Init setting found in TinyMCEPlugin. If the TINYMCEPLUGIN_INIT settings have been customized, this change will need to be merged into your customized settings or the new behavior will be ignored.

Force Default Host URL toggle

Sites that use HTTP Proxies, load balancers and SSL Accelerators often modify the users original input URL. When this happens, Foswiki can generate incorrect links on the pages. A new expert configuration parameter {ForceDefaultUrlHost} can be enabled to force Foswiki to override the user entered URL with the {DefaultUrlHost} setting.

New configuration parameter {Register}{ExpireAfter}

Foswiki 1.1.6 added code to clean up expired pending registrations, and tied the request lifetime to the {Sessions}{ExpireAfter} timer. This is much too short, especially when registration requests are redirected to a 3rd party approver, as described in FAQ 12 and Managing Users documentation.

Item12329 breaks this out to a separate timer for registration requests. Default is 21600 seconds (6 hours). If this setting is not in the configuration, the code will fall back to the {Sessions}{ExpireAfter} timer, and if that is not configured, the default is 36000 (10 hours). Extend this setting to a longer value to give the approver ample time to process the request.

When upgrading, a new setting is needed for PatternSkin

If you are upgrading an existing Foswiki system, verify the following:

• Ensure that SitePreferences or DefaultPreferences have the setting for PATTERNSKIN_JQUERY_THEME.

     * Set PATTERNSKIN_JQUERY_THEME = PatternSkinTheme

• Be sure to run through an edit / save cycle in bin/configure.

The new System.DefaultPreferences topic has this setting, but if you have customized you DefaultPreferences, then this setting may need to be added.

The save cycle of configure is necessary to register the new JQuery pattern theme in the configuration. (If configure reports no changes, make a minor change and save again, and configure will merge in the changed settings). Or edit the LocalSite.cfg file by hand and add

$Foswiki::cfg{JQueryPlugin}{Themes}{PatternSkinTheme}{Url} =
'$Foswiki::cfg{PubUrlPath}/$Foswiki::cfg{SystemWebName}/PatternSkinTheme/jquery-ui.css';
$Foswiki::cfg{JQueryPlugin}{Themes}{PatternSkinTheme}{Enabled} = 1;

Font changes

A change made in 1.1.6 changed the default size and family of the body font. This change resulted in unexpected word wrap in tables that had column widths set to avoid wrapping. Foswiki 1.1.7 reverts the font setting back to that of Foswiki 1.1.5. Changes to the skin that impact layout should not have been made in a patch release.

Minor change to Main.WebHome

The Main.WebHome topic was changed to display the %WIKIRELEASE% macro instead of the %WIKIVERSION%. WIKIRELEASE is a more friendly user readable version string.

Important changes in Foswiki 1.1.6

Release 1.1.6 is a security focused and bug fix release. There are a number of fixes and small enhancements designed to improve the security of Foswiki.

Default format of "New Topic" links has changed.

The old format used a trailing questionmark to create a topic. Missing topics are now rendered with red text, and underlined with a dotted line. The entire missing-topic name is a link to create the new topic, instead of just the question mark. If you have applied a custom new topic setting in your SitePreferences, you shouldn't see any changes. Remove the override from SitePreferences to get the new behavior.

JQuery version updates

• The default version of JQuery has been bumped to JQuery 1.8.2
• All versions of jquery older than 1.7.1 have been removed.

Be sure to run configure and verify that the JQuery version is set to one still available, and preferably the default 1.8.2.

Registration handling

• The check for duplicate email regisrations is now applied to pending registrations.
• Code has been added to remove stale registration approval requests.

Wysiwyg / TinyMCE Editor changes

A number of changes have been made to make editing more "WYSIWYG" like:

• All links are now represented as real HTML links in TMCE. Editing the link text displayed in-line only updates the link text, including auto-linked WikiWords. Click the link icon to update the actual link target.
  • Ex. if a InlineWikiWord is changed to ADifferentWikiWord, the link will become [[InlineWikiWord][ADifferentWikiWord]]
• Verbatim blocks that are hidden will now display and can be edited.
• Escaped WikiWords will no longer display as links when edited.
• Major issues with loss of white-space and line breaks while editing have been corrected.
• It is now possible to position the cursor above/below blocks that start or end a topic.
• HTML entities added to topics when Ctrl-i or Ctrl-b are used for Italics / Bold are now removed on save.
• Multi-line TML tables can now be edited.
• NOAUTOLINK and <noautolink> blocks are now handled correctly.
• JQuery Chili highlighter classes are now all available from the context menu of a verbatim block.
• New tables inserted with wysiwyg now show the expected borders.
• TinyMCE has been updated to release 3.4.9

Insecure dependency errors when using LOCALEs

Setting a Locale in the configuration causes internal errors because of perl's mechanisms used to protect applications from potentially untrusted input. The systems Locale strings are considered "Tainted" and Foswiki fails with taint errors. At this point we don't have a good solution. Significant work is being done for future releases to resolve this issue.

In the meantime, if you require a custom Locale, and are experiencing errors like Insecure dependancy in x while running with -T switch our only solution presently is to disable Taint checking by removing the "-T" switch from the first line of each script in the bin directory.

A serious performance problem when renaming topics has been resolved

The resolution results in a change to what is renamed. Prior to this resolution, an extra scan of the entire web was performed. The new behavior is that "Incoming" links (Links pointing to the topic being renamed) will be listed and updated when their checkbox is checked. However "Outgoing" links (links internal to the renamed topic, pointing to other topics in the original web) will not be updated.

Performance problems when logs are "Rotated" at end of month.

The plainfile logger was using too much resources when rotating the logs at end of month. This has been improved somewhat, however there still can be issues for very busy sites. To help resolve this, the settings for the "Compatibility Logger" have been restored to the configuration. The compatibility logger writes to "date-stamped" filenames instead of doing an end-of-month rotation.

As an alternative, there is a new Foswiki:Extensions.LogDispatchContrib for more advanced logging. This extension will be the default logger in Foswiki 1.2.

JQuery Chili highlighter is enabled by default.

This was temporarily disabled because Firefox and Safari had errors which will corrupt the highlighted text. Recent browser releases have resolved this issue, and Chili is again enabled by default. It may still be necessary to disable Chili if your user community still is using the buggy browsers.

configure now backs up the configuration

configure now will save the previous configuration to a file named LocalSite.cfg.[n] where [n] is increased by 1 prior to each save. By default, 10 prior revisions are kept.

Markup within input fields are no longer rendered

Item11480 now prevents the rendering of Topic Markup (TML) within input fields. Previously if an input field was "pre-filled" with markup for ex: some *marked* text, it would be renderd as some <strong>marked<strong> text. Foswiki will no longer render the contents of input fields.

This exposes a potential issue. If input field initial content is manually protected using the <literal> to prevent the rendering, the resulting html will be corrupted. Foswiki allows for <nop>, however any other unencoded < and > is not legal within <input> tag and must be removed.

   <input ... text=' WikiWord *bold* text'>   previously was rendered,  on 1.1.6 will be shown exactly as written.
   <input ... text='<nop>WikiWord' >     Is acceptable,  but the <nop> is unnecessary.
   <input ... text='<literal>some *bold* text</literal' >   The <literal> tags MUST be removed

Sandbox WebHome topic updated with improved validation of new topic name

Foswiki upgrade packages and manual upgrade procedures typically do not upgrade any WebHome topics. The 1.1.6 upgrade package will include a new WebHome for the Sandbox web. If you upgrade manually, you should copy the data/Sandbox/WebHome.txt file from the full Foswiki distribution onto your system. If you have a customized Sandbox WebHome topic, and use the upgrade package, you may need to revert back to your customized topic or re-customize the new version.

Important changes in Foswiki 1.1.5

Release 1.1.5 is a security focused release. There are a number of fixes and small enhancements designed to improve the security of Foswiki.

API Change

The Foswiki API version is incremented to version 2.2 in Foswiki 1.1.5 for the following changes:

• Foswiki::Func::getScriptUrlPath() has been removed from deprecation, and enhanced with a new calling convention to be consistent with Foswiki::Func::getScriptUrl().

Improvements to User Registration

• The complete fix for CVE-2012-1004 has been integrated, including pluggable field validations in the User Mapper. If your installation uses a custom user mapper, there is a new function in the base user mapper lib/Foswiki/Users.pm that performs registration field validations. Override this method in your custom user mapper to add site specific validations.
• The user registration and group management API calls now all return error messages describing any failures. All errors are processed through MAKETEXT so that they are translated to the selected language.
• New options can reject duplicate registrations using the same email, and can either white-list or black-list email domains from registering.

Improvements to .htpasswd handling

• The HtPasswdUser password manager has been changed to globally cache the password file if enabled. In an installation running fcgi or mod_perl, this will reduce the overhead of reading the file for each transaction.
• The .htpasswd lock file is now configurable. There was a small risk that when multiple foswiki installations shared a common .htpasswd file, simultaneous updates would not be prevented, resulting in file corruption.
• The default for {Htpasswd}{Encoding} has been changed to apache-md5. We strongly recommend that installations migrate away from crypt encoding - the prior default. crypt truncates passwords at 8 characters.
• The {Htpasswd}{AutoDetect} option is enabled by default. This ensures that an existing .htpasswd file cannot be accidentally corrupted due to the change in default encoding.
• A new password encoding hash has been added. bcrypt encoding. (Ref. http://yorickpeterse.com/articles/use-bcrypt-fool )

Better session support for mixed http and https environments

If your foswiki is set up to accept both https and http requests, your users may find themselves logged out much faster than desired.

1.1.5 fixes this by using separate authentication session cookies when using http and https, but this may mean your users may need to login again. This applies to both TemplateLogin and ApacheLogin.

Changes to the configure password handling

The encoding of the bin/configure and "sudo" admin user has been changed. Sites should change their configure password as soon as possible. Note that this change is not backwards compatible. Once the password has been changed, if fallback to 1.1.4 is required, the password will have to be reset by removing the password from lib/LocalSite.cfg.

Changes to Statistics processing

The WebStatistics topics are no longer shipped with Foswiki. Two new topics have been included; DefaultWebStatistics and WebStatisticsTemplate. The statistics script now has the optional capability of creating the missing WebStatistics topics.

• The Foswiki configuration has a new parameter: {Stats}{AutoCreateTopic} (Default is disabled)
• The statistics script has a new parameter: -autocreate 1 or autocreate=1 (Default is 0 or disabled)
• The statistics script must now only be run using POST. HTML GET should never result in an update.

The details of this change are in SiteTools#WebStatistics, including a tool to help with creating the missing WebStatistics topics.

Changes to PlainFile logger to improve log rotation

In previous versions of foswiki, the default PlainFile logger failed to rotate the logs if any log records were corrupted. This is more likely in the error log file, but can be caused by any log record that is written containing embedded newlines. If a log record is read without the expected | Timestamp | as the first column, rotation stops.

This behavior has been corrected, however sites where rotation was failing may have extremely large log files. When foswiki performs the rotation at the beginning of the next month, rotation can take an extended time, resulting in extended response time.

Rotation is performed when the timestamp of the log file (events.log, error.log, debug.log) is in a month prior to the current month. In order for rotation to proceed:

• The directory containing the log files must be writable.
• Archive files named [logfile].YYYYMM must not exist for any records in the current [logfile].log file.
  • For example, if events.log contains an event dated 2012-01-15:, then the archive file events.201201 must not exist.

In order to force rotation and avoid extended web server response time:

• Quiesce the web server to prevent logging activity
• Upgrade to 1.1.5, which will install the updated lib/Foswiki/Logger/PlainFile.pm
• Reset the timestamps to the previous month on the logfile requiring rotation
  • touch -t 201202280101 events.log will set the timestamp to February 28th on a linux/unix system.
  • Windows users will need to install a 3rd party tool to change timestamps, or wait for the next month
• Change to the bin directory and run the view script from the shell as the web user.
  • sudo -u www ./view (Actual user will vary depending on the distribution)

The plainfile logger will now report additional information on the rotation process, including displaying bad records to STDERR. Edit lib/Foswiki/Logger/Plainfile.pm and change the line use constant TRACE => 0; to use constant TRACE => 1; to enable more detailed debug messages.

Important changes in Foswiki 1.1.4

1.1.3 may have changed some form.name MetaData to contain fully-qualified (with web name prefix) values

In Foswiki 1.1.4 this problem has been fixed by Item10874, however, users upgrading from 1.1.3 may wish to review the following information to determine if they need to take action on their existing SEARCHes or DataForm topics.

Please note, you may be unaffected by https://foswiki.org/Tasks/Item10874 if:

• You have never used Foswiki 1.1.3
• You are not QuerySearching form.name MetaData for exact topic-only (without web prefix) values, or
• Your users are not adding or changing DataForms on their topics via the edit screen's "add/change form" button, or
• Your installation is using Foswiki:Extensions.NatEditPlugin

Description

Any topics which have had a DataForm added or changed using the "Add/change form" button on the edit screen while running Foswiki 1.1.3 will now have "fully-qualified" Web.Topic names in the form.name MetaData even if the WEBFORMS preference variable omitted web prefixes from DataForm topic names. In other words, if you were using a WEBFORMS preference which looked like this:

   * Set WEBFORMS = MyForm

In Foswiki 1.1.3, the "Add/change form" button on the edit screen actually treats it like this:

   * Set WEBFORMS = TheWeb/TheSubWeb.MyForm

Having selected "MyForm", the form.name value is actually stored as TheWeb/SomeSubWeb.MyForm. This prevents QuerySearch type SEARCHes for an exact match on the topic-only value of form.name from working correctly, for example:

%SEARCH{"form.name='MyForm'" type="query" ...}%

... will not match these topics. Instead, a search on both possible values can be used:

%SEARCH{"form.name='MyForm' OR form.name='TheWeb/SomeSubWeb.MyForm'" type="query" ...}%

Or a regex query:

%SEARCH{"form.name=~'\bMyForm$'" type="query" ...}%

Alternatively, the erroneous form.name values can be repaired by searching for and fixing them using one of the solutions detailed in https://foswiki.org/Tasks/Item10874#Solution

Email enhancements

Significant enhancements were made to the Foswiki email implementation. These changes increase our compatibility with email services like Google's gmail, add enterprise features like S/MIME signed mail, and add a test facility to help the administrator better diagnose email problems before testing registration.

• Item10521: Implement SSL support, which adds direct support for gmail.
• Item10522: Implement S/MIME support for signed email using either sendmail or the Net::SMTP methods.
• Item10523: Add configure parameter to select GMT or Servertime in generated email messages
• Item10919: Implement an Email test function in configure.

These changes are backwards compatible with LocalSite.cfg however it is recommended to visit the Email tab in configure, correct any warnings, and save the configuration parameters guessed when the configuration is migrated.

Note that there are some subtle changes to the Email implementation. Prior to these changes, Foswiki guessed the email send method based upon the setting of the mail server name, which can be configured in LocalSite.cfg, as well as a deprecated preference setting SMTPMAILHOST. Once the configuration is updated for 1.1.4, the Email send method is an explicit setting in LocalSite.cfg. If the email send method is set to one of the Net::SMTP choices but the MAILHOST parameter is not set, Foswiki will still fall back to the MailProgram (like sendmail). However if the email method is set to use the MailProgram explicitly, it will ignore any hostname set in MAILHOST or SMTPMAILHOST.

Email linking improvements in Foswiki topic rendering.

The following tasks made significant changes to rendering of email addresses in Foswiki topics:

• Item10905: Unable to include spaces in the query string of mailto links
• Item10660: Some email address autolinking doesn't work
• Item11059: Email address followed by a dot generates email link with dot included

An old legacy link format deprecated in 2005 was interfering with the ability to pass complex query params to explicit http: and mailto: links. This issue is fixed, but there is a loss of some backwards compatbility. Before this fix, this link: [[mailto:user@example.com?subject=some email]] woud generate a message with the subject = "some" and link text of "email". After the fix, the link text will be the entire email address and the subject will be "some email". If the original link text is required, it should be entered as [[mailto:user@example.com?subject=some][email]]

Note that this fix also adds a new configuration parameter: $Foswiki::cfg{AntiSpam}{EntityEncode}. Entity encoding of email addresses as an anti-spam technique was previously controlled by the parameter $Foswiki::cfg{AntiSpam}{HideUserDetails}. Both parameters default to enabled. If you disabled the $Foswiki::cfg{AntiSpam}{HideUserDetails} option and desire the same behavior, you should also disable. $Foswiki::cfg{AntiSpam}{EntityEncode}. This fix corrects an issue where mailto links were double-encoded, breaking the ability to include more than one option in the query string.

Also the detection of email addresses in topics is significantly improved and is much closer to the Email address specification in RFC:5322 and the mailto URL specifications in RFC:3696.

Password Authentication enhancements Item9164 and Item10962

The PasswordManager Foswiki::Users::HtpasswdUser has been enhanced with an AutoDetect mode to detect the format of the stored password and to validate old passwords using the stored form instead of the encoding configured in {Htpasswd}{Encoding}. Enable this new feature by setting the configuration parameter {Htpasswd}{AutoDetect} to enabled.

• With this change, it is now possible to migrate to an alternate password Encoding without invalidating existing user passwords.
• The performance of HtpasswdUser.pm has been improved by up to 30% with large .htpasswd files
• A new encryption mode - apache-md5 has been added. This official Apache variation on MD5 encoding is compatible with the passwords generated by the htpasswd -m command.
• The encoding previously labeled md5 has been renamed to htdigest-md5 and is compatible with the encoding generated by the Apache htdigest command. The config setting will be modified by a config checker the first time you run configure after upgrade. It is recommended to save your configuration.
  • Note that it is also now possible to modify the {AuthRealm} setting without invalidating existing passwords.
• Cross-platform compatibility issues between Linux, Apple OSX and MS Windows have been resolved and .htpasswd files should be portable regardless of the selected encoding.
• The Crypt::PasswdMD5 CPAN module is required for the apache-md5 encoding, as well as for better cross-platform compatibility.

Note: It is strongly recommended that sites using the old default "crypt" encoding migrate to a stronger method. The crypt method truncates passwords at 8 characters and silently discards the rest. For the highest security, choose htdigest-md5 encoding with Apache htdigest authentication. If using Template authentication, if possible use a SSL client connection - HTTPS.

Changes to User Registration topics Item1539

The URL parameters passed in from User Registration were previously still prefixed with Twk. This has been changed to Fwk to be consistent with Foswiki naming conventions. Note however that backwards compatbility has been maintained and either prefix can still be used, so it is not required to update customized User Registration topics.

Changes to Foswiki Logging - Item10637, Item11157

A new Logging method has been added: Foswiki::Logger::PlainFile::Obfuscating. If this module is chosen as the Logger, IP addresses by default will be replace with a pseudo-address derived from a MD5 hash of the original address. This is provided for use in regulatory domains where systems are not permitted to track IP addresses of users.

• An Expert parameter is provided to use a mask (x.x.x.x) instead of the hashed IP address where absolute anonymity is required.
• Note that AUTHENTICATION FAILURE messages are never obfuscated. This permits tools like fail2ban to be used to block penetration attempts.

Major JQuery changes

• Foswiki has been updated to include JQuery 1.7.1, and this is now the default version of JQuery. After installing Foswiki 1.1.4, be sure to visit bin/configure and verify that the JQuery Plugin is configured to use this version.
• The JQuery Autocomplete plugin has been replaced by the incompatible JQueryUI Autocomplete widget. If your site has implemented forms using the old version of Autocomplete, they will not work until converted to the new API. See https://foswiki.org/Support/JQueryMigrationGuide
• The JQuery Textboxtlist plugin has been updated with an incompatible version. See the above referenced JQueryMigrationGuide for details.
• The JQuery Chili syntax highlighting plugin is incompatible with Firefox 7 and Safari Rev. 6-17-2011.

Changes to Store

Foswiki has improved handling of files that are modified outside of Foswiki's control. Topic changes made by external programs may cause unexpected results. The following behaviour is expected:

• If a topic is modified (file revision date of file is newer than the date of the .txt,v file):
  • The TOPICINFO metadata stored with the topic textfile is ignored.
  • Modified by is reported as UnknownUser
  • Modified timestamp is the file timestamp
  • Revision number is 1 greater than the last revision known to RCS.
  • Topic comment is pending, indicating there are changes not yet checked into RCS.
  • The next change to the topic under Foswiki control will record the external changes into RCS, and create a new revision for the changes saved in this iteration.
• If a topic rcs .txt,v file is newer than the topic file
  • The TOPICINFO is trusted
  • This avoids unnecessary overhead by the RCS system.
• If a topic is modified externally and checked into RCS outside of Foswiki control, it is very important to generate a valid TOPICINFO line or the data reported by Foswiki will be incorrect.

Note that Foswiki also now requires that the %META:TOPICINFO be the first line of the file.

Changes to SpreadSheetPlugin

Several SpreadSheetPlugin functions were found to provide inconsistent results when cells contained leading spaces. Leading/trailing spaces are part of cell formatting and should be uniformly stripped when extracting data from cells.

• LEFTSTRING position of first character would vary.
• LISTUNIQUE would fail to eliminate duplicate entries due to leading or trailing spaces.

Changes were made in the code that extracts cell data to uniformly remove leading and trailng spaces. This change may require changes to spreadsheet formula if they had been adjusted to accommodate these spaces. Unit tests have also been added to better detect inconsistencies and improve the quality of this plugin.

Also the SpreadSheetPlugin was synchronized with features added to the TWiki version of the plugin. This added the following functions:

• SPLIT( separator, text ) -- split a string into a list.
• HEXENCODE and HEXDECODE -- Encode and decode a string to/from printable hex.
• XOR( list ) Logical XOR of integers in a list.
• BITXOR( list ) -- Bitwise XOR of integers in a list.
• BITXOR( string ) -- Bitwise NOT operation on the string.
• LISTNONEMPTY( list ) -- Remove all empty elements from a list
• WHILE( condition, do ) -- Repeat the "do" function while the "condition" remains true.
• isodate formats -- ISO 8601 week support.
• DOY -- Day of Year dates: DOYyyyy.ddd for example to specify the ddd day of yyyy

Changes to JSCalendarContrib.

The changes to JSCalendarContrib made post 1.1.3, and released in JSCalendarContrib version 1.4.x have been reverted. The changes attempted to make dates stored in the formfields format per the requested JSCalendarContrib format. However it was incompatible with alternative date formats that were not understood by the core Foswiki time code. JSCalendarContrib saves dates in whatever format is set in the configuration {JSCalendarContrib}{format}. If the format is changed, Foswiki makes no attempt to change the displayed format of existing dates. The format can be updated by re-selecting the date using the calendar display.

Important changes in Foswiki 1.1.3

SEARCHDEFAULTTTYPE restored

The default search type used in the WebSearch page was not carried forward from 1.0. to 1.1. This option has been restored in 1.1.4, with some changes:

• It only applies to the WebSearch and WebSearchAdvanced. On Foswiki 1.0 it also applied to the %SEARCH macro.
• The (ignored) default in DefaultPreferences is keyword, but on 1.1, WebSearch defaulted to word
• WebSearchAdvanced had a hardcoded default of word on both 1.0 and 1.1. This is changed to use the SEARCHDEFAULTTTYPE setting.
• The historical mis-spelling (SEARCHDEFAULTTTYPE) is preserved.

Important Changes in Foswiki 1.1.2

Changes to %GROUPS% and %GROUPINFO% Macros

See https://foswiki.org/Tasks/Item10176. On releases prior to Foswiki 1.1.3 it was possible that the GROUP related macros could expose User WikiNames that would be hidden from the currently autenticated user. This has been changed, and if the current user does not have VIEW authority for the user's topic, then the user will not be shown as a group member. See the new FAQHiddenUsersAndGroups topic for more information.

JQueryPlugin update to jQuery 1.4.3

On releases prior to Foswiki 1.1.3, JQueryPlugin shipped with jQuery 1.3.2 enabled. It now uses 1.4.3, and some Foswiki javascript will no longer work correclty with 1.3.2 and earlier. As a result, upgraders will need to

1. set {JQueryVersion} in configure under Extensions -> JQueryPlugin to 1.4.4
2. Clear browser cache
3. test non-default plugins and any custom jQuery javascript code for compatibility with jQuery 1.4.3.

Improved handling of legacy logging format

Foswiki 1.1 changed the logging format and the default location of the log files. See below for more information.

As of 1.1.3, if any of the 1.0 Debug, Warning or Log filenames are found, the "compatibility" logger will be used regardless of the Implementation setting.

Important changes in Foswiki 1.1.0

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, to plug in. Most of these modifications should be invisible to the end user and the admin, but are important to position Foswiki for the next generation of improvements. Here is a list of the most important enhancements in Foswiki 1.1.0

Adoption of the jQuery Javascript user interface framework

Since Foswiki 1.1, the industry-standard jQuery Javascript user interface framework has been more closely integrated; the existing JQueryPlugin is included into the core distribution. Reflecting the move to jQuery, the BehaviourContrib has been removed from the core distribution; it is still available for download from Foswiki.org. The default PatternSkin now depends on this jQuery framework.

Also added are the new ADDTOZONE and RENDERZONE macros that manage dependencies between Javascript modules, making use of this sophisticated toolset much easier. See Foswiki:Development.UpdatingExtensionsScriptZone on how to replace ADDTOHEAD usage.

New macros enabled by jQuery

• BUTTON{"text" ...} -- renders a nice button
• TABPANE{...}, ENDTABPANE, TAB{"text" ...}, ENDTAB -- tabpane widget
• JQICON{"name" ...} -- render an image
• JQICONPATH{"name"} -- render the urlpath to an image
• JQPLUGINS{"plugins" ... } -- display a summary of avaliable plugins
• JQREQUIRE{"plugin, plugin, ... "} -- enable a plugin on the current page
• JQTHEME{"name" ...} -- switch jQuery UI theme
• POPUPWINDOW{"topic" ...} -- opens a topic or url in a new window

See JQueryPlugin for details.

Powerful new QUERY macro

A number of new features have been added with the goal of improving support for wiki applications. These include the powerful new QUERY macro, which:

• supports formatted access to formfields and other meta-data in topics using the same syntax as is used in IF and SEARCH statements,
• gives access to all meta-data, including that added by extensions,
• supports reporting values using JSON and other standards, simplifying the retrieval of meta-data for REST applications,
• replaces the FORMFIELD macro for most applications.

Use of the "formfield" parameter to the META macro has been deprecated (it is still available, but use is discouraged and it will be removed at some point in the future).

Re-architecting of the SEARCH macro

To improve the speed, consistency and extendability of the most complex and important Macro, we've started to separate the generation of search results from the outputing of FormattedSearch. The most significant user facing improvements are speed and reliability changes - with many more unit tests written to ensure future compatibility.

FORMAT macro

The extraction of the FormattedSearch system has made it possible to provide a Macro that allows users to render a list of topics into any header, footer, format style, using the same formatting controls as used by SEARCH. This macro will be further enhanced in future Foswiki releases and will play an increaingly important role as it is extended to format other types of object lists.

WikiGroups have add & remove user interface

WikiGroups are now be edited using a much simpler HTML form.

For developers additional API's have been added to the Foswiki code to allow these Forms to also be used for non-Foswiki user and group backends.

With some configuration, Foswiki can also add users to groups on registration - either automatically, or allowing the users to select groups to join.

TinyMCEPlugin updates

TinyMCEPlugin has been updated to the latest 3.3 release from Moxiecode. Additionally, several improvements to the Foswiki integration have been made, such as:

• Smarter attach dialogue
• Background autosave feature has been enabled (saves to local browser storage at 3 minute intervals)
• New context (right-click) menu:
  • Set syntax highlighting classes on verbatim blocks
  • table rows/columns may be duplicated, cells merged/split
• Customisation via the TINYMCEPLUGIN_INIT preference has been improved. Read the upgrade advice if you are upgrading a Foswiki installation which uses a custom TINYMCEPLUGIN_INIT preference setting.

Testing configuration variables in %IF

Prior to 1.1, %IF could be used to test the value of any configuration variable (those defined in configure). This represented a security risk, so now only those variables listed in {AccessibleCFG} may be accessed this way. Note that {AccessibleCFG} also controls which variables are visible in %SEARCH{type="query" and the new QUERY macro.

"Copy topic" now copies attachments

The "Copy Topic" function in "More topic actions" now copies attachments as well as the topic text and form.

Tailoring of user registration made easier.

The topic UserRegistration has been enhanced so it now determines whether a custom user registration page exists in Main, and includes it if it does; otherwise it includes DefaultUserRegistration.

This means that your tailored version in Main web will not be overwritten by future upgrades.

You can create a custom version of the UserRegistration form by first copying the topic 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 simple as possible. You can unhide those fields on the page by removing EXCLUDED_ from the INCLUDE tags).

Easy tailoring of reset/change password and change email forms

The topics ResetPassword and ChangePassword now only show the change forms when Foswiki is managing the passwords (the configure setting {PasswordManager} set to a manager that handles setting of passwords).

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

ChangeEmailAddress will now guide the user to define the email address in the user topic when the PasswordManager does not handle hidden email addresses, so you should not need to tailor this topic any longer.

TMPL:DEFs may now access previous (overridden) TMPL:DEF

SkinTemplates authors are often limited by the fact that %TMPL:DEF{"something"}% statements override whatever DEF may have previously existed in the SKIN path. Now, when overriding these DEFs, SkinTemplates authors may access the previous definition using the new %TMPL:PREV% template token.

New Logging architecture and location for log files

The Foswiki logging architecture has been changed to make processing of the "current" logs easier, and the logs have been moved from the data/ directory into working/logs. The configuration of the logging files have also been updated.

If Foswiki detects the presence of the old logging configuration, it will continue to use the old files. configure will issue warnings about the deprecated settings.

Migration considerations

Foswiki provides two Logger implementations selectable in configure. Foswiki::Logger::Plainfile implements the new file naming conventions and locations. Foswiki::Logger::Compatibility uses the old locations and settings. The Compatibility logger is used if the old file locations are detected in the configuration.

The primary use of the logs by Foswiki is for generation of Statistics. If changing to the new logger ( strongly recommended ) it is best to get a full statistics refresh prior to migration. Copy / rename the log files into their new location using the above table as a guide. Manually edit lib/LocalSite.cfg to remove the obsolete parameters, and then run configure to verify the new settings.

Logging Configuration

The 1.0 configuration settings should be manually removed from LocalSite.cfg, and configure then used to verify the new settings. If the 1.0 Warning filename is found, the "compatibility" logger will be used even if the PlainFile logger is selected.

• As of Release 1.1.6, the Compatibility logger can be configured using the configure web interface. On extremely busy systems with very large log files, the Compaibility logger provides better performance at month end because it does not "rotate" the log files.
• Some very old (pre-Foswiki) Extensions write directly to Log File configured in $Foswiki::cfg{LogFileName}. Foswiki will attempt to set a reasonable default value to maintain backwards compatibility. It is recommended to configure this filename if you run old pre-Foswiki extensions that write directly to the log.

$Foswiki::cfg{Log}{Implementation} = 'Foswiki::Logger::PlainFile';
$Foswiki::cfg{Log}{view} = 1;
$Foswiki::cfg{Log}{search} = 1;
$Foswiki::cfg{Log}{changes} = 1;
$Foswiki::cfg{Log}{rdiff} = 1;
$Foswiki::cfg{Log}{edit} = 1;
$Foswiki::cfg{Log}{save} = 1;
$Foswiki::cfg{Log}{upload} = 1;
$Foswiki::cfg{Log}{attach} = 1;
$Foswiki::cfg{Log}{rename} = 1;
$Foswiki::cfg{Log}{register} = 1;
$Foswiki::cfg{ConfigurationLogName} = 'foswiki-root/data/configurationlog.txt';
$Foswiki::cfg{DebugFileName} = 'foswiki-root/data/debug.txt';
$Foswiki::cfg{LogFileName} = 'foswiki-root/data/log%DATE%.txt';
$Foswiki::cfg{WarningFileName} = 'foswiki-root/data/warn%DATE%.txt';

$Foswiki::cfg{Log}{Dir} = '$Foswiki::cfg{WorkingDir}/logs';
$Foswiki::cfg{Log}{Implementation} = 'Foswiki::Logger::PlainFile';
$Foswiki::cfg{Log}{Action} = {
          'search' => 1,
          'rest' => 1,
          'viewfile' => 1,
          'edit' => 1,
          'register' => 1,
          'save' => 1,
          'rename' => 1,
          'changes' => 1,
          'view' => 1,
          'rdiff' => 1,
          'upload' => 1,
          'attach' => 1
        };
$Foswiki::cfg{DebugFileName} = '';
$Foswiki::cfg{LogFileName} = '';
$Foswiki::cfg{WarningFileName} = '';

Logging of access failures

Configure and TemplateLogin now log authentication failures to the event logs:

• working/logs/configure.log
• working/logs/events.log

It is possible to monitor these logs with a product like fail2ban which will set firewall filters due to excessive failures.

configure user interface revamp

Also included in 1.1 is a major improvement to the configure user interface, that clarifies and simplifies setting configuration options.

Configure file system checks

The configuration tool bin/configure now performs extensive checks of file system permissions. The pub and data directories are checked to verify that all data files match the requested default permissions of 755 for directories and 644 for data files. Files with excess permissions are reported as a warning. Files with insufficient permissions are noted as an error.

Because of prior inconsistencies in the files distributed with Foswiki and TWiki core and extensions, migration of older Foswiki or TWiki installs may see excessive errors reported by configure. You are recommended to correct the file system permissions.

Newer modern icon set for Document Graphics

To celebrate our new look, project and momentum, Foswiki now has a new ICON set to update the one shipped for the last 10 years. Using the FamFamFam icon set, augmented with icons from other leading graphic artists.

Table Plugin has been improved

HTML formatting has been replaced by pure CSS rendering. You can however enable inline markup HTML, in addition to the CSS markup, by setting the new parameter inlinemarkup to "on". This is useful if your users often copy/paste content of topics containing tables into HTML formatted emails or Office documents.

Sorting has been improved so the plugin can now better handle mix of formats and even empty cells.

!1 Notes for extension authors

API Enhancements

The following functions have been added to the Foswiki::Func API:

• copyAttachment

New parameters can be found on:

• saveTopic (ignorepermissions)

Deprecated handlers

The following handlers have been deprecated (i.e. they are still available, but should not be used in new code and will be removed in a future release, so if you have been used them, you need to modify your code).

The redirectCGIQueryHandler plugin handler has been deprecated (it is still available, but should not be used in new code and will be removed in a future release, so if you have been used it, you need to modify your code). This handler assumed a level of interaction with the CGI handling process that is dangerous if misused, and severely limits the flexibility and optimisations available to the core.

The beforeAttachmentSaveHandler and afterAttachmentSaveHandler plugin handlers have been deprecated in favour of the newly-added beforeUploadHandler and afterUploadHandler. The new handlers operate on streams, and are more efficient as well as more secure.

Deprecated handlers will continue to work as documented in 1.1 and for the immediate future, but will be removed in a future release. Extension authors are strongly recommended to implement the new handlers as soon as possible.

Deprecated Foswiki::Func functions

The readTopicText and saveTopicText functions have been deprecated. Use readTopic and saveTopic instead. Both readTopic and saveTopic have always been available in Foswiki (and its predecessor) and are a lot safer. Existing code can usually be modified to eliminate these deprecated functions without difficulty.

Note: readTopicText had implicit access control checks. The replacement method, readTopic does not, so calling code must call checkAccessPermission explicitly.

Refactored Foswiki::Store and new Foswiki::Meta functions

Access checking has been moved from Store up to the Meta and Func routines. This was done to improve perfomance of the Store backend and simplify implementation of different stores e.g. using databases.

Store was never part of the Foswiki or TWiki API. Extensions which violate this API and reference Store:: functions directly could potentially have access that was previously blocked by Foswiki and/or may require other changes to be compatible with Foswiki 1.1.

Extension authors should first try to use the Foswiki::Func API. This is the preferred API. Pay careful attention to whether or not each Func:: method verifies access control and use the Foswiki::Func::checkAccessPermission to verify access.

Foswiki::Meta should be used only if Foswiki::Func does not have a needed function. Note that Foswiki::Meta functions do not implicitly perform any access control checks. Callers of Foswiki::Meta= should first use the Foswiki::Meta::haveAccess function to verify access for the planned actions. This was done by design to reduce repetitive access control checks and improve performance.

Tainting

The Foswiki core now checks values used for web, topic and attachment names for 'taintedness' when FOSWIKI_ASSERTS are enabled. Tainted values are those that have been taken from user input (for example, from topic content or from form fields) without being validated. Such unchecked values are a large potential security hole, and the authors of plugins that manipulate topics or attachments need to check their plugins with Foswiki ASSERTs enabled. If you find a taint error, you can use the functions in Foswiki::Sandbox to validate them. For example, to validate a web name and a topic name, you would write:

$validWebName = Foswiki::Sandbox::untaint(
    $webName, \&Foswiki::Sandbox::validateWebName);
$validTopicName = Foswiki::Sandbox::untaint(
    $topicName, \&Foswiki::Sandbox::validateWebName);

If $webName is not a legal web name, then $webName will end up being undefined. Similarly for the topic name.

Note that values are only checked for taintedness when FOSWIKI_ASSERTS are enabled, so unless you run your Foswiki in this mode, you will never see the errors. To enable asserts, simply add the line:

$ENV{FOSWIKI_ASSERTS} = 1;

to your bin/LocalLib.cfg.

Foswiki Release 1.1.0 Details

Fixes

Enhancements

Foswiki Patch Release 1.1.1 Details

Fixes

Enhancements

Foswiki Patch Release 1.1.2 Details

Fixes

Enhancements

Foswiki Patch Release 1.1.3 Details

Fixes

Enhancements

Foswiki Patch Release 1.1.4 Details

Fixes

Enhancements

Foswiki Patch Release 1.1.5 Details

Fixes

Enhancements

Foswiki Patch Release 1.1.6 Details

Fixes

Enhancements

Foswiki Patch Release 1.1.7 Details

Fixes

Enhancements

Foswiki Patch Release 1.1.8 Details

Fixes

Foswiki Patch Release 1.1.9 Details

Fixes

Enhancements

Foswiki Patch Release 1.1.10 Details

Fixes

Enhancements

Related Topic: ReleaseHistory ReleaseNotes01x00