Changes Report

Revamping of the macro configuration UI

The macro configuration UI displayed in the WYSIWYG editor has been entirely revamped to improve its usability and for supporting order of parameters. This revamping brings a new UI to better display groups and features in macro parameters, and also allows to support validation of mandatory features. On top of that it also guarantees the stability of the displayed order of the parameters.

Dynamic configuration input

It's now possible to overwrite properties from configuration files like xwiki.cfg, xwiki.properties using Java system properties or environment variables. See Configuration Module for more details.

New configuration also been introduced to benefit from it:

• it's now possible to set the cluster id through configuration
• it's now much simpler to disable the scheduler through configuration

New security check on external URLs

A new security mechanism related to URLs has been put in place in XWiki to inform users when they click on a link leading to an external URL that does not belong to the list of trusted domains. This mechanism is enabled by default only on links put on comments, but can be enabled for the whole wiki too. It reuses the list of trusted domains that can be configured in xwiki.properties, and a new configuration has also been provided to allow specifying specific URLs that can be accessed without any warning from the frontend. Finally it's possible to also disable the new security mechanism thanks to a dedicated configuration. 

#-# [Since 17.9.0]
#-# [Since 17.4.7]
#-# [Since 16.10.14]
#-# Define the policy to use for URL checks performed in the UI, whether the user should be asked for confirmation
#-# when going to an untrusted domain.
#-# Accepted values for this property are: enabled, disabled, or comments.
#-# Enabled means that the check will be enforced in all the wiki UI, disabled that the check will never be
#-# performed, and comments (default value) means that the check will only be performed on links provided in the
#-# comments of the wiki.
#-#
#-# By default this property is set to comments:
# url.frontendUrlCheckPolicy=comments

#-# [Since 17.9.0RC1]
#-# [Since 17.4.6]
#-# [Since 16.10.13]
#-# Allow to allow specific URLs to be accessible from the frontend without asking confirmation, and without
#-# needing to allow and entire domain. The expected format is absolute URLs separated by commas, e.g.:
#-# https://github.com/xwiki/xwiki-platform,https://www.xwiki.org/xwiki/bin/view/Main/WebHome
#-#
#-# By default this property is empty:
# url.allowedFrontendUrls=

New security check on external URLs

A new security mechanism related to URLs has been put in place in XWiki to inform users when they click on a link leading to an external URL that does not belong to the list of trusted domains. This mechanism reuses the list of trusted domains that can be configured in xwiki.properties, and a new configuration has also been provided to allow specifying specific URLs that can be accessed without any warning from the frontend. Finally it's possible to also disable the new security mechanism thanks to a dedicated configuration. 

#-# [Since 17.9.0RC1]
#-# [Since 17.4.6]
#-# [Since 16.10.13]
#-# Allow to enable or disable checks performed when clicking links in the UI based on the list of trusted domains.
#-#
#-# By default this property is set to true:
# url.frontendUrlCheckEnabled=true

#-# [Since 17.9.0RC1]
#-# [Since 17.4.6]
#-# [Since 16.10.13]
#-# Allow to allow specific URLs to be accessible from the frontend without asking confirmation, and without
#-# needing to allow and entire domain. The expected format is absolute URLs separated by commas, e.g.:
#-# https://github.com/xwiki/xwiki-platform,https://www.xwiki.org/xwiki/bin/view/Main/WebHome
#-#
#-# By default this property is empty:
# url.allowedFrontendUrls=

Require Java 21

XWiki now requires at least Java 21 and now officially support up to Java 25.

Client-Side component manager

Similarly to the server-side Component Module, it is now possible to define and inject components client-side (e.g., using JavaScript or Typescript). See the how-to for a complete example.

BlockNote Realtime Collaboration

The experimental BlockNote WYSIWYG editor integration now supports realtime collaboration based on Yjs. This feature is enabled by default. You just need to install the extension and edit the same wiki page. There are a couple of limitations that we are aware of, though:

• you need to force the edit lock to join the collaboration session
• there is no auto-save
• it doesn't use the realtime editing toolbar that is currently used by CKEditor integration
• macro output is included in the synchronization (e.g. if a macro shows private information that depends on the current user, that information will be shared with all the collaborators joining the same editing session)
• while it does support clustering (in a best case scenario), it doesn't handle recovery in case a cluster node is restarted or disconnected and reconnected (after some time)

We hope to handle these limitations in the next versions.

Improved Conversion between BlockNote and XWiki Syntax

