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.

Among other things, this release introduces the ability to mention a user, who will receive a notification each time she is mentionned in the content of a page, an object, or a comment. The in-place editing now offers the ability to display and edit the source (in the current syntax) of the page, and it is now possible to display the context of a modification in the "rendered diff" viewer.

On the performances side, a new asynchronous event store (mainly used for notifications) has been created, but is still not enabled by default. Also, renaming a page is now an "atomic" operation, meaning that some bugs we had while trying to rename a page which had a huge history are now fixed.

Some new tools have been added for developers and, as usual, many bugs have been fixed during this month.

New and Noteworthy (since XWiki 12.4)

Full list of issues fixed and Dashboard for 12.5.

For Users

Support of Mentions

 
XWiki Standard now support by default User Mentions. You can mention a user by two ways: either by typing "@" in the WYSIWYG editor as displayed in the screenshot, or by inserting a Mention macro. Mentioning a user will have for effect to send a notification to that user, with the link to the page or place (can be a comment or an object) mentioning her/him.

Switch to source while editing in-place

 
You can now switch to source while editing in-place the content of a page.

Toggle Rendered Diff Context

 
You can now use the "Show context" toggle button to show / hide all the unmodified parts of the page rendered content when comparing two versions of a wiki page from its history. Check the user guide for more information.

User Avatar macro with user picker

 
When inserting the User Avatar macro from the WYSIWYG editor you can now select the target user with a user picker.

For Admins

• New experimental event store: The storage of the events is now asynchronous, they used to slow down every stored event before (document modification, blog post, etc.) since each of them was producing a blocking database insert query.

  This version introduce the complete support of the new event store in the UI notifications (mail notification support is planned for 12.6). Pre filtering is not new and was introduced in 12.1 but it's part of a new architecture to manage user notifications.

  The main differences with the current default behavior are:

  • events are associated with users right when they happen and the association is stored, this means changing your notification configuration won't have any impact on already stored user notifications
  • gathering of notifications associated with users is very fast because it's a simple request to get the list of already calculated associations
  • it will be possible to introduce much more advanced event filters since they won't be required to be translated into database queries anymore

  The new event store and the pre filtering are disabled by default. You can enable both of these options in xwiki.properties configuration file using the following:

  notifications.eventPreFilteringEnabled = true
  eventstream.store.enabled=true

  This won't disable the old event store which will be used as a fallback when something is not supported yet by the new store especially regarding the support of notification post filters which is not yet fully complete.

• Reliable page renames: A new low-level API have been introduced in the XWikiStoreInterface that allows performing an atomic rename of documents: this should improve efficiency of refactoring operations and allows better rollback in case of problems. However since it's a new unstable API concerning a sensitive feature we provided a switch-off configuration for it in xwiki.properties in case of trouble: 

  #-# [Since 12.5RC1]
  #-# Indicate to use the old implementation based on copy and delete, or the new implementation
  #-# using an atomic operation on database (which allows efficient rollback).
  #-# This property aims at being removed in the future once the atomic rename has been validated
  #-# to work 100% fine. Only use it if you are facing an issue with the move/rename features.
  #-#
  #-# The default value is:
  # refactoring.rename.useAtomicRename = true

• Allow IndexerJob to be triggered wiki per wiki on farms: Until now when the configuration solr.synchronizeAtStartup was set to true, the indexer job was trigger for the whole farm of wiki, which could have been resource consuming for the machine. We added a new configuration for the Solr Search API that allows to trigger the index job only when sub-wikis are starting (default behaviour now) or for the whole farm as it was done before. You can find the following configuration in xwiki.properties.

  #-# [Since 12.5RC1]
  #-# Indicates which wiki synchronization to perform when the "solr.synchronizeAtStartup" property is set to true.
  #-# Two modes are available:
  #-#   - WIKI: indicate that the synchronization is performed when each wiki is accessed for the first time.
  #-#   - FARM: indicate that the synchronization is performed once for the full farm when XWiki is started.
  #-# For large farms and in order to spread the machine's indexing load, the WIKI value is recommended, especially if
  #-# some wikis are not used.
  #-# The default is:
  # solr.synchronizeAtStartupMode=FARM

  This option default value changed between 12.5RC1 and 12.5. The default value was WIKI in 12.5RC1 and is now FARM since 12.5

For Developers

Allow to define the pool size of a GroupedJob

 
It is now possible to configure the pool of threads to be used for grouped jobs. To provide that configuration you need to declare a new component that implements org.xwiki.job.GroupedJobInitializer and whose method getId matches the JobGroupPath of the GroupedJob. You will be able to define the size of the pool of threads to be used for those jobs and the default priority of the threads. 

Note that the hierarchy of the JobGroupPath can be used to define the same configuration for a whole hierarchy of GroupedJobs.

New global configurations have been also added in xwiki.properties related to this feature:

Upgrades

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

