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.

Apart from UI improvements to panels, quick search, macro editing and annotations, this release further improves the experimental BlockNote editor integration and increases the security of user and superadmin passwords. For developers, several new scripting APIs were added. This release contains security fixes, with the highest severity being 9.3/10.

New and Noteworthy (since XWiki 18.7.0)

Full list of issues fixed and Dashboard for 18.8.0.

For Users

Improvements to panel titles and navigation items

News styles for panel titles

Panel titles now have a more compact view by default

Navigation items ease of access

Pages featured in the navigation panel now span 100% of the width of the panel. This should make easier to navigate to pages with short names using the navigation panel

Insert links from the BlockNote slash menu

The BlockNote editor's slash menu now has a "Link" entry: type /link, select it, and the link modal opens so you can enter the display text and target of a new link without selecting text first. See Insert a Link with the BlockNote Editor.

Quick search icons follow the icon theme

The icons displayed next to each group of results in the quick search, and next to each source in the search suggest administration section, now use the icon theme of the wiki instead of the Silk images, so they match the other icons of the interface.

Search suggest sources whose icon is not an icon name prefixed with icon: keep displaying the image they point to.

Redesigned annotation bubble

The annotation bubble has a new layout: a smaller avatar, the author and the date on the same line, and an "x" button to close it.

Annotations stored as comments now show the same "Reply", "Share", "Edit" and "Delete" buttons as the Comments tab, plus a "View thread" button showing the number of replies when there are some. "Share" opens a dialog with the permalink of the annotation, and that dialog now has a button to copy the link to the clipboard. See the Annotation Application for how to view, edit and delete annotations.

Macro name shown when hovering a macro in the WYSIWYG editor

Hovering a macro in the WYSIWYG editor now displays the macro identifier next to its move handle. This makes nested macros, and macros without a visible output, easier to identify.

Miscellaneous

• BlockNote realtime sessions save automatically:

  Content edited with the BlockNote editor in a realtime collaboration session is now saved automatically, about once a minute while there are unsaved changes. This closes the "there is no auto-save" limitation announced when BlockNote realtime collaboration was introduced.

  Only one of the collaborators' browsers performs each save, so the session adds a single version per save instead of one version per participant. That version records the summary "Auto-saved during real-time collaboration", the same summary a CKEditor realtime session uses. Saving by hand keeps working and takes precedence over the automatic save.

  The save status ("Unsaved", "Saving", "Saved") that the realtime toolbar displays is not shown in the BlockNote action bar yet, so there is currently no on-screen indication of when the automatic save happens. We plan to add it in the next version.

• Join a BlockNote realtime session without the lock confirmation:

  When a Page was already being edited with the BlockNote editor, the next user opening that Page for editing was asked to confirm that they want to take over the edit lock, even though both users were about to edit the Page together.

  Now, as long as a BlockNote collaboration session is in progress on the Page, opening that Page with BlockNote joins the session directly, in both the in-place and the standalone edit modes, the same way realtime editing with CKEditor already did. The confirmation is still shown when there is no session to join, and when the Page is opened with another editor.

For Admins

• Hashed superadmin password:

  Enabling the superadmin rescue account no longer means leaving its password in clear text in xwiki.cfg: as described in Enable the Superadmin Account, the xwiki.superadminpassword property now also accepts a hashed value, written as {algorithm}hash with one of the algorithms supported by password properties. A plain text value keeps working, so existing configurations are unaffected.

For Developers

