Summary of the XWiki 10.x Cycle

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. 

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..

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 xwiki.properties:

  #-# 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
  # extension.xar.protection=warning
• 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.

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
• PAGE_ATTACHMENT
• PAGE_OBJECT
• PAGE_OBJECT_PROPERTY
• PAGE_CLASS_PROPERTY

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:

Miscellaneous

• 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).