Summary of the XWiki 10.x Cycle

Last modified by Ecaterina Moraru (Valica) on 2019/01/08

This is a summary of the release notes for XWiki Commons, XWiki Rendering and XWiki Platform, for the whole 10.x cycle (i.e. the whole year 2018). They share the same release notes as they are released together and have the same version.

10.x cycle is defined by having an improved usability for on-boarding new users and administrators: from protection against refactoring operations, to editing inline macro content, to more auto-suggests, to a faster user interface.

Here are some stats of what happened during the 10.x cycle, more than:

  • 750 issues were closed (see the full issue list)
  • 415 bugs closed, 160 improvements, 31 new features and more:


  • And the top participants (those contributing to more than 1% of the total issue number):


Congrats to all who participated!

Top 10 Features

We've handled various areas of XWiki in order to achieve that and here are the top 10 features that we wish to mention (arbitrarily hand-picked; it's hard to pick only 10):

  1. Look & Feel
  2. Navigation Administration
  3. Protection of Refactoring operations
  4. Editor Improvements
  5. Auto-suggest for pages
  6. Improved user sections
  7. Notifications
  8. Under the hood
  9. New community extensions
  10. XWiki SAS Store

Look & Feel

In the 10.x cycle the look & feel didn't changed drastically, but we've worked mostly on consistency and polishing of the visual elements we already have. In this section we can mention from improved PDF export, to consistent modals and icons, to adding new extension points; but our top 3 changes are:

New colors

In the beginning of the cycle we've refreshed our color theme while keeping our professional and clean look & feel. Our community voted for blue as our main color, replacing the black color we had in the past.

Visible Save

We made sure the save buttons are always visible when editing the content of the page. We've also simplified the available options and naming so that the editing process becomes more natural.

Faster UI

We've added a new asynchronous rendering framework that assures that panels, menus, wiki UI extensions and wiki macros are cached and thus load much faster. This allows to have the page content rendered much faster than before giving a nice feeling of increased performance and snappiness.

Navigation Administration

The Navigation Panel is now configurable and we've removed the XWiki-specific pages in order to provide an uncluttered view. You can now drag pages from the navigation tree to exclude or include them, while making sure the navigation is focused on users content pages.

Also the Menus are now integrated inside the Administration.

Protection of Refactoring operations

In order to prevent accidental modifications of extensions pages and classes, pages that belong to installed extensions are now protected for the majority of refactoring operations: edit, rename, move, delete. Users are forbidden or warned that their actions will have consequences. This assures to have fewer unnecessary errors and to inform users about the nature of existing pages.

Editor Improvements

We've added several improvements to our CKEditor integration. Here are our top 3: 

Inline Macro Content Editing

We support inline editing of the content for some macros (like box, info, warning, error and figure macros). The user can edit directly in the context of the editor, instead of going to the dedicated macro modal.

Link Autocomplete