• New script APIs to execute and render UI extensions:

  A common pattern for rendering UI extensions using scripting (Velocity) is:

  #foreach($uix in $services.uix.getExtensions("org.xwiki.platform.html.head", {'sortByParameter' : 'order'}))
    $services.rendering.render($uix.execute(), 'html/5.0')
  #end

  The problem with this is that the specified output syntax, html/5.0, is not taken into account when executing the UI extension. It is used only to control how the result of the execution is rendered. This may seem enough, but when a template-based or wiki-based UI extension produces a raw block, this is labeled with the syntax from the rendering context, which is not necessarily the target syntax specified by the script (e.g. when the page holding the script is accessed with ?outputSyntax=plain). Such a UI extension can thus be excluded from the output because an HTML renderer will ignore non-HTML raw blocks (same as a plain text renderer will ignore HTML raw blocks).

  This problem doesn't manifest when using {{uiextension}} or {{uiextensions}} macros, which is why we recommend using them when wiki syntax is available. But we still have a lot of UI extension points in Velocity-only templates. For this we introduced the following new script service APIs to execute and render UI extensions in a given syntax:

  $services.uix.render($uix, 'html/5.0')
  $services.uix.renderExtensions('org.xwiki.platform.template.header.after', 'html/5.0')
  $services.uix.renderExtensions('org.xwiki.platform.html.head', 'html/5.0', {'sortByParameter': 'order'})

  Checkout the documentation for more information.

• Count the distinct XWiki instances behind the Active Installs pings:

  The Active Installs script service could only count pings, and an instance sends many of them — one a day, plus one on every restart — so counting the instances themselves meant post-processing the pings by hand. Two new methods count instances directly: countDistinctInstalls returns the total, and countDistinctInstallsByExtension returns the breakdown by extension, computed in a single query rather than one query per extension. Both are experimental for now.

  See Active Installs Script Service for the signatures, the precision limits and query examples.

• Integration tests use SILO instead of MinIO:

  Browser-based integration tests support using S3 as blob store to ensure compatibility with it. Until now, we were using MinIO as S3-compatible object storage implementation in our test setup but as that open-source software has been archived and the Docker image was unpublished recently, we've switched to SILO, an actively maintained fork, instead. This shouldn't change anything unless you were passing explicit versions when running tests.

• Number fields reject invalid values before saving:

  A Number property is now edited with an HTML5 number input, so the browser rejects letters and, for the integer and long types, decimal values before the form is submitted. A value outside the integer range is refused the same way, and a value outside the long range is now reported with a readable message on save instead of a server error.

  The "Size" property metadata no longer applies to a Number field: the attribute it used to set is ignored on a number input, so it is no longer emitted.

• New extension point to skip the edit lock confirmation:

  An editor that supports realtime collaboration can waive the confirmation that XWiki asks for before taking over the edit lock of a Page, because the users are going to edit that Page together. Until now the only way to do this was to extend the documentLock edit confirmation checker and register the subclass under the same component hint, so only one extension at a time could waive the confirmation.

  The decision is now taken by org.xwiki.doc.lock.UnlockRule components: each one is asked whether the lock can be taken over silently for the document and the edit mode described by the LockContext it receives, and the confirmation is skipped as soon as one of them accepts. XWiki provides two rules, one for the Netflux based realtime editing (wiki syntax and CKEditor) and one for BlockNote; the override that the realtime module used to register has been removed.

  See Document Edit Lock Confirmation for the details. The new API belongs to xwiki-platform-oldcore and is unstable, so it may still change in a backward incompatible way.

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
• English (British)
• French

Tested Browsers & Databases

Automated Testing

XWiki executes a lot of automated tests during its build, testing all supported configurations.

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.

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 18.8.0-rc-1

Change in password format

The passwords handled by PasswordClass in XWiki (so including standard XWiki users passwords as well as any XClass password property) used to be stored following the format: hash:<algorithmName>:<salt>:<hash>. This format is no longer used in XWiki and has been replaced by the more standard format: {algorithmKey}<encodedHash>, where the format of the hash itself depends on the algorithm and contains information about the salt etc. For more information check the PasswordClass documentation.

Migration of passwords

The security of algorithms used for hashing passwords has been reinforced as part of this release. As a result, we're automatically performing a re-hash operations of all passwords during a migration: this operation doesn't perform any reset of the passwords, so they can still be used properly. However, you might see warnings in your instance related to usage of old-style passwords: it is recommended to ask users to reset their passwords to use the new format.

API Breakages

The following APIs were modified since XWiki 18.7.0:

Real breakages

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

• Unused WikiModel serializer API. XWiki serializes through the Renderer/Listener implementations in xwiki-rendering-syntaxes, never through WikiModel's serializers. This interface was imported with WikiModel in XRENDERING-173 and has never had an implementor nor a caller.
  • Violation type:

    java.class.removed

  • Code:

    ## Old:
    interface org.xwiki.rendering.wikimodel.IWikiSerializer

