Release Notes for XWiki 17.4.0

Last modified by Ilie Andriuta on 2025/05/29

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.

This release introduces the capability for users to toggle the panel columns to improve usability and navigation, and for admins to define the required rights of pages for better security. On top of that, a few macros have been improved for developers and Live Data now runs with Vue 3. This release also contains security fixes, with the highest severity being 9.3.

New and Noteworthy (since XWiki 17.3.0)

Full list of issues fixed and Dashboard for 17.4..

For Users

Toggle panel columns

 
When panels are displayed on the right and left of the page, a toggle appears on hover. Interacting with the toggle will either hide or show the panel column. Hiding a panel column will also reset the preference for this column width. The state of the columns is synchronized across tabs. This preference is stored at the browser level, meaning that navigating to a new page ont he same wiki will not lose this preference, but moving to another machine will. Read more about the panel layout and how this new toggle interacts with the existing system.

Regular case on form labels

 
To improve legibility on XWiki forms, all form labels use regular case now, instead of uppercase.

For Admins

New UI for setting required rights

 
A new UI for setting the required rights of a page has been added. Required rights are the rights that a page requires for executing script macros or registering a UI extension. This new UI allows selecting if required rights shall be enforced, and allows specifying which rights shall be enforced. When required rights are enforced, the page can only use the specified rights and only users with those rights can edit the page. This avoids that, for example, a script macro added by a user without script right is executed when a user with script right saves the page, or that users accidentally break a page when they edit it without having the required rights.

For Developers

Live Data components store

 
With the migration to Vue 3, a new mechanism was required to register additional components (in addition to the ones already registered by default).
In addition, even components registered by default are now dynamically loaded. For instance, if a Live Data is only displayed cells of type text, only the text displayer will be loaded on the page.

Example:

import { componentStore } from "xwiki-livedata";

// Dynamically register a new "toggle" displayer component.
componentStore.register("displayer", "toggle", async () => {
 return (await import("./components/DisplayerToggle.vue")).default;
});

Miscellaneous

  • document macro filters parameter: The documents macro now provides a filters optional parameter. It allows for the definition of a default filtering of the Live Data displaying the list of documents.

  • Conversion filter made more generic: The conversion (servlet) filter allows WYSIWYG editors to submit HTML even if the edited content is supposed to be saved as wiki syntax, by intercepting the request and replacing the HTML with the conversion result. But not all WYSIWYG editors are using HTML internally to edit the content. In order to support such editors we made the conversion filter more generic, allowing it to convert from any input syntax (for which there is a parser) to any output syntax (for which there is a renderer). The WYSIWYG editor needs to submit 4 parameters, like this:

    fieldName=value
    RequiresConversion=fieldName
    fieldName_inputSyntax=foo/1.0
    fieldName_outputSyntax=xwiki/2.1

    Replace "fieldName" with the name of the edited field and replace "foo/2.1" with the syntax expected by the editor as input. See the WYSIWYG Editor module for more information.

  • New parameter in the Location Picker Macro: New parameters have been added to the locationPicker velocity macro: filterHiddenDocuments, root and sortDocumentsBy.

    These new parameters are just passed to the Document tree macro.

  • UserManager#hasUsers: The UserManager API now offers a way to check if a given wiki contains users: UserManager#hasUsers(WikiReference wiki).

Upgrades

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

Translations

The following translations have been updated:

Tested Browsers & Databases

Automated testing

XWiki executes a lot of automated tests during its build, testing all supported configurations. In addition, some manual QA is also executed to try to discover additional problems (see below):

Manual testing

Here is the list of browsers we support and how they have been manually tested for this release:

 BrowserTested on:
Firefox30.pngMozilla Firefox 139Not Tested
Chrome30.pngGoogle Chrome 137Jira Tickets Marked as Fixed in the Release Notes
Edge30.pngMicrosoft Edge 137Tests run and results
Safari30.pngSafari 18Not Tested

Here is the list of databases we support and how they have been manually tested for this release:

 DatabaseTested on:
hypersql.pngHyperSQL 2.7.4Not Tested
mariadb.pngMariaDB 11.7Tests run and results
mysql.pngMySQL 9.3Jira Tickets Marked as Fixed in the Release Notes
postgresql.pngPostgreSQL 17Not Tested
oracle.pngOracle 19cNot Tested

Here is the list of Servlet Containers we support and how they have been manually tested for this release:

 Servlet ContainerTested on:
tomcat-icon.pngTomcat 11.0.7
jetty-icon.pngJetty 12.0.19 (XWiki Standalone packaging)Not Tested
jetty-icon.pngJetty 12.0.20Not Tested

Security Issues

Security issues are not listed in issue lists or dashboards to avoid disclosing ways to use them, but they will appear automatically in them once they're disclosed. See the XWiki Security Policy for more details.

Known issues

Backward Compatibility and Migration Notes