The BlockNote editor integration is now converting the BlockNote syntax used by the editor directly to the back-end syntax (e.g. XWiki 2.1). By removing the UniAst intermediary conversion step we could improve the conversion fidelity. We worked on reducing the gap between BlockNote syntax and XDOM (XWiki syntax's AST) by:

• extending the BlockNote schema to support most of XDOMs's blocks (i.e. avoid loosing data when loading the editor)
• mapping special BlockNote content to the right XWiki syntax (i.e. avoid loosing BlockNote content on save)

Here's a list of notable improvements:

• XWiki group syntax is now preserved. You can't add groups (DIVs) from BlockNote, but you can edit the content of existing groups (inserted from XWiki syntax). Syntax like this:

  * list item(((
  nested paragraph
  )))

  is properly edited and saved.

• Link resource reference and custom parameters are now preserved on save. You can't modify the parameters (e.g. a CSS class name like in [[Some.Page||class="page-link"]]) from BlockNote, but they are preserved even if you change the link target. The link URL in edit mode is now pointing to the right target (clicking on the link opens the expected page).
• Links without label (e.g. [[Some.Page]]) get a generated label that is saved only when modified.
• Freestanding link and image syntax is preserved, e.g. image:attach:avatar.png
• Nested macros are now properly rendered in edit mode. There can still be some minor differences in the macro output between view mode and edit mode.
• Attached images are now properly displayed in edit mode. Moreover, image custom parameters (e.g. a CSS class name or some data attribute as in [[image:avatar.png||class="user-avatar"]]) are preserved on edit and save, even if you change the image source through the image editor.
• Image caption is preserved (e.g. [[some caption>>image:attach:avatar.png]]), but you can't edit it from BlockNote currently (it is displayed read-only).
• Table custom parameters are preserved, but you can't change them from BlockNote. Note that table cell parameters are still lost.
• Table header cells are preserved, but you can't have a header cell after a normal cell on the same row/column. This means header cells have to be put at the top of left of the table.
• Definition lists (inserted from XWiki syntax) are preserved on save. You can edit their content, but you can't add new definition lists from BlockNote.
• Default BlockNote styles don't pollute the output XWiki syntax anymore.
• The macro output is better highlighted (for both inline and block-level macros)
• The macro output is replaced by the macro placeholder after a macro is edited. We hope to work soon on reloading the content after a macro is edited or inserted, in order to have the updated macro output.

See the BlockNote Editor Integration documentation for more information.

Edit mode and row creation support for Live Data

Live Data now offer a new "Edit Mode", that can be enabled in Live Data instances using a livetable source with the parameter hasEditMode set to true.

This mode offers support for bulk edition of Live Data content (including keyboard navigation), and also the ability to create new rows (which requires also setting the livetable source parameters newRowLocation and newRowNamingStrategy).

Please note that this feature is still experimental and the user experience will be improved in future releases.

New Homepage

We replaced the Dashboard application from the main Homepage and added introductory steps as wiki syntax. This change will make it simpler for new users to edit the Homepage content, while also benefiting from some basic help concepts. The left panels area also showcases now the 'Navigation' panel, while the right panels area contain a 'Need Help?' panel.

Application Index

We removed some applications from the AppBar (like Scheduler, Invitation, Panels, etc.) with the intention to simplify the interface and promote a smaller number of applications inside the AppBar panel. In order for the applications to still be discoverable, we added in the Drawer an Application Index.

Children Macro

A new {{children/}} macro has been added to display a tree view of all children of the current page.

XAR Children Export

It's now possible, for HTML and XAR formats, to export selected children along with the current page.

Display recommended extensions in the Extension Manager

Extension Manager is now displaying only recommended extension by default.

You can still switch to All Remote Extensions. If no recommended extension is can be found for the provided search, the result for All Remote Extensions is displayed.

Templates from JARs

TemplateManager component now also search for templates in current Thread classloader which mean you can put your templates inside your JAR in the /templates folder. This is the last step to any JAR extension can provide default template which can be overwritten in a skin on in /template/ WAR resources.

App Within Minutes integration with Create Page dialog

We added a new step to the App Within Minutes wizard to configure the location where the application entries are created. This step generates a template provider for the application and thus exposes the application in the Create Page dialog. This means that now you can create application entries not only from the application home page (using "Add new entry") but also from other pages using the Create Page dialog.

New applications created with the new version of the App Within Minutes wizard will not use the Data page any more. The application entries will be created directly under the application home page by default. Of course, you can configure the location with the new wizard step.

CKEditor Integration Improvements

The CKEditor Integration extension has been upgraded to version 1.9 which brings a couple of improvements and bug fixes:

• The "WYSIWYG Editor" section from the Wiki Administration has been extended to support CKEditor configuration
• The link dialog has a new text input to specify the link label
• The form action buttons are now available in full-screen mode
• CKEditor has been upgraded to the latest stable version 4.5.11

CKEditor Integration Improvements

CKEditor has been upgraded to version 4.6.0 which brings a new flat skin and a lot of improvements and bug fixes. The XWiki integration has been improved to support automatic link creation when dropping a non-image file over the editing area. Creating a link to a non-existing wiki page has been simplified. Check the CKEditor Integration documentation for more information.

Drawer menu has changed

The drawer menu has changed to display the "scope" of the displayed items. Items are ordered regarding if their scope is "local" (i.e. it affects only the current wiki) and "global" (i.e. it affects the whole farm).

The change have been made after users complaining the old menu was not very clear, and after a poll sent on the mailing list.

Some items like "Home", "Create Wiki" and "Delete Wiki" has been removed from that menu, in order to focus on frequent operations that really deserve a place in this important menu. We offer other means in the UI to achieve these operations.

XAR export/import changes

• The XML produced in XAR files is now following the XML 1.1 specification (instead of 1.0). Since it's mostly about supporting thing that were simply not working before there should not be any retro compatibility issues.
• All from/toXML methods located in classes like XWikiDocument, BaseObject, BaseClass, etc. are now based on Filter modules which became the only way to produce XAR XML format. The only difference remaining when using xwiki.action.export.xar.usefilter and xwiki.action.import.xar.usefilter properties in xwiki.cfg configuration file is the handling of the XAR packaging.