Changes Report

Performance improvement in templates

Wiki skins and filesystem templates are now cached. In addition, the Velocity from Velocity templates (not yet those based on wiki syntax) is compiled to speed up following executions.

The first performances tests suggest that the XWiki Standard skin is now up to 5 times faster thanks to this caching.

It will continue to improve in upcoming versions of XWiki with the caching and compilation of Velocity (and other costly tasks) in other areas (templates located in JAR extensions, velocity scripts located in wiki content like UI extensions and panels, code macros, etc.).

XJetty Debian packages

XWiki now comes with new Debian package based on a customized Jetty optimized for XWiki that you can use instead of the traditional Tomcat based XWiki Debian package which unfortunately don't work on Debian 12+. See InstallationViaAPT for mode details.

Block preparation and caching

To continue the work on improving the performances and benefit from the Velocity scripts compilation introduced in 15.8, the concept of block preparation has been added to the Rendering framework. The goal is to pre-execute everything that does not rely on the context in a XDOM and cache it to not redo all this in each transformation pass.

The rendering framework now offers a helper to make a lot easier to cache part of the execution of a macro. When preparing a Block, the Macro transformation will call the new Macro#prepare API that any macro can implement to reduce the time spent in Macro#execute.

In 15.9, the following macros are prepared:

• the content is compiled in the velocity macros
• the wiki content is parsed (and the resulting blocks are prepared) in the following macros
  • box
  • info
  • warning
  • error
  • success
  • content
  • footnote
  • html
  • async
  • context
  • cache
  • container
  • gallery
  • translation

And the XDOM is prepared and cached in the following use cases:

• The content of the UI extensions
• The content of the panels
• The content of the wiki macros

See ExtendingMacro for more details.

Required Rights

When the rights of the current author are different from the rights of the page author, a required rights analyzer is executed.

This analyzer can raise a warning if:

• the current user has more rights than the content author (e.g., a macro previously failing by lack of right might start being evaluated)
• the current user has less rights than the content author (e.g., a macro previously working might stop working by lack of rights)

Note that this analysis is currently disabled by default. See the Admins section.

Required Rights

New APIs have been introduced for required rights, a new mechanism for explicitly marking which rights the content of a document needs. 

This provides two protections:

• Restricting script executions in documents where scripts haven't explicitly been enabled, 
• Preventing users without script, admin, or programming right from editing documents that require these rights. 

For now, this is a developer-only change, required rights aren't enforced by default and there is no UI (a UI is planned for a following release). Developers whose extensions depend on XWiki 16.10.0+ are encouraged to start using the new document authorization manager when checking the rights of document authors, e.g., when registering a component based on an XObject. 

Extensions can also start enforcing required rights on their documents, marking which pages need wiki admin or programming right for example and check if their extensions still work when enabling enforcing required rights for these documents. 

The XAR Format Specification has been adapted, accordingly. If not done already, required rights analyzers should be implemented for all XObjects and macros that need rights beyond what's covered by standard fields. This includes for example the interpretation of Velocity code in fields that aren't marked as containing Velocity code, or requiring wiki admin right for certain scope values. Those analyzers are necessary to allow suggesting the user all rights that are required by a page.

Users with edit rights can pin pages in spaces

It was already possible for global administrators and administrators of spaces to pin pages for organizing the navigation panel. Now the feature is also available for people having edit rights on a space: a new tab is available in the page children view, available from the more action menu. From this new tab, it is possible for a user to entirely reorganize the pages of the space by using drag & drop or by using the action button to pin / unpin pages, pretty much like it was already possible in the navigation panel administration.

Realtime WYSIWYG Editing Bundled by Default

The realtime WYSIWYG editor is now bundled by default in XWiki Standard. It's still an experimental feature, so you have to enable it if you want to try it out. We refactored the code to make it a CKEditor plugin rather than a separate editor (based on CKEditor) so in order to enable realtime collaboration for the WYSIWYG editor you have to remove (uncheck) the "xwiki-realtime" from the list of disabled plugins in the CKEditor administration section. Make sure you read the list of known limitations before you try it out.

Pinned Pages

You can now manually change the order of the pages displayed in all the page trees used in the wiki (Navigation tree, Breadcrumbs tree, Page Index Tree, etc). It's not a fully manual order but rather a mix of manual and automatic order: some pages, we call them "pinned" pages, are displayed first (in manual order), followed by the rest of the child pages in automatic order (e.g. by page title). You can pin pages at any level in the page tree hierarchy using the dedicated administration section. For a given parent (nested) page the list of pinned child pages is saved in its page preferences. The list of top level pinned pages are saved in the wiki preferences.

The screenshots show the effect of pinning the Nested1/Nested2/Pinned Page Example page in various trees in the XWiki UI (namely: Navigation tree, Breadcrumbs tree and Page Index Tree).

Besides the new administration section, we also updated the Navigation Panel administration section to allow you to change the order of the top level pages and save this manual order using pinned pages. Basically, whenever you move a top level page to a new position, that page and all its previous sibling pages become pinned. You can of course unpin a top level page.

Users with edit rights can pin pages in spaces

It was already possible for global administrators and administrators of spaces to pin pages for organizing the navigation panel. Now the feature is also available for people having edit rights on a space: a new tab is available in the page children view, available from the more action menu. From this new tab, it is possible for a user to entirely reorganize the pages of the space by using drag & drop or by using the action button to pin / unpin pages, pretty much like it was already possible in the navigation panel administration.

Respect name strategy from WYSIWYG Editor inserted links