General Notes

  • When upgrading make sure you compare and merge the following XWiki configuration files since some parameters may have been modified, removed or added:
    • xwiki.cfg
    • xwiki.properties
    • web.xml
    • hibernate.cfg.xml
  • Add xwiki.store.migration=1 in xwiki.cfg so that XWiki will attempt to automatically migrate your current database to any new schema. Make sure you backup your Database before doing anything.

Issues specific to XWiki 17.4.0

Live Data Vue Components registration

With the upgrade to Vue 3, the former mechanism to load additional components is not supported.
If you are using code such as the one presented below, please migrate your component to Vue 3 as well, and see the Live Data Component store section to migrate.

Vue.component('DisplayerXXX', DisplayerXXXVue2Component);

Removed Mail Plugin

The Mail Plugin was a non-finished feature that was supposed to be used to be able to send mail to XWiki to bring modifications to wiki pages. It's now been removed and you'll need to remove its entry in xwiki.cfg to avoid the following log error in the XWiki logs:

2025-05-20 17:16:15,170 [XWiki initialization] ERROR c.x.x.p.XWikiPluginManager     - Cannot initialize plugin [com.xpn.xwiki.plugin.mail.MailPlugin]. This plugin will not be available.
java.lang.ClassNotFoundException: com.xpn.xwiki.plugin.mail.MailPlugin
        at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:440)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
        at org.xwiki.classloader.xwiki.internal.ContextNamespaceURLClassLoader.loadClass(ContextNamespaceURLClassLoader.java:176)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:467)
        at com.xpn.xwiki.plugin.XWikiPluginManager.addPlugin(XWikiPluginManager.java:83)
        at com.xpn.xwiki.plugin.XWikiPluginManager.addPlugins(XWikiPluginManager.java:118)
        at com.xpn.xwiki.XWiki.preparePlugins(XWiki.java:1654)
        at com.xpn.xwiki.XWiki.initXWiki(XWiki.java:1371)
        at com.xpn.xwiki.XWiki.initXWiki(XWiki.java:1293)
        at com.xpn.xwiki.XWiki.<init>(XWiki.java:1266)
        at com.xpn.xwiki.internal.XWikiInitializerJob.runInternal(XWikiInitializerJob.java:103)
        at org.xwiki.job.AbstractJob.runInContext(AbstractJob.java:246)
        at org.xwiki.job.AbstractJob.run(AbstractJob.java:223)
        at java.base/java.lang.Thread.run(Thread.java:833)

The change to bring to xwiki.cfg is the following:

[...]
#-# List of active plugins.
xwiki.plugins=\
  com.xpn.xwiki.monitor.api.MonitorPlugin,\
  com.xpn.xwiki.plugin.skinx.JsSkinExtensionPlugin,\
  com.xpn.xwiki.plugin.skinx.JsSkinFileExtensionPlugin,\
  com.xpn.xwiki.plugin.skinx.JsResourceSkinExtensionPlugin,\
  com.xpn.xwiki.plugin.skinx.CssSkinExtensionPlugin,\
  com.xpn.xwiki.plugin.skinx.CssSkinFileExtensionPlugin,\
  com.xpn.xwiki.plugin.skinx.CssResourceSkinExtensionPlugin,\
  com.xpn.xwiki.plugin.skinx.LinkExtensionPlugin,\
  com.xpn.xwiki.plugin.feed.FeedPlugin,\
  com.xpn.xwiki.plugin.mail.MailPlugin,\ <---- Remove this line
  com.xpn.xwiki.plugin.packaging.PackagePlugin,\
[...]

New meta.vm template

When the XWiki.XWikiPreferences^XWiki.XWikiPreferences[0].meta field is emptied if it matched the default value when upgrading to 17.4.0RC1.
You can consult this field from the UI by going to the Presentation section of the administration, under the Look & Feel category. Then check the HTTP Meta Info field.

  • When the meta field is empty, the new meta.vm template file is used.
  • After upgrading, it is advised to check if the meta field is empty. If that's the case and no customization has been performed, you can check the history to verify if minor, irrelevant changes can be found. If that's the case, it is possible to empty the meta field by yourself.

XWiki now overwrites the standard application server request URL resolution

We had too many erratic/buggy behaviors with various application servers not properly following proxy headers, so we decider to not trust them anymore: XWiki now overwrite in a Servlet filter the behavior of ServletRequest#getScheme(), ServletRequest#getServerName(), ServletRequest#getServerPort() and HttpServletRequest#getRequestURL() so those should now have the same behavior to matter the application server used and its setup.

API Breakages

The following APIs were modified since XWiki 17.3.0:

No breakage!

Credits

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

  • Alex Cotiugă
  • Josue-T
  • LucasC
  • Manuel Leduc
  • Marius Dumitru Florea
  • Michael Hamann
  • Simon Urli
  • Simpel
  • Thomas Mortagne
  • Tomek
  • Vincent Massol
  • Xiaofei Cui
  • jan2xue
  • tkrieck
  • xrichard

Get Connected