Release Notes for XWiki 17.5.0

Last modified by Simon Urli on 2025/06/30

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 brings a new UI for configuring macro in the WYSIWYG editor that should provide a better user experience: parameters can be ordered, the order is stable and we clarified optional and mandatory parameters. For admins, it's now possible to overwrite properties using environment variables or Java system properties. Also we started to enforce required rights in some bundled pages, and improved the mechanism to only require admin right in skin extension. Performance has been tackled with the Solr search indexing speed. Last but not least, we defined for developers a dedicated webjar-node packaging type to help contributions using nodejs. This release also contains security fixes, with the highest severity being 9.3/10

New and Noteworthy (since XWiki 17.4.1)

Full list of issues fixed and Dashboard for 17.5.0.

For Users

Revamping of the macro configuration UI

 
The macro configuration UI displayed in the WYSIWYG editor has been entirely revamped to improve its usability and for supporting order of parameters. This revamping brings a new UI to better display groups and features in macro parameters, and also allows to support validation of mandatory features. On top of that it also guarantees the stability of the displayed order of the parameters.

Updated the Live Data pagination

 
Standardized the look of the Live Data pagination to fit better in the standard Flamingo Skin.

For Admins

  • Dynamic configuration input: It's now possible to overwrite properties from configuration files like xwiki.cfg, xwiki.properties using Java system properties or environment variables. See Configuration Module for more details.

    New configuration also been introduced to benefit from it:

  • Skin extensions on this wiki require just wiki admin right: Skin extensions that are always active on this wiki now require just wiki admin right instead of programming right. This makes the required rights more consistent as UI extensions with the same scope also just require wiki admin right and already allowed activating skin extensions on a whole wiki. Further, this should reduce problems when admins without programming right install extensions, for example, on a subwiki.

  • Improved Solr search indexing speed: The batch size of the Solr search index has been increased to speed up indexing. To further speed up indexing, documents are now submitted in batches to Solr (using the same batch size) and batches are now prepared in parallel to the indexing of the previous batch. This slightly increases the memory usage as two full batches of data to index might be kept in memory. You can control the memory usage by adapting the number of characters after which a batch is committed, the (new) default is 10 million.

  • Started enforcing required rights in some bundled pages: After adding the possibility to configure required rights of pages in XWiki 17.4.0, we're now starting to slowly enforce required rights for wiki pages that are part of a standard XWiki installation. In this release, we're starting with the Alerts Application and the Annotation Application.

For Developers

Improved support for webjar built using node

 
Building the artifacts of a webjar using node is becoming a pattern we use more and more frequently.

To simplify this usecase, the webjar-node packaging type has been introduced.

Using this packaging type allows for more concise pom definitions, ensure a standard projects structures, commons node and npm version, and a default build lifecycle.

Miscellaneous

  • Possibility to define the order of content and parameters in Wiki Macros: It's now possible to specify the order of the wiki macro parameters: a new property "order" is available in the WikiMacroParameterClass allowing to define the order of each parameter. This order defines how the parameters are sorted in the macro configuration UI. The lower the value for the order, the higher the priority to display them in the configuration UI. Note that it's also possible to define the order of the content, which is displayed in same UI, to order it with the other parameters. The default value is -1 and means no preset order.

  • Support for the conversion of new collection types: To make it much easier to use the properties converter API which takes a default value, support for the types of the following very common objects has been added:

    • List.of()
    • List.of(1)
    • List.of(1, 2, 3)
    • Arrays.asList()
    • Collections.emptyList()
    • Collections.unmodifiableList(Collections.emptyList())
    • Set.of()
    • Set.of(1)
    • Set.of(1, 2, 3)
    • Collections.emptySet()
    • Collections.unmodifiableSet
  • New ordering property: A new bean property has been added allowing to specify the order of a parameter. This is currently used for defined the order to display the macro parameters in the macro configuration UI. The order is defined such as the lower the value the higher the priority, with a default value defined to -1, meaning no order set.

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: 

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.5.0

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 decided 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.

REST wiki and space keyword search API uses Solr by default

We've changed the backend that is used for keyword search in the REST API at the wiki and space level from the database to Solr as the database search just doesn't scale – we saw running times above a minute in installations with a million documents. While the general feature of the API is the same, finding pages from potentially partial user input, the specific behavior including the default sort order of the results is different. In case you want to restore the previous behavior, you can change the backend in the configuration of the REST API.

Inplace editable macro parameters are visible in the macro configuration UI

Following the revamping of the macro configuration UI, the inplace editable macro parameters are now by default always displayed in the configuration UI, while they used to only be displayed in the configuration UI when not editable in the editor (e.g. the optional title of an optional box was displayed in the macro configuration UI before being first set only, after it was only editable through the editor itself). However, it's possible to revert to the old behaviour if needed by using the following configuration in the Administration > WYSIWYG Editor: config['xwiki-macro'].showInlineEditableParameters=false.

API Breakages

The following APIs were modified since XWiki 17.4.1:

Real breakages

Real backward compatibility breakages that we have unwillingly accepted to do for the reasons mentioned in each violation below.

  • Long voted removal for a plugin which hasn't been used in a very long time
    • Violation type:
      java.class.removed
    • Code:
      ## Old:
      class com.xpn.xwiki.plugin.mail.MailPlugin
  • Long voted removal for a plugin which hasn't been used in a very long time
    • Violation type:
      java.class.removed
    • Code:
      ## Old:
      class com.xpn.xwiki.plugin.mail.MailPluginApi

Credits

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

  • anonymous 
  • jasongwq 
  • Leif Erik Andersen 
  • LucasC 
  • Manuel Leduc 
  • Marius Dumitru Florea 
  • Mend Renovate 
  • Michael Hamann 
  • Simon Urli 
  • Simpel 
  • Thomas Mortagne 
  • Vincent Massol 
  • Xiaofei Cui 
  • xrichard

Get Connected