Release Notes for XWiki 12.5-rc-1

Version 3.1 by Vincent Massol on 2020/06/11

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.

<insert description of release here>

New and Noteworthy (since XWiki <version - 1>)

Full list of issues fixed and Dashboard for <full version here even for RC, e.g. 10.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:


#-# [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

Moved Modules

<description deprecated, retired and moved projects>

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: 

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 <version>

<issues specific to the project>

API Breakages

The following APIs were modified since <project> <version - 1>:

Credits

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

<code contributors>

Tags:
   

Get Connected