It is now possible to create more easily links to page not yet existing from the link modal of the WYSIWYG editor. One option is by typing a link name: the suggester will propose to create a link in current space, or for advanced user it's possible to specify the exact reference and to select the option to create the link with that specific reference. The other option is to create the needed hierarchy from the tree. The links that are created that way will always follow the configured name strategy of the wiki.

Extension Supported By

Extensions now have the concept of supporters and support plans. The goal is to replace the very vague concept of Recommended we currently have for a very explicit pledge of organizations and individuals (Supporters) to support an extension, and to which extent (Support Plans).

See Extension Manager Application and https://extensions:Extension.Repository Application for more details.

Realtime WYSIWYG Editing Enabled by Default

Realtime editing is now enabled by default when editing the content of a wiki page using either the in-place or the standalone WYSIWYG editor. We encourage you to test it and report any issues you may find so that we can fix them before the new LTS version (16.10.x). For more information about the realtime WYSIWYG editor, including its limitations, please check the documentation.

Move to Jakarta EE 9.1

XWiki moved to Jakarta EE 9.1.

The main benefit is that XWiki can now run in jakarta.* based application servers (like Tomcat 10+, Jetty 12 EE9/10).

See the retro compatibility section for more details about the potential breakages.

Attachments and recycle bins can be stored in S3

XWiki now optionally supports storing attachments, deleted attachments and deleted pages in Amazon S3 or S3-compatible storage as it is provided by many cloud providers and open source implementations. This eliminates the need for a shared file system in clustering setups. Even with S3, XWiki currently still needs permanent file storage, we'll continue removing the need for permanent file storage in the next releases.

By default, XWiki still uses the file system for storing attachments, deleted attachments and deleted pages, and we have no plans to discontinue support for it. Currently, S3 support needs to be installed explicitly before enabling it. When configured, existing data is migrated on the first start. See how to configure the S3 blob store for details.

Document save speed improvements

• Only modified objects are now really sent to the database. This should provide an important performance boost when doing small modifications to an existing document that contains a lot of objects.
• XWiki does not store diff anymore for the history. It was not adding that much value and could be very expensive for big documents.

Page rendering performance improvements

The macros of the main /view/ are now prepared (the part of the execution that does not depend on the context is cached). Also, preparation has been added to both the code macro and the wiki content passed to various wiki macros. This should improve the performance of quite a lot of complex pages (especially those containing velocity or code macros).

Users with edit rights can pin pages in spaces

It was already possible for global administrators and administrators of spaces to pin pages for organizing the navigation panel. Now the feature is also available for people having edit rights on a space: a new tab is available in the page children view, available from the more action menu. From this new tab, it is possible for a user to entirely reorganize the pages of the space by using drag & drop or by using the action button to pin / unpin pages, pretty much like it was already possible in the navigation panel administration.

New Realtime Editing Toolbar

The toolbar that is displayed at the bottom of the page when editing in realtime has been redesigned:

• The "Save & View" button has been renamed to "Done"
• The "Save" (and continue) button has been removed because it's not needed as much with auto-save. You can still use the save & continue shortcut key though (Alt+Shift+s).
• The "Cancel" button has been removed because its behavior with auto-save is confusing. You can still use the cancel shortcut key (Alt+c) though to leave the edit mode without saving.
• The list of connected users has been moved here from the WYSIWYG editor toolbar. Besides the user avatar we also show the username abbreviation. If there are many users connected you can see all of them in the users' dropdown.
• "Allow realtime collaboration" checkbox has been renamed to "Leave Collaboration" and is now located in the Done dropdown.
• The save status is displayed directly on the toolbar (unsaved, saving, saved)
• There is a new history dropdown on the right side that shows recently saved versions of the edited document, along with their author. You can use this to see the content of the edited document in those specific versions.
• The "Minor edit" and "Version summary" fields have been moved to the "Summarize Changes" modal. Basically, you can:
  • either use the "Summarize Changes" entry from the history dropdown to review and summarize the current changes, then continue editing
  • or use the "Summarize & Done" entry from the Done dropdown to review and summarize the changes before leaving to view mode

Check the realtime editing module for more information.

Improvements in Wiki Macro Parameters

Wiki Macro Parameters class has been improved to allow defining the same properties it was already possible to define in Java macro parameters. In particular it's now possible to define the following properties:

• Parameter feature (optional): Allows to specify the name of the feature this parameter is bound to. If several parameters are bound to same feature, it means a choice need to be made between those parameters.
• Parameter group (optional): Allows to specify the name of the group this parameter belongs to. This allows to visually shows the parameters together in the macro configuration UI.
• Parameter hidden (optional): Indicates whether the parameter should be displayed or not in the macro configuration UI.
• Parameter advanced (optional): Indicates whether the parameter should be emphasized or not in the macro configuration UI.
• Parameter deprecated (optional): Indicates if the parameter is deprecated and shouldn't longer be used.
• Parameter feature mandatory (optional): Indicates if the parameter feature is mandatory, i.e. the parameter itself might not be mandatory but if the feature is then at least one of the parameters of the feature should be used.

New UI for setting required rights

A new UI for setting the required rights of a page has been added. Required rights are the rights that a page requires for executing script macros or registering a UI extension. This new UI allows selecting if required rights shall be enforced, and allows specifying which rights shall be enforced. When required rights are enforced, the page can only use the specified rights and only users with those rights can edit the page. This avoids that, for example, a script macro added by a user without script right is executed when a user with script right saves the page, or that users accidentally break a page when they edit it without having the required rights.