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.

The realtime WYSIWYG editing feature has been added to XWiki (but turned off by default as it's still considered experimental). In addition, this release brings performance improvements when pages have lots of revisions. In term of important infrastructure changes, XWiki has moved from Restlet to Jersey for its REST API and from Solr 8 to Solr 9 (a migration has been included). XWiki is progressing on its path for being WCAG 2.1 AA compliant and several improvements have been made. And bug fixes as usual.

New and Noteworthy (since XWiki 16.1.0)

Full list of issues fixed and Dashboard for 16.2.0.

For Users

Realtime Inplace Editing

 
The In-place WYSIWYG edit mode now supports real-time collaboration. This feature is experimental so it is disabled by default. If you want to try it out just ask your administrator to enable the "xwiki-realtime" CKEditor plugin from the CKEditor administration section.

Realtime WYSIWYG Editing Bundled by Default

 
The realtime WYSIWYG editor is now bundled by default in XWiki Standard. It's still an experimental feature, so you have to enable it if you want to try it out. We refactored the code to make it a CKEditor plugin rather than a separate editor (based on CKEditor) so in order to enable realtime collaboration for the WYSIWYG editor you have to remove (uncheck) the "xwiki-realtime" from the list of disabled plugins in the CKEditor administration section. Make sure you read the list of known limitations before you try it out.

Realtime Editing of Rendering Macros

 
The realtime WYSIWYG editor has changed the way it handles rendering macros. Previously, the macro output was propagated from the user that inserted or last modified the macro parameters to the other participants in the realtime session. This was working fine for static macros, that don't rely on custom CSS and JavaScript, but it was creating problems for dynamic macros (e.g. live data). Starting with this version, the macro output is not synchronized anymore between the users. When a user inserts a macro or modifies the parameters of an existing macro call, the other users will get their content re-rendered server side in order to get the updated macro output (which often depends on the current user, e.g. on their access rights). See the realtime WYSIWYG editor documentation for more information.

Miscellaneous

• The administration menu now has carets next to section names to highlight the fact that sections can be expanded to view subsections.

• Performance improvements for history display: Displaying the history and switching pages for a document that has a large number of revisions should be noticeably faster and use less memory.

For Admins

• The administration rights interface now uses buttons with up to date icons instead of skeuomorphic images.

For Developers

JAX-RS 2.1 support

 
XWiki now supports JAX-RS 2.1. The implementation relies on Jersey 2, which replaces Restlet that was used for JAX-RS 1.

See the Backward Compatibility section for the related breaking changes.

Live Data async actions

 
It is now possible to allow a Live Data actions to be asynchronous. Instead of following the link, the action will be performed in the background, and the Live Data refreshed at the end of the process.
Additionally, it is possible to define a user confirmation before performing the action.

Example:

Script Safe Provider

 
The old ScriptSafeProvider tool has been move to a public package. It's making much easier to make a script API safe by wrapping what it returns to make sure:

• it really only can use the method exposed in the returned API
• there is some protection added to the methods called in the returned objects
• it's easy to make collection of those objects safe

See Script Module for more details.

Versioning Store API improvements

 
The Versioning Store interface now exposes two new methods designed to directly fetch subsets of revisions:

If you maintain a custom implementation of a Versioning Store, there should be no breaking change since these methods have default implementations. However, you are still encouraged to implement them to improve performances.

Consequently, the Document API now offers a method to directly obtain the number of existing revisions, fetching the information directly from the Versioning Store without actually loading the revisions:

Operations that required to load the complete history of a document before filtering the revisions (e.g., displaying a paginated document history) have been modified to benefit from these changes, they should now be faster and use less memory.

Miscellaneous

• Live Data properties annotation: Live Data displayers have a new data-livedata-property-id property, containing the ID of the displayed property. This is useful to select the DOM element corresponding to a given property without relying on the structure of a given layout.

Upgrades

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

• dompurify 3.0.9
• Jetty 10.0.20
• AspectJ 1.9.21.2
• commons-compress 1.26.0
• MariaDB connector 3.3.3
• PostgresSQL connector 42.7.2
• Docker Java 3.3.6
• Commons Codec 1.16.1
• Wiremock 3.4.2
• Log4J API 2.23.0
• Exec Maven Plugin 3.2.0
• JGroups 5.3.4
• Error Prone annotations 2.25.0
• SLF4J 2.0.12
• Woodstox 6.6.1
• MChange Commons 0.3.0
• Netty 4.1.107.Final
• Download Plugin for Maven 1.8.1
• JFFI 1.3.13
• JNR FFI 2.2.16
• JNR POSIX 3.1.19
• Protobuf Java 3.25.3
• commons-compress 1.26.1
• Zookeeper 3.9.2
• Solr 9.4.1 and Lucene 9.8.0
• Maven XML 4.0.0-alpha-13
• Log4J API 2.23.1
• Liquibase 4.26.0
• Jetty Client 10.0.19
• Jackson 2.17.0
• JSONP 2.1.3 and Parsson 1.1.5
• JAX-RS 2.1.6 (JSR370)
• Groovy 4.0.19
• Error Prone annotations 2.26.1
• Elastic search client 8.12.2
• Commons DBCP2 2.12.0
• Commons Configuration 2.10.0
• Commons Configuration 2.10.1
• Antlr 4.13.1

Translations

The following translations have been updated: 

• German
• Simplified Chinese

Tested Browsers & Databases

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

	Browser	Tested on:
	Mozilla Firefox 124	Jira Tickets Marked as Fixed in the Release Notes Tests run and results
	Google Chrome 123	Tests run and results
	Microsoft Edge 123	Not Tested
	Safari 17	Not Tested

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

	Database	Tested on:
	HyperSQL 2.7.2	Not Tested
	MariaDB 11.3	Jira Tickets Marked as Fixed in the Release Notes
	MySQL 8.3	Tests run and results
	PostgreSQL 16	Not Tested
	Oracle 19c	Tests run and results

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

	Servlet Container	Tested on:
	Tomcat 9.0.87	Jira Tickets Marked as Fixed in the Release Notes Tests run and results
	Jetty 10.0.20 (XWiki Standalone packaging)
	Jetty 10.0.20	Not 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.

Accessibility Improvements

Since 16.1.0, three accessibility bugs have been fixed. Those fixes improve the semantics in the WYSIWYG, search suggest and Notifications sections of the administration UI.

Since october 2023, we cleared out three more automated accessibility rules from our tests. We now fail the build on 54 of the 61 possible rules. Our goal is to fail the build on every rule violation. Out of the seven rules we still only trigger warnings in our build for, only two of them have more than two places where they are violated. More details about the state of integration of accessibility tests in our CI.

Known issues

• Bugs we know about

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 16.2.0

Move to Jersey

The XWiki REST API used to depend on Restlet, and has now been moved to Jersey 2.

We took great care to keep the same behavior as much as possible, but there are some differences:

• If you were using directly any Restlet class (which was something not recommended), your code won't work anymore.
• There were some bugs in the Restlet implementation of the URIBuilder class. They are fixed in Jersey. One that was existing when Restlet was used was that Restlet was not escaping / characters contained in parameters passed to the URIBuilder class. So, if your code was depending on this behavior, you are going to have problems, and you'll need to split the parameters into several Strings instead (this should work fine with Restlet too if you want to fix the issue while staying on XWiki < 16.2.0).
• Restlet added a lot of custom behaviors on top of JAX-RS and HTTP specifications, especially regarding the special meaning of some URL parameters. We only kept what was documented in the XWiki REST API (the media parameter, which allows overwriting the HTTP request Accept value, and the method parameter, which allows to overwrite the HTTP request method, both of which are only here for retro-compatibility reasons, and we highly recommend to use standard HTTP instead).

Upgrade to Antlr 4.10+

Antlr introduced a breaking change in version 4.10, which makes it impossible to run code built with a version of Antlr 4 lower than 4.10.

Upgrade to Solr 9

XWiki now expects Solr 9 to be installed. There is nothing special to do if you use the embedded Solr server (the default, which has been moved to Solr 9) but if you have a standalone Solr server, you need Solr 9 (using Solr 8 with XWiki 16.2.0+ has not been tested and is not supported). There is an automatic migration of the data from Lucene 8 to 9 format but for this you need to setup new cores as explained in the remote Solr server instructions.

Realtime WYSIWYG Editor

If you have previously installed the Realtime WYSIWYG Editor extension and enabled realtime collaboration by default by changing the "Default WYSIWYG Editor" setting from the "Editing / WYSIWYG Editor" administration section, then you need to revert this change and instead remove "xwiki-realtime" from the list of disabled CKEditor plugins from the same administration section.

If you haven't enabled realtime editing before but you have a custom list of disabled CKEditor plugins, then you need to add "xwiki-realtime" to that list, otherwise realtime editing will be enabled by default after you upgrade.

org.xwiki.script.internal.safe.ScriptSafeProvider class missing

You might see this error logged during the upgrade of XWiki:

This is actually expected logs for the upgrade (the old flavor depends on an internal class which does not exist anymore), they shouldn't appear anymore once the flavor is properly upgraded through the distribution wizard.

API Breakages

The following APIs were modified since XWiki 16.1.0:

Real breakages

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

• WrappingIterableResult was not really usable because it forced to also use internal APIs by mistake.
  • Violation type:
    java.field.removedWithConstant
  • Code:
    ## Old:
    field org.xwiki.script.internal.safe.AbstractSafeObject<T>.FORBIDDEN @ org.xwiki.extension.wrap.WrappingIterableResult<E extends org.xwiki.extension.Extension>
• WrappingIterableResult was not really usable because it forced to also use internal APIs by mistake.
  • Violation type:
    java.field.removed
  • Code:
    ## Old:
    field org.xwiki.script.internal.safe.AbstractSafeObject<T>.safeProvider @ org.xwiki.extension.wrap.WrappingIterableResult<E extends org.xwiki.extension.Extension>
• WrappingIterableResult was not really usable because it forced to also use internal APIs by mistake.
  • Violation type:
    java.method.numberOfParametersChanged
  • Code:
    ## Old:
    method void org.xwiki.extension.wrap.WrappingIterableResult<E extends org.xwiki.extension.Extension>::<init>(org.xwiki.extension.repository.result.IterableResult<E>, org.xwiki.script.internal.safe.ScriptSafeProvider<?>)
    
    ## New:
    method void org.xwiki.extension.wrap.WrappingIterableResult<E extends org.xwiki.extension.Extension>::<init>(org.xwiki.extension.repository.result.IterableResult<E>)
• WrappingIterableResult was not really usable because it forced to also use internal APIs by mistake.
  • Violation type:
    java.method.removed
  • Code:
    ## Old:
    method <S> S org.xwiki.script.internal.safe.AbstractSafeObject<T>::safe(java.lang.Object) @ org.xwiki.extension.wrap.WrappingIterableResult<E extends org.xwiki.extension.Extension>
• WrappingIterableResult was not really usable because it forced to also use internal APIs by mistake.
  • Violation type:
    java.class.noLongerInheritsFromClass
  • Code:
    ## Old:
    class org.xwiki.extension.wrap.WrappingIterableResult<E extends org.xwiki.extension.Extension>
    
    ## New:
    class org.xwiki.extension.wrap.WrappingIterableResult<E extends org.xwiki.extension.Extension>
• Was never meant to be an API.
  • Violation type:
    java.field.removed
  • Code:
    ## Old:
    field org.xwiki.search.solr.AbstractSolrCoreInitializer.fields
• Was never meant to be an API.
  • Violation type:
    java.field.removed
  • Code:
    ## Old:
    field org.xwiki.search.solr.AbstractSolrCoreInitializer.types
• Was never meant to be an API.
  • Violation type:
    java.field.visibilityReduced
  • Code:
    ## Old:
    field org.xwiki.search.solr.AbstractSolrCoreInitializer.solrSchemaUtils
    
    ## New:
    field org.xwiki.search.solr.AbstractSolrCoreInitializer.solrSchemaUtils
• Should have never been public in the first place and is deprecated since 9.8RC1.
  • Violation type:
    java.class.removed
  • Code:
    ## Old:
    class org.xwiki.rest.Constants
• Not runtime breakages from REST API point of view and not supposed to be called in Java
  • Violation type:
    java.method.numberOfParametersChanged
  • Code:
    ## Old:
    method javax.ws.rs.core.Response org.xwiki.notifications.rest.NotificationsResource::postNotifications() throws java.lang.Exception
    
    ## New:
    method javax.ws.rs.core.Response org.xwiki.notifications.rest.NotificationsResource::postNotifications(java.lang.String, java.lang.String, java.lang.String, boolean, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String) throws java.lang.Exception
• Not runtime breakages from REST API point of view and not supposed to be called in Java
  • Violation type:
    java.method.returnTypeChanged
  • Code:
    ## Old:
    method java.util.Map<java.lang.String, java.lang.String> org.xwiki.image.style.rest.ImageStylesResource::getDefaultStyleIdentifier(java.lang.String, java.lang.String) throws org.xwiki.image.style.ImageStyleException
    
    ## New:
    method javax.ws.rs.core.Response org.xwiki.image.style.rest.ImageStylesResource::getDefaultStyleIdentifier(java.lang.String, java.lang.String) throws org.xwiki.image.style.ImageStyleException
• Not runtime breakages from REST API point of view and not supposed to be called in Java
  • Violation type:
    java.annotation.added
  • Code:
    ## Old:
    parameter javax.ws.rs.core.Response org.xwiki.rest.resources.attachments.AttachmentsResource::addAttachment(java.lang.String, java.lang.String, java.lang.String, ===javax.mail.Multipart===, java.lang.Boolean, java.lang.Boolean) throws org.xwiki.rest.XWikiRestException, org.xwiki.attachment.validation.AttachmentValidationException
    
    ## New:
    parameter javax.ws.rs.core.Response org.xwiki.rest.resources.attachments.AttachmentsResource::addAttachment(java.lang.String, java.lang.String, java.lang.String, ===java.lang.Boolean===, java.lang.Boolean) throws org.xwiki.rest.XWikiRestException, org.xwiki.attachment.validation.AttachmentValidationException
• Not runtime breakages from REST API point of view and not supposed to be called in Java
  • Violation type:
    java.annotation.added
  • Code:
    ## Old:
    parameter javax.ws.rs.core.Response org.xwiki.rest.resources.attachments.AttachmentsResource::addAttachment(java.lang.String, java.lang.String, java.lang.String, ===javax.mail.Multipart===, java.lang.Boolean, java.lang.Boolean) throws org.xwiki.rest.XWikiRestException, org.xwiki.attachment.validation.AttachmentValidationException
    
    ## New:
    parameter javax.ws.rs.core.Response org.xwiki.rest.resources.attachments.AttachmentsResource::addAttachment(java.lang.String, java.lang.String, java.lang.String, ===java.lang.Boolean===, java.lang.Boolean) throws org.xwiki.rest.XWikiRestException, org.xwiki.attachment.validation.AttachmentValidationException
• Not runtime breakages from REST API point of view and not supposed to be called in Java
  • Violation type:
    java.annotation.attributeValueChanged
  • Code:
    ## Old:
    parameter javax.ws.rs.core.Response org.xwiki.rest.resources.attachments.AttachmentsResource::addAttachment(java.lang.String, java.lang.String, java.lang.String, javax.mail.Multipart, ===java.lang.Boolean===, java.lang.Boolean) throws org.xwiki.rest.XWikiRestException, org.xwiki.attachment.validation.AttachmentValidationException
    
    ## New:
    parameter javax.ws.rs.core.Response org.xwiki.rest.resources.attachments.AttachmentsResource::addAttachment(java.lang.String, java.lang.String, java.lang.String, java.lang.Boolean, ===java.lang.Boolean===) throws org.xwiki.rest.XWikiRestException, org.xwiki.attachment.validation.AttachmentValidationException
• Not runtime breakages from REST API point of view and not supposed to be called in Java
  • Violation type:
    java.method.numberOfParametersChanged
  • Code:
    ## Old:
    method javax.ws.rs.core.Response org.xwiki.rest.resources.attachments.AttachmentsResource::addAttachment(java.lang.String, java.lang.String, java.lang.String, javax.mail.Multipart, java.lang.Boolean, java.lang.Boolean) throws org.xwiki.rest.XWikiRestException, org.xwiki.attachment.validation.AttachmentValidationException
    
    ## New:
    method javax.ws.rs.core.Response org.xwiki.rest.resources.attachments.AttachmentsResource::addAttachment(java.lang.String, java.lang.String, java.lang.String, java.lang.Boolean, java.lang.Boolean) throws org.xwiki.rest.XWikiRestException, org.xwiki.attachment.validation.AttachmentValidationException
• Very specific to Restlet and not supposed to be called in Java
  • Violation type:
    java.method.removed
  • Code:
    ## Old:
    method java.lang.String org.xwiki.rest.XWikiResource::getUriTemplate()
• Was actually internal classes exposed through public APIs
  • Violation type:
    java.class.removed
  • Code:
    ## Old:
    class org.xwiki.captcha.script.CaptchaScriptSafeProvider
• Was actually internal classes exposed through public APIs
  • Violation type:
    java.class.removed
  • Code:
    ## Old:
    class org.xwiki.captcha.script.WrappedScriptCaptcha
• Was actually internal classes exposed through public APIs
  • Violation type:
    java.field.typeChanged
  • Code:
    ## Old:
    field org.xwiki.extension.script.AbstractExtensionScriptService.scriptProvider.*
    
    ## New:
    field org.xwiki.extension.script.AbstractExtensionScriptService.scriptProvider.*
• Was actually internal classes exposed through public APIs
  • Violation type:
    java.field.typeChanged
  • Code:
    ## Old:
    field org.xwiki.filter.script.AbstractFilterScriptService.scriptProvider.*
    
    ## New:
    field org.xwiki.filter.script.AbstractFilterScriptService.scriptProvider.*

Credits

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

• Antoine Mottier
• Clemens Robbenhaar
• Clément Aubin
• Lucas C
• Manish Krishna Kandrakota
• Manuel Leduc
• Marius Dumitru Florea
• Mend Renovate
• Michael Hamann
• Oana-Lavinia Florean
• Pierre Jeanjean
• Simon Urli
• Thomas Mortagne
• Vincent Massol
• listeng