You can now create links to existing wiki pages and attachments directly from the editing area using the link auto-complete feature. Just type [ (open square bracket) followed by at least 2 characters and you will get link suggestions based on the typed text.

Macro Content Prefill

When inserting a macro, the macro content text area is prefilled with the text selected within the editing area.

Auto-suggest for pages

Several inputs related to selecting pages references now support auto-suggestion, making it much simpler to use and less error prone (such as not having to know if the reference should end with WebHome). You can find these inputs in Administration, when using the standard classes or you can use it when creating your own applications.

Improved user sections

We've revamped several places to use the new compact users displayer. We display the user / group avatar followed by the user / group name, while suggestions are retrieved from both the current wiki and the main wiki.

We've improved the Groups section in Administration to display the user type and scope. Also we are finally displaying the user membership in the profile.


We've continued the work on Nofications, by providing loads and loads of improvements and bugfixes. Notifications were the highlight on our 9.x cycle, but they made a come back also this year. We've improved our filtering mechanism and default values, added new macros, added auto notifications on changes, etc. A very important aspect was making it more scalable for handling large volumes.

The Notifications Application is now the central feature in XWiki for notifications, finally replacing the Watchlist and the Activity Stream features.

Under the hood

It's much easier to mention visual features, since we have screenshots to show, but under the hood features usually do all the heavy duties. Usually these features are mostly targeted towards administrators, but since they are so nice, we thought we could mention a couple:

Improved Multi-Term Search Relevancy

This is commonly referred to as sloppy phrase matching and allows for more "Googleish" query strings. The allows for partial multi-term matching so that searching for long phrases won’t “hide” documents with a subset of shorter multi-term matches.

Filesystem store improvements

Filesystem store is now the default location for attachments and deleted documents.

Also we've added support for case insensitive filesystems. 

On top of that, we support larger attachments by default. Until now the default limit for attachments was set at 32MB. It's now been increased to 100GB.

New community extensions

2018 was a good year for extensions, with over 40 new extensions released and plenty of releases for the existing extensions. We want to thank all our contributors that spread the love for open source and invest in new ways of using and extending XWiki.

CAPTCHA implementations

Currently CAPTCHAs are used by default in the Registration and Comments areas. A new CAPTCHA application was been implemented and now you can extend and change the implementation you use across the wiki from the Administration. You can install the popular Google reCAPTCHA integration or use the default JCaptcha that provides image, sound and text CAPTCHA formats.


You can now use LaTeX syntax to write content inside XWiki. You can use LaTeX to add formulas, table of content, containers, footnotes, etc. 

Also if the existing PDF export is not good enough for your needs, consider using the LaTeX exporter.

New macros

Lots of new macros available, but we're going to mention just the most popular:

XWiki SAS Store

XWiki's ecosystem continues to grow and this year we've also seen an increase in the the number of professional extensions that come with included support. XWiki SAS Store currently contains over 15 extensions.

XWiki's Extension Manager is connected to the XWiki SAS Store (thanks to the XWiki SAS being a top sponsoring company) and these extensions can easily be installed from your instances. You can read more about paying extensions.

Top User Features

For our users, here are the top features that we wish to highlight:

Notifications fully replace the Watchlist

It's finally done! In this version, we have decided to disable the Watchlist in XWiki, by default. Instead, the Notifications Application is now the central feature in XWiki for notifications. 

Don't forget to warn your users about the need to enable email in their notification settings!

Note: you can rollback this change by disabling the Notifications Application and enabling the Watchlist again.

Improved performances

We have enabled asynchronous rendering of several UI elements: side Panels, Menu entries and more. This allows to have the page content rendered much faster than before giving a nice feeling of increased performance and snappiness.

Inline Macro Content Editing

The macro content can now be edited inline with the WYSIWYG editor, if the macro is used on a separate line (stand-alone, not inside a paragraph of text) and the macro descriptor declares that its content is rendered without being transformed. There are a few macros that do this at the moment (box, info, warning, error and figure macros) but we're planing to add support for more macros in the next versions.

See the CKEditor Integration documentation for more information.

New default Color Theme

We wanted to refresh the default color theme (Charcoal) for the XWiki Standard 10.x cycle and the community voted for the Iceberg theme, which is our new default theme. We kept a professional / clean look and feel and opted for blue as our main color. The purpose of the default color theme is to cover as many use cases as possible, so if you want to spice up your instance try one of our community contributed color themes

New Notifications Macro

It is now possible to list the notifications for the wiki by using the Notifications Macro. You can use it in any page or any dashboard. The goal is to be able to replace the Activity Stream which is going to be deprecated (too slow and missing some features).

Page fields now support auto-suggestion

You can now use the auto-suggestion feature on Page fields by typing the page title or the page reference. 

Link Autocomplete in WYSIWYG Editor

You can now create links to existing wiki pages and attachments directly from the editing area using the link auto-complete feature. Just type [ (open square bracket) followed by at least 2 characters and you will get link suggestions based on the typed text. Checkout the CKEditor Integration documentation for more information.

New CAPTCHA API and CAPTCHA implementations

A new CAPTCHA Application and API have been implemented, replacing the old Captcha Module, thus making it even easier to use and validate a CAPTCHA in a form. Also, it's now very easy to change the CAPTCHA implementation that you want to use in your wiki, directly from Administration, without having to touch a line of code.

Also, a new and much more extensive JCaptcha implementation has been provided for the new API, that works offline and features image, sound and text CAPTCHAS. It is bundled by default with XWiki Standard.

As a popular alternative, a Google reCAPTCHA implementation is also available, installable as an extension using the Extension Manager.

The locations in XWiki where CAPTCHA is being used by default (e.g. Registration and Comments) will use the CAPTCHA implementation that you have enabled and configured in the "Administration >> CAPTCHA" section.

Auto-suggest for pages

Several inputs related to selecting pages references now support auto-suggestion, making it much simpler to use and less error prone (such as not having to know if the reference should end with WebHome or not!). See the screenshots for some examples.

Activity Stream is not bundled anymore

The good old Activity Stream Application is not bundled anymore with XWiki. This decision has been made because the Notifications Application can now handle the same features with better performances.

As a consequence, we have also modified every applications that was using Activity Stream to use the new Notifications features.

For backward compatibility, we also provide a Legacy Notification Activity Macro that would help you not to break the pages you have created with the use of the {{activity/}} macro..

Top Admin Features

For our admins, here are the top features that we wish to highlight:

XAR entry types improvements

Starting XWiki 10.4 we started to introduce the concept of page "Types".

  • Several ways to protect extension pages are now provided and can be configured in

    #-# The possible choices are:
    #-# * none: no protection at all
    #-# * warning (the default): everyone get a warning when trying to edit a protected document
    #-# * deny = EDIT/DELETE right is denied for everyone except for admins who just get a warning
    #-# * forcedDeny = EDIT/DELETE right is denied for everyone, admins can't force edit/delete
    #-# * denySimple = EDIT/DELETE right is denied for simple users except for simple admins who just get a warning
    #-# * forcedDenySimple = EDIT/DELETE right is denied for all simple users, simple admins can't force edit/delete
  • Main.WebHome page entry type is now demo since the wiki home page is configurable so there is no reason to prevent its deletion
  • XWiki.XWikiAdminGroup page entry type is now configuration, was forgotten in previous version
  • the type home has been removed since it was designed for wiki home page use case which does not make much sense anymore

Filesystem store by default

Filesystem store is now the default location for attachments and deleted documents. See attachment storage documentation for more details.

Top Developer Features

For our developers, here are the top features that we wish to highlight:

New asynchronous rendering framework

It's now possible to easily enable asynchronous execution and caching for panels, wiki UI extensions and wiki macros.

The following fields have been added:

  • Asynchronous rendering (async_enabled): a boolean indicating if the element should be executed asynchronously. Disabled by default.
  • Cached (async_cached): a boolean indicating if the result of the execution of the element should be cached. Disabled by default.
  • Context elements (async_context): the context information required for the execution of the element (current user, current document, etc.). It's also used to generate the cache key.

A org.xwiki.rendering.async.AsyncContext Java class and corresponding $services.async script service have been introduced to control:

  • if the asynchronous execution should be enabled/disabled in the current context (in which case any following execution of panels will be synchronous no matter how it was configured in the first place for example).
  • a set of methods to help register a set of entities and components which should lead to cache invalidation if they are modified, for the current asynchronous execution.
  • a way to register some custom resources to remember. Their cached results will be reinjected later (for example it's used to remember the skin extensions required by a cached element). One can then implement org.xwiki.rendering.asyncAsyncContextHandler to restore them when using the cached content.

New document type in XAR extensions

It's now possible to indicate a type for each entry in a XAR extension. The type indicates what actions are allowed for a document once it's installed (edit, delete) and how it should be handled during upgrade (merge, skip, overwrite, etc.). See XAR package format for more details about this new property.

New Page API

10.6 brings the Page concept which was introduced in 7.4 to the API and the macros.

PAGE EntityType and Page*Reference classes

First thing first we now have a few new types in EntityType and the corresponding typed Page*Reference helpers. One for each of the element you can have in a page:

  • PAGE

Corresponding resolvers/serializer/providers

Each of the already existing DOCUMENT oriented resolvers and serializers have their PAGE oriented implementation.

Conversion from DOCUMENT to PAGE world

The entity resolvers automatically convert from/to DOCUMENT from/to PAGE world references. So yes, using a resolver is the official way to do that conversion.

New syntax

Pages reference have a very different syntax.

To summarize it's a filesystem path syntax with support for parameters.

Here is are a few examples:



  • separator: "/" between all elements except WIKI which is still ":"
  • escaping: still "\"
  • current, parent support: like in a file system you can refer to the current page or parent page/wiki using "." and ".."
  • parameters: we now have syntax to express the parameters of an EntityReference. Each parameter is separated by a ";" at the end of the entity name
  • default parameter: the syntax have the concept of default parameter which mean a parameter for which you don't need to indicate the name. For example PAGE reference default parameter is "locale"

New resource reference

A new resource reference of type PAGE has been added and can be used in links for example:



  • the $services.model API also got his own new helpers to manipulate pages
  • support for page references have been added to various oldcore (XWiki/XWikiDocument/Document) and bridge (DocumentAccessBridge) APIs
  • support for page references have been added to the security module

No more unset xobject property

Missing properties in an xobject (compared to the xclass) are now automatically added (with a null value most of the time) during save or when adding a new field in a class. Among other things it means you can now use fields in a database query without wondering if the field exist or not, no more missing result because the property is not set in some object yet.

Page picker velocity macro

You can now use a #pagePicker($parameters) velocity macro (works like #userPicker) to display an input auto-suggesting pages. Pages are searched by full name (e.g. Sandbox.Page) and title (depending on the locale of the user).

Detailed Release Notes

If you wish to see the full details of all features and improvements you can check each release note.

Check the highlight and summary of the XWiki 10.x cycle.

Version 10.x.x

Version 10.9.x

Version 10.8.x

Version 10.7.x

Version 10.6.x

Version 10.5.x

Version 10.4.x

Version 10.3.x

Version 10.2.x

Version 10.11.x

Version 10.10.x

Version 10.0.x

Get Connected