Release Notes for XWiki 10.8

Version 17.2 by Thomas Mortagne on 2018/09/24
Warning: For security reasons, the document is displayed in restricted mode as it is not the current version. There may be differences and errors due to this.

This is the release notes for XWiki Commons, XWiki Rendering and XWiki Platform. They share the same release notes as they are released together and have the same version.

In this version we have added a new tab in the user profile that displays the groups a user is part of. We've added auto-suggest for pages in several places and improved the startup speed on Tomcat. We've also replaced our CAPTCHA implementation with a new one and it's now very easy to change and preview, from Administration, the CAPTCHA type that it will be used in your wiki. The Menu application is now directly accessible through the Administration.

New and Noteworthy (since XWiki 10.7)

Full list of issues fixed and Dashboard for 10.8.

For Users

New CAPTCHA API and CAPTCHA implementations

A new CAPTCHA Application and API have been implemented, replacing the old Captcha Module, thus making it even easier to use and validate a CAPTCHA in a form. Also, it's now very easy to change the CAPTCHA implementation that you want to use in your wiki, directly from Administration, without having to touch a line of code.

Also, a new and much more extensive JCaptcha implementation has been provided for the new API, that works offline and features image, sound and text CAPTCHAS. It is bundled by default with XWiki Standard.

As a popular alternative, a Google reCAPTCHA implementation is also available, installable as an extension using the Extension Manager.

The locations in XWiki where CAPTCHA is being used by default (e.g. Registration and Comments) will use the CAPTCHA implementation that you have enabled and configured in the "Administration >> CAPTCHA" section.

Auto-suggest for pages

Several inputs related to selecting pages references now support auto-suggestion, making it much simpler to use and less error prone (such as not having to know if the reference should end with WebHome or not!). See the screenshots for some examples.

User membership in the profile

It's now possible to see the groups a user is member of in the profile. See User Profile Application.

Updated attachments modal

The attachments pop-up that is displayed for deleting an attachment is now a bootstrap modal, having the same functionality as before.


  • Filter group members by their full name: You can now filter the group members by their full name from the live table displayed on the group page or when editing a group from the administration, as long as the members are from the same wiki as the group itself. The members that are from a different wiki than the group can still be filtered by their reference (e.g. by user alias).

For Admins

Menu is now available in Administration

The Menu application is now available through the Administration under the Look & Feel category. By default, the application is now hidden from the panels of applications.


  • XWiki on WildFly: XWiki now deploys fine out of the box on WildFly 14.x.

  • Notifications Filters Store: Due to scaling issue, we have changed the way the notification filter preferences are stored in the wiki. They are not saved in the user profile pages anymore, but in their own database table.

    A migration to the new store is necessary for existing filter preferences. It is done automatically when you first start XWiki after upgrading, but it may take time.

    Thanks to this improvement, we have re-enabled the default behavior for the Auto Watch feature so that users automatically watch pages they have contributed to.

  • Argument to specify the wait time in the script: You can now specify, in the script, the number of seconds to wait for the XWiki lock to be released before exiting. For instance " -wt 10" will make the script wait 10 second. The default wait time is now 30sec.

For Developers

Group manager

A new and corresponding script service are now available.

See more details on User Module.


  • No longer committing XML document date fields: Our maven XAR plugin's xar:verify goal will now fail the build if the XAR module contains XML pages with date fields in them. To clear them automatically, just use xar:format which was also updated to remove such fields. This behavior can be skipped for individual files or for the entire project. See the documentation for more details.

  • A new xwiki-commons-collection module has been introduced to share base collection related API

Moved Modules


The following runtime dependencies have been upgraded (they have a different release cycle than XWiki Commons, XWiki Rendering and XWiki Platform):


The following translations have been updated: 

Known issues

Backward Compatibility and Migration Notes

General Notes

When upgrading make sure you compare your xwiki.cfg, and web.xml files with the newest version since some configuration parameters may have been modified or added. Note that you should add so that XWiki will attempt to automatically migrate your current database to the new schema. Make sure you backup your Database before doing anything.

Issues specific to XWiki 10.8

  • A migration to the new store is necessary for existing filter preferences. It is done automatically when you first start XWiki after upgrading, but it may take time.

    If you had installed XWiki 10.8RC1, then we changed the new notifications filter table name, which was notification_filter_preferences (in 10.8RC1) to notification_filter_prefs. The previous name was too long for Oracle and was causing a bug. Since it was not a final version, we have decided not to handle the migration.
    However, if you really need to upgrade from XWiki 10.8RC1, you need to manually update the database of each wiki, and rename the table "notification_filter_preferences" to "notification_filter_prefs". With MySQL, the command would be:
    RENAME TABLE notification_filter_preferences TO notification_filter_prefs;

    Upgrades from prior versions are still supported and automated.

  • XWiki has been configured to increase startup speed by avoiding JAR scanning, especially on Tomcat. The following was done, which you can modify if you need JAR scanning for some reason (not used by XWiki Standard by default):
    • Addition of metadata-complete="true" and <absolute-ordering /> in XWiki's web.xml
    • Addition of a META-INF/context.xml Tomcat-specific deployment file in XWiki's WAR to prevent Tomcat from doing JAR scanning completely and to avoid scanning for JSP and WebSocket.
  • Auto redirects are now off by default when moving/renaming pages. Rationale:
    • Several users have reported a usability issue about automatic redirects. The way they express it is the following: "I have duplicates pages in my wiki. I don't understand why this is happening. I'm choosing to rename pages and not to copy them but I still get duplicates in the Navigation panel".
    • Automatic redirects are especially useful for public wikis where users can have bookmark on pages and you don't want to break them. It can also be useful for internal wikis but it's less an issue.
    • Even for public wikis not all pages need automatic redirects. Technical pages don't need them for example.
    • We don't have management UIs for redirects FTM and reducing the number of redirects make the wiki easier

    In the future we'll offer a config option to define the default behavior.

API Breakages

The following APIs were modified since XWiki 10.7:

Failed to execute the [groovy] macro. Cause: [Error number 9001 in 9: Access denied in edit mode on document xwiki:ReleaseNotes.Data.XWiki.10\.8.WebHome]. Click on this message for details.


The following people have contributed code and translations to this release (sorted alphabetically):

Adel Atallah
Alex Cotiugă
Constantin Listar
Dominik Roszkowski
Ecaterina Moraru (Valica)
Eduard Moraru
Guillaume Delhumeau
Ilie Andriuta
Marius Dumitru Florea
Oana-Lavinia Florean
Roman Ivanov
Simon Urli
Thomas Mortagne
Valdis Vitolins
Vincent Massol


Get Connected