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.

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.

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.

For Admins

No changes!

Miscellaneous

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

  • 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

  • Add atomic store API for document 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

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:


#-# [Since 12.5RC1]
#-# The maximum number of entries to put in cache for the GroupedJobInitializer components.
#-# The default is 100.
# job.groupedJobInitializerCacheSize=100

#-# [Since 12.5RC1]
#-# The thread keep-alive time in milliseconds for the single job executor.
#-# This value defines how long a thread can be idle before being terminated by the executor.
#-# The default value is 60000 for 60 000ms.
# job.singleJobThreadKeepAliveTime=60000

#-# [Since 12.5RC1]
#-# The thread keep-alive time in milliseconds for the grouped job executors.
#-# This value defines how long a thread can be idle before being terminated by an executor.
#-# The default value is 60000 for 60 000ms.
# job.groupedJobThreadKeepAliveTime=60000

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: 

  • German
  • Spanish
  • Simplified Chinese

Tested Browsers & Databases

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

 BrowserTested on:
Chrome30.pngGoogle Chrome 83Not Tested
Firefox30.pngMozilla Firefox 77Not Tested
Edge30.pngMicrosoft Edge 83Not Tested
IE30.pngInternet Explorer 11Jira Tickets Marked as Fixed in the Release Notes
Safari30.pngSafari 13Not Tested

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

 DatabaseTested on:
hypersql.pngHyperSQL 2.5.0Not Tested
mysql.pngMySQL 8Jira Tickets Marked as Fixed in the Release Notes
oracle.pngOracle 19cNot Tested
postgresql.pngPostgreSQL 12Not Tested
mariadb.pngMariaDB 10.4Not Tested

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

 Servlet ContainerTested on:
tomcat-icon.pngTomcat 9.0.36Jira Tickets Marked as Fixed in the Release Notes
jetty-icon.pngJetty 9.4.29 (XWiki Standalone packaging)Not Tested
jetty-icon.pngJetty 9.4.29Not Tested

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.

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
Tags:
Created by Vincent Massol on 2020/06/08
   

Get Connected