Draft

Contents

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.

The biggest highlight of this cycle is ...

  • User and Page pickers
    • User groups in profile
  • CKEditor:
    • Inline Macro Editing, 
    • Link autocomplete
    • Macro Content Prefill
  • Edit protection, Rename/Move protection, Prevent users from deleting/moving/renaming pages containing used XClass
  • Notifications: AS retired, 
  • CAPTCHA
  • New Default Color
  • Usability:
    • Visible Save
    • Navigation Panel Configuration
  • Filesystem store by default

Work Done

The work is organised using JIRA and here are some JIRA stats of what happened during the 10.x cycle:

  • x issues were closed (See the full JIRA issue list)
  • x bugs closed, x improvements, x new features and more:

    jira-issue-types-10x.png

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

    jira-assignees-10x.png

Congrats to all who participated!

Top User Features

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

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

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.

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. 

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.

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

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.

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.

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.

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.

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 Page picker in the App Within Minutes field palette

A Page picker has been integrated in the App Within Minutes and works like the User picker.

The Notifications Macro now includes a RSS view

Compact User Picker

The List of Users and List of Groups class properties have a new compact display that shows in view mode the user / group avatar followed by the user / group name. In edit mode the selected users / groups are shown in-line. Suggestions are retrieved from both the current wiki and the main wiki, depending on the current wiki's user scope (there's no toggle to switch between local and global users anymore). See the Data Model documentation for more information. This is the same user picker that has been already integrated in the Live Table user filter.

The compact user picker has been integrated in other places such as Administration, App Within Minutes, Wiki Application, Message Sender, Solr Search user facet and Share Page.

Updated the comments modals

The comments pop-ups that are displayed for deleting a comment and for permalink are now bootstrap modals, having the same functionality as before.

Removed misleading shortcut

Removed the META+V shortcut used in the jump dialog as it was preventing users from pasting.

Macro Content Prefill in WYSIWYG Editor

When inserting a macro, the macro content text area is prefilled with the text selected within the editing area. This means you can for instance transform a paragraph into an error message by selecting the paragraph text, click the Insert Macro button from the tool bar, select the Error Message macro and insert it. Checkout the CKEditor Integration documentation for more information.

User membership in the profile

It's now possible to see the groups a user is member of in the profile. See User Profile Application.

The notifications macro can now handle tags

The "tags" parameters can be used to filter events that concern pages marked with some given tags. In a multi-wikis environment, it works only on the current wiki.

Followed users in the user profile

A user can now see again (it was temporarily removed in past version while we migrated from WatchList to Notifications) the list of the users she is watching in the "network" panel of her user profile.

The name of the wiki is now displayed in the notifications

When a notification concerns a page that is not in the current wiki, the name of the wiki is now displayed in the notification.

All filters preferences are displayed in the same livetable

The "advanced filtering options" window has disappeared, and all filters are displayed in the same place.

Improved Multi-Term Search Relevancy

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

For those interested in the more technical aspects:

  • The query string is split into groups of multi-term contiguous sequences (word shingles), ignoring stopwords where appropriate.
  • The higher the number of terms in close proximity the more relevant the document will appear.
  • While the order of the terms in the query string is important for forming word shingles, the order in which the terms appear in the document doesn’t affect the score.
  • Stemming is still used so that all forms of each word are considered matches even in multi-term relevancy calculations.
  • Exact matches are still returned when terms are encased in quotes.

Hiding notifications that are read

Since the introduction of the Notifications Application in XWiki, it was possible to mark some notifications as "read". They were displayed differently, and not counted in the red circle above the bell, but they were still there.

Now, it is possible to decide not to show them anymore thanks to an option in the user's notification settings.

Notification Filter Preferences that concern hidden pages are not listed anymore

Filters that concern hidden pages are not shown in the table, unless you enabled the option to see hidden pages. More informations: Hidden (technical) pages.

Prevent users from deleting/moving/renaming pages containing used XClass

Users are now warned when they make refactoring operations (delete, move or rename) in pages that contain used XClass. Simple users are forbidden to realize those operations, whereas advanced users get an UI to allow them selecting the pages to refactor. 

Auto-suggestion of pages

The auto-suggestion of pages feature has been implemented in new places:

  • Administration Descriptor section
  • Template Provider Sheet

Delete all from the recycle bin

It is now possible to permanently delete all pages that have been already deleted, in order to clean the recycle bin. See Index Application Documentation.

Minor changes do not generate notifications anymore

A new filter has been created, to hide events about minor changes. This filter can be disabled, but is enabled by default.

Rename/Move protection

As with the delete action, if you try to rename a page that belongs to an installed extension you will now get a warning suggesting you to uninstall the extension instead and asking you to explicitly select the standard pages you want to rename.

Note that the displayed message text is currently the same one as for delete but that will be fixed in the next version.

Figure Macro

A new Figure Macro was created to be able to add illustrations (images, tables, code, graphs, etc) along with optional captions.

Example:

...
{{figure}}
[[image:macaque.jpg||alt="Macaque in the trees"]]

{{figureCaption}}A cheeky macaque, Lower Kintaganban River, Borneo. Original by [[Richard Clark>>http://www.flickr.com/photos/rclark/]]{{/figureCaption}}
{{/figure}}
...

Edit protection

As with delete and rename operations, if a user tries to modify a page belonging to an Extension, a warning will be displayed to explain that it's very risky and it should be avoided.

10.4 will introduce configuration that helps the user have more control on this behavior (disable edit completely without even a warning, allow a user to hide this warning, etc.).

Auto Notifications on changes

Thanks to an improvement to the AutoWatch feature of the notifications, users now get notified on changes done to pages they previously edited.

The "network" tab is back in the user profile

The "network" tab disappeared in XWiki 10.3 for technical reasons. Thanks to the new Notifications Macro, it comes back in XWiki 10.4. It's also better than before since it now allows dismissing events.

The goal of this tab is to display all the events performed by the users you are following.

Navigation Panel Configuration

The top level application pages are now excluded by default from the Navigation Panel. You can still access the corresponding applications from the Applications Panel. This allows the Navigation Panel to focus more on your own content pages. However, you can disable this filter (if you wish to see all the pages) or configure other page excludes from the Wiki Administration.

Visible Save

The save buttons bar is now always visible which makes it simpler to see the buttons, even for long pages (some users used to not find the buttons).

Top Admin Features

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

Filesystem store by default

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

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

Top Developer Features

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

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.

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.

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.

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

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:

wiki:page1/page2;param1=value1;param2=value2;en_US

wiki:page1/page2/attachment

../siblingpage
  • 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:

[[parent>>page:..]]
[[page:page1/page2]]

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

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

Tags:
   

Get Connected