Release Notes for XWiki 11.8

Last modified by Simon Urli on 2019/11/04

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 more mature version of the edit conflict resolution UI, display of disabled users in the User Directory, more consistent UI by using Icon Themes in the Live Table and more streamlined template provider creation. Admins also benefit from the improvements added to the conflict resolution UI, but at the Extension Manager level, and get more help for making the right choices when wanting to delete a user (to avoid the mess of broken page rights). Developers now have multiple options for asynchronous rendering of various elements and more control over the rendering of templates.

Some important bugs have been found since XWiki 11.8 has been released:

New and Noteworthy (since XWiki 11.7)

Full list of issues fixed and Dashboard for 11.8.

For Users

Independent Conflict Resolution

 
We introduced few releases ago a mechanism to detect and handle conflict edition (i.e. when two users save changes on the same page) during page edition.
Starting with this release, the conflict edition window allows one more choice: to fix each conflict individually.
This new choice is marked as advanced since it's not something easy to handle.

When choosing the new option, the UI is updated to display the changes between the latest version saved and the current version the user is trying to save. At each place a conflict occurred, the changes display an orange bar and a blue area is reserved for the conflict resolution.
This blue area displays some text, and a select with several choices. The displayed text in the blue area is what will be used for fixing the conflict, you can see the text changing for each choice.

The conflict choices are the following:

  • current version (default): the conflict is fixed by getting the current changes
  • before your changes: the conflict is fixed by getting what was there before you starting to edit. Both latest version saved and your current changes would be lost for this conflict,
  • latest version saved: the change made on the latest version saved (the one you are conflicting with) are taken to fix the conflict
  • custom version: with this option, a text area is displayed to allow you to enter any new value to fix the conflict. Multiple lines can be entered.

If the choice text displays something in red, it is because no content is actually available for the chosen version to fix the conflict: usually it means the content in conflict will be removed with the choice made.

Live Table Actions use the Icon Theme

 
The default Actions column from the Live Table is now using the configured Icon Theme for the action icons. See the Live Table macro documentation for more information.

User Directory Configuration Live Preview

 
The User Directory configuration has a new setting to show/hide disabled users. Disabled users are hidden by default. The users live table is now updated automatically when the configuration is modified.