• CSS4J 2.0.3
• Jetty 9.4.29.v20200521
• HtmlCleaner 2.24
• CKEditor Integration 1.47
• log4j API 2.13.3
• Woodstox 6.2.1
• Stax2 API 4.2.1
• Protobuf Java 3.12.2
• JNR POSIX 3.0.57
• JNR FFI 2.1.15
• JGroups 4.2.4
• Hibernate 5.4.17
• Groovy 2.5.12
• Error Prone annotations 2.4.0
• Commons IO 2.7
• Caffeine 2.8.4
• Batik 1.13

Translations

The following translations have been updated: 

• German
• Spanish
• 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:
	Google Chrome 83	Not Tested
	Mozilla Firefox 77	Not Tested
	Microsoft Edge 83	Not Tested
	Internet Explorer 11	Jira Tickets Marked as Fixed in the Release Notes
	Safari 13	Not Tested

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

	Database	Tested on:
	HyperSQL 2.5.0	Not Tested
	MySQL 8	Jira Tickets Marked as Fixed in the Release Notes
	Oracle 19c	Not Tested
	PostgreSQL 12	Not Tested
	MariaDB 10.4	Not Tested

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.36	Jira Tickets Marked as Fixed in the Release Notes
	Jetty 9.4.29 (XWiki Standalone packaging)	Not Tested
	Jetty 9.4.29	Not Tested

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.

API Breakages

The following APIs were modified since XWiki 12.4:

• NamespaceURLClassLoader no longer inherits from URIClassLoader since this one is now deprecated.
  • Violation type:
    java.class.noLongerInheritsFromClass
  • Code:
    ## Old:
    class org.xwiki.classloader.NamespaceURLClassLoader
    
    ## New:
    class org.xwiki.classloader.NamespaceURLClassLoader
• Not a binary breakage (no API breakage), only source level.
  • Violation type:
    java\.generics\.elementNowParameterized
  • Code:
    ## Old:
    .*org\.xwiki\.component\.annotation\.ComponentDescriptorFactory::createComponentDescriptors.*
    
    ## New:
    .*org\.xwiki\.component\.annotation\.ComponentDescriptorFactory::createComponentDescriptors.*
• Not a breakage for using the User Avatar macro.
  • Violation type:
    java.annotation.added
  • Code:
    ## Old:
    method void org.xwiki.rendering.macro.useravatar.UserAvatarMacroParameters::setUsername(java.lang.String)
    
    ## New:
    method void org.xwiki.rendering.macro.useravatar.UserAvatarMacroParameters::setUsername(java.lang.String)
• Not a breakage. Old deprecated method that has been moved to legacy.
  • Violation type:
    java.method.removed
  • Code:
    ## Old:
    method void com.xpn.xwiki.doc.XWikiDocument::rename(java.lang.String, java.util.List<java.lang.String>, com.xpn.xwiki.XWikiContext) throws com.xpn.xwiki.XWikiException
• Not a breakage. Old deprecated method that has been moved to legacy.
  • Violation type:
    java.method.removed
  • Code:
    ## Old:
    method void com.xpn.xwiki.doc.XWikiDocument::rename(java.lang.String, java.util.List<java.lang.String>, java.util.List<java.lang.String>, com.xpn.xwiki.XWikiContext) throws com.xpn.xwiki.XWikiException
• Not a breakage. Old deprecated method that has been moved to legacy.
  • Violation type:
    java.method.removed
  • Code:
    ## Old:
    method void com.xpn.xwiki.doc.XWikiDocument::rename(java.lang.String, com.xpn.xwiki.XWikiContext) throws com.xpn.xwiki.XWikiException
• Young API
  • Violation type:
    java.method.addedToInterface
  • Code:
    ## Old:
    
    
    ## New:
    method void org.xwiki.search.solr.SolrUtils::setAtomic(java.lang.String, java.lang.String, java.lang.Object, org.apache.solr.common.SolrInputDocument)
• Not a breakage. Added a new property to the Page REST resource.
  • Violation type:
    java.annotation.attributeValueChanged
  • Code:
    ## Old:
    class org.xwiki.rest.model.jaxb.PageSummary
    
    ## New:
    class org.xwiki.rest.model.jaxb.PageSummary
• TargetableNotificationPreferenceBuilder is meant to be a builder but the API wasn't following the builder pattern. This change is not breaking for using that component, but it is breaking if you implemented the TargetableNotificationPreferenceBuilder interface.
  • Violation type:
    java.method.returnTypeChanged
  • Code:
    ## Old:
    method void org.xwiki.notifications.preferences.TargetableNotificationPreferenceBuilder::.+(.+)
    
    ## New:
    method org.xwiki.notifications.preferences.TargetableNotificationPreferenceBuilder org.xwiki.notifications.preferences.TargetableNotificationPreferenceBuilder::.+(.+)

Credits

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

• Carr0ter
• Clemens Robbenhaar
• DenisF
• Francisco García Moreno
• Guillaume Delhumeau
• Hassan Ali
• Marius Dumitru Florea
• Markus Gerhold
• Simon Urli
• Thomas Mortagne
• Vincent Massol
• xrichard