• Unused WikiModel serializer, never completed (its javadoc says "Not ready yet.") and never called. JSPWiki rendering is handled by xwiki-rendering-syntax-jspwiki.
  • Violation type:

    java.class.removed

  • Code:

    ## Old:
    class org.xwiki.rendering.wikimodel.jspwiki.JspWikiSerializer

• Unused WikiModel serializer for XWiki 1.0 syntax, imported with WikiModel in XRENDERING-173 and never called. XWiki syntax rendering is handled by the renderers in xwiki-rendering-syntaxes.
  • Violation type:

    java.class.removed

  • Code:

    ## Old:
    class org.xwiki.rendering.wikimodel.xwiki.xwiki10.XWikiSerializer

• Unused WikiModel serializer for XWiki 2.0 syntax, imported with WikiModel in XRENDERING-173 and never called. XWiki syntax rendering is handled by the renderers in xwiki-rendering-syntaxes.
  • Violation type:

    java.class.removed

  • Code:

    ## Old:
    class org.xwiki.rendering.wikimodel.xwiki.xwiki20.XWikiSerializer2

• We changed the default algorithm for PasswordClass hash computation for something more robust and we also changed the format of the hash for better handling in the future.
  • Violation type:

    java.field.constantValueChanged

  • Code:

    ## Old:
    field com.xpn.xwiki.objects.classes.PasswordClass.DEFAULT_HASH_ALGORITHM
    
    ## New:
    field com.xpn.xwiki.objects.classes.PasswordClass.DEFAULT_HASH_ALGORITHM

• We changed the default algorithm for PasswordClass hash computation for something more robust and we also changed the format of the hash for better handling in the future.
  • Violation type:

    java.method.removed

  • Code:

    ## Old:
    method java.lang.String com.xpn.xwiki.objects.classes.PasswordClass::getPasswordHash(java.lang.String, java.lang.String, java.lang.String)

• We changed the default algorithm for PasswordClass hash computation for something more robust and we also changed the format of the hash for better handling in the future.
  • Violation type:

    java.method.removed

  • Code:

    ## Old:
    method java.lang.String com.xpn.xwiki.objects.classes.PasswordClass::getSaltFromPassword(java.lang.String)

• We changed the default algorithm for PasswordClass hash computation for something more robust and we also changed the format of the hash for better handling in the future.
  • Violation type:

    java.method.removed

  • Code:

    ## Old:
    method java.lang.String com.xpn.xwiki.objects.classes.PasswordClass::randomSalt()

Unstable APIs

Not real backward compatibility breakages since they were done on APIs marked @Unstable (a.k.a Young APIs). Thus it's part of the contract that they can be broken until they become stable. They're listed purely for reference in case you decided to still use them (and thus agreed to be broken).

• UserManager#hasAccess() is an unstable API. Checking any right on a user through the user API was too broad, checking view access makes sense but others are out of scope. It is now replaced by UserManager#hasViewAccess().
  • Violation type:

    java.method.removed

  • Code:

    ## Old:
    method boolean org.xwiki.user.UserManager::hasAccess(org.xwiki.security.authorization.Right, org.xwiki.user.UserReference, org.xwiki.user.UserReference)

• UserManager#hasAccess() is an unstable API. Checking any right on a user through the user API was too broad, checking view access makes sense but others are out of scope. It is now replaced by UserManager#hasViewAccess().
  • Violation type:

    java.method.addedToInterface

  • Code:

    ## Old:
    
    
    ## New:
    method boolean org.xwiki.user.UserManager::hasViewAccess(org.xwiki.user.UserReference, org.xwiki.user.UserReference)

Credits

• Andi Chandler
• ClementEXWiki
• elenicojocariu
• LucasC
• Manuel Leduc
• Marius Dumitru Florea
• Michael Hamann
• Pierre Jeanjean
• Simon Urli
• Simpel
• Thiago Krieck
• Thomas Mortagne
• Vincent Massol
• xrichard