Create Template Provider from the Class UI

 
Until now, the place to create a template provider was Administration->Content->Page Templates and most of the time the need was to work together with a template created for a class. It is possible now to create the template provider from the class UI, just as the sheet and template are created. The only condition is to first create the template, in order to use it (otherwise it doesn't make sense to have a template provider for the class).

For Admins

Custom conflict resolution in Extension Manager

 
We improved the Extension Manager conflict resolution to allow making specific choices for fixing some conflicts.

The conflicts that can be fixed with custom choices are displayed directly in the changes display by an orange bar. A blue area is reserved for the conflict resolution.
This blue area displays some text, and a select with several choices. The displayed text in the blue area is what will be used for fixing the conflict, you can see the text changing for each choice.

The conflict choices are the following:

  • current version (default): the conflict is fixed by getting the current changes
  • before your changes: the conflict is fixed by getting what was there before you starting to edit. Both latest version saved and your current changes would be lost for this conflict,
  • latest version saved: the change made on the latest version saved (the one you are conflicting with) are taken to fix the conflict
  • custom version: with this option, a text area is displayed to allow you to enter any new value to fix the conflict. Multiple lines can be entered.

If the choice text displays something in red, it is because no content is actually available for the chosen version to fix the conflict: usually it means the content in conflict will be removed with the choice made.

Replace Author when Deleting Users

 
Starting with this version deleting a user from the Administration requires 2 steps:

  • You have to disable the user first. Disabling the user prevents them from logging in and it doesn't break the scripts that they last modified. This is the recommended way to "remove" an user account from your organization.
  • If you really need to completely remove the user account then you can delete it. However, you should choose another user account with similar access rights to replace the delete one as page author of existing pages, otherwise, any scripts inside those existing pages will lose their rights and stop working.

Miscellaneous

  • Mail Configuration inherited from main wiki: The Mail Configuration for a subwiki is now inheriting from the configuration from the main wiki. More precisely if the local Mail.MailConfig is empty for the looked up configuration property, it's looked for in the same page in the main wiki, and if not found then it defaults to the value from xwiki.properties.

For Developers

Asynchronous rendering improvements

 

  • Asynchronous support has been added to page content execution (include macro, display macro, view, #getRenderedContent, etc.)
  • Asynchronous support has been added to templates, see Template Module
  • Calls to hasAccess and checkAccess are automatically associated to cached elements and invalidated if the right change
  • Force refresh in the browser now also apply to asynchronous rendering cache located on server side
  • Support has been added for the following context elements (see Async)
    • RenderingContext target syntax
    • RenderingContext default syntax
    • RenderingContext restricted
  • UI improvements
    • The spinner is displayed only after 500ms so that it does not get in the way when the asynchronous execution is very fast
    • The AJAX request now retry every 500ms instead of blocking a HTTP input thread forever

Templates improvements

 

  • It's now possible to indicate that a template should be executed only once in the same request.
  • It's now possible to enabled asynchronous rendering and caching for a template.

 See Template Module for more details.

Miscellaneous

  • RightUpdatedEvent: A org.xwiki.security.authorization.event.RightUpdatedEvent event is now sent when a modification may have an impact on the result of a right check (modified XWikiRights object, modified group, etc.).

  • Hints for Meta Properties: The class editor is now displaying hints for meta properties when they are available. You can check for instance the Size, Editor and Content Type meta properties of a Text Area object property.

  • Possibility to disable the fullscreen behaviour on textarea: Until now a "maximize" link was automatically added to any textarea added to a page when viewing it in an editor. This can be now disabled by using the CSS class not-maximizable on the textarea. 

  • Remove XWikiUser disabled property and introduce email_checked property: We introduced in XWiki 11.6RC1 a new property on XWikiUsers objects called disabled to allow to disable or enable users. This property was however redundant with the previously existing active property, which was until then only used to check if users validated their email account, when the linked registration option was activated. 

    In this release, we remove the disabled property and rely entirely on the active property to know if a user account is enabled or not. We introduced a new email_checked property to verify if a user validated his/her email address if the option was activated. 

  • Computed field values are now available in REST representations: In the REST API, the REST representation of objects containing computed fields now includes the computed values of these fields while previously, they contained an empty value.

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:

Tested Browsers & Databases

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

 BrowserTests performed and results
Chrome30.pngGoogle Chrome 77Not Tested
Firefox30.pngMozilla Firefox 69Not Tested
Edge30.pngMicrosoft Edge 18New and Noteworthy Features + Jira Tickets Marked as Fixed in the Release Notes
IE30.pngInternet Explorer 11Not Tested
Safari30.pngSafari 13Not Tested

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

 DatabaseTests performed and results
hypersql.pngHyperSQL 2.5.0Not Tested
mysql.pngMySQL 5.7New and Noteworthy Features + Jira Tickets Marked as Fixed in the Release Notes
oracle.pngOracle 12cNot Tested
postgresql.pngPostgreSQL 11Not Tested

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

 Servlet ContainerTests performed and results
tomcat-icon.pngTomcatNot Tested
jetty-icon.pngJetty (XWiki Standalone packaging)New and Noteworthy Features + Jira Tickets Marked as Fixed in the Release Notes
jetty-icon.pngJettyNot Tested

Performances tests compared to 8.4.6

Summary

The skin is back on track compared to 8.4.6 mostly thanks to asynchonous elements (which means it's still slower but it now feels similar). 11.8 contains more documents (70 more) than 8.4.6 which make most tasks in charge of loading all documents take longer, it also contains more wiki components which take slighly more time to save (because they are registered at save time). While the memory is more optimized (explaining the lower memory used before initializing the DB) we simply store more stuff in it (mostly more cached wiki components and also a bit of asynchronous elements).

"similar": difference is lower than 10%
"slightly": difference is lower than 20%

Note that most of the speed related values are an average of very moving results, a lot of things is happening during a HTTP request and it's far from stable duration (that's why 10% may sounds a lot for something called "similar" but the variable can go up and down around 5% sometimes so 10% average is really not that much of a clear win). Dumbbench based tests are executed several times and the lowest result is selected.

Speed

ActionsDifference
Jetty startup+30%
First accessnot existing page without UI+23%
not existing page with UIsimilar
Reloadnot existing page without UIsimilar
not existing page with UIsimilar
empty page without UIslightly slower
empty page with UIsimilar
Main.WebHome without UIx2
Main.WebHome with UIsimilar
SOLRFull SOLR reindex+25%
SOLR sync when index is emptyx2
SOLR sync when there is nothing to do+26%
Result of search finding lots of resultssimilar
Result of search finding one resultsimilar
RenderingPage with 1000 macros without UIsimilar
Page with 1000 html macros without UI/10.6
Wiki creationFrom flavor-24%
From template+40%

Memory

ActionsDifference
Heap Memory after jetty startup-49
Heap Memory after full SOLR index+53

More details on Performance test on Jetty/HSQLDB with a single wiki between 8.4.6 and 11.8.

Known issues

Backward Compatibility and Migration Notes

The migration to XWiki 11.8 can take a very long time for wikis containing a lot of users, more information can be found on the related issue:

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 11.8

  • The disabled property introduced on XWikiUsers objects in XWiki 11.6RC1 has been removed. The existing property active should be use instead. You can read more about this on this specific note.
  • The value returned by PropertyClass#getFieldFullName() for a meta property has changed: the meta property name is prefixed with the property type, e.g. the value returned for the "editor" meta property of a TextArea object property is "TextArea_editor". The value returned by PropertyClass#getFieldFullName() for a class property has not changed.

API Breakages

The following APIs were modified since XWiki 11.7:

  • This API was marked as unstable. Breakage needed because of https://jira.xwiki.org/browse/XCOMMONS-1722.
    • Violation type:
      java.method.numberOfParametersChanged
    • Code:
      ## Old:
      method void org.xwiki.diff.display.UnifiedDiffConflictElement<E>::<init>(org.xwiki.diff.Conflict<E>, int)

      ## New:
      method void org.xwiki.diff.display.UnifiedDiffConflictElement<E>::<init>(org.xwiki.diff.Conflict<E>)
  • This API was marked as unstable. Breakage needed because of https://jira.xwiki.org/browse/XCOMMONS-1722.
    • Violation type:
      java.method.returnTypeChangedCovariantly
    • Code:
      ## Old:
      method E org.xwiki.diff.display.UnifiedDiffConflictElement<E>::getCurrentElement()

      ## New:
      method java.util.List<E> org.xwiki.diff.display.UnifiedDiffConflictElement<E>::getCurrentElement()
  • This API was marked as unstable. Breakage needed because of https://jira.xwiki.org/browse/XCOMMONS-1722.
    • Violation type:
      java.method.returnTypeChangedCovariantly
    • Code:
      ## Old:
      method E org.xwiki.diff.display.UnifiedDiffConflictElement<E>::getNextElement()

      ## New:
      method java.util.List<E> org.xwiki.diff.display.UnifiedDiffConflictElement<E>::getNextElement()
  • This API was marked as unstable. Breakage needed because of https://jira.xwiki.org/browse/XCOMMONS-1722.
    • Violation type:
      java.method.returnTypeChangedCovariantly
    • Code:
      ## Old:
      method E org.xwiki.diff.display.UnifiedDiffConflictElement<E>::getPreviousElement()

      ## New:
      method java.util.List<E> org.xwiki.diff.display.UnifiedDiffConflictElement<E>::getPreviousElement()
  • This API was marked as unstable. Breakage needed because of https://jira.xwiki.org/browse/XCOMMONS-1722.
    • Violation type:
      java.method.removed
    • Code:
      ## Old:
      method void org.xwiki.diff.display.UnifiedDiffElement<E, F>::<init>(int, org.xwiki.diff.display.UnifiedDiffElement.Type, E, org.xwiki.diff.Conflict<E>)
  • This API was marked as unstable. Breakage needed because of https://jira.xwiki.org/browse/XCOMMONS-1722.
    • Violation type:
      java.method.removed
    • Code:
      ## Old:
      method org.xwiki.diff.display.UnifiedDiffConflictElement<E> org.xwiki.diff.display.UnifiedDiffElement<E, F>::getConflict()
  • This API was marked as unstable. Breakage needed because of https://jira.xwiki.org/browse/XCOMMONS-1722.
    • Violation type:
      java.method.removed
    • Code:
      ## Old:
      method boolean org.xwiki.diff.display.UnifiedDiffElement<E, F>::isConflicting()
  • This class was actually not deleted but moved from xwiki-platform-oldcore module to xwiki-platform-store-merge-default module.
    • Violation type:
      java.class.removed
    • Code:
      ## Old:
      class com.xpn.xwiki.doc.merge.CollisionException
  • This class was actually not deleted but moved from xwiki-platform-oldcore module to xwiki-platform-store-merge-default module.
    • Violation type:
      java.class.removed
    • Code:
      ## Old:
      class com.xpn.xwiki.doc.merge.MergeException
  • Use a real serialVersionUID field. Not breaking since we never serialize it.
    • Violation type:
      java.field.serialVersionUIDChanged
    • Code:
      ## Old:
      null

      ## New:
      field com.xpn.xwiki.objects.BaseElement<R extends org.xwiki.model.reference.EntityReference>.serialVersionUID
  • This method was added on XWiki 11.6RC1 and is actually redundant with XWikiUser#isDisabled
    • Violation type:
      java.method.removed
    • Code:
      ## Old:
      method boolean com.xpn.xwiki.user.api.XWikiUser::isActive(com.xpn.xwiki.XWikiContext)
  • This method was added on XWiki 11.6RC1 and is actually redundant with XWikiUser#setDisabled
    • Violation type:
      java.method.removed
    • Code:
      ## Old:
      method void com.xpn.xwiki.user.api.XWikiUser::setActiveStatus(boolean, com.xpn.xwiki.XWikiContext)

Credits

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

Afonso Henrique Oliveira
Alex Cotiugă
Christian Fröhlich
Clemens Robbenhaar
Clément Aubin
DenisF
Eduard Moraru
Jascha Kirchhoff
Joan
liuyf
Marius Dumitru Florea
Oana-Lavinia Florean
Prachi Joshi
Sam Lanning
Simon Urli
slauriere
sugov5
Thomas Mortagne
Vincent Massol
Vyacheslav Sukharnikov
xrichard

Tags:
   

Get Connected