Summary of the XWiki 10.x Cycle

Version 7.61 by Ecaterina Moraru (Valica) on 2018/12/21
Warning: For security reasons, the document is displayed in restricted mode as it is not the current version. There may be differences and errors due to this.
  • 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
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.

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:

    jira-issue-types-10x.png

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

    jira-assignees-10x.png

Congrats to all who participated!

Top 10 Features

We've handled diverse 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. Administrate navigation
  3. Refactoring operations protection
  4. Editor Improvements
  5. Auto-suggest for pages
  6. Users sections improved
  7. Notifications
  8. Under the hood
  9. New community extensions
  10. XWiki 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 and feel. Our community voted for blue as our main color, replacing the black color we had in the past.

Iceberg_XS.png

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.

visiblesave.gif

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.

Administrate navigation

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.

navigationPanelConfig.png
admin-menu.png

Refactoring operations protection

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.

menu_rename_simpleuser.png
menu_rename_advanceduser.png
editprotection.png

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.

ckeditor-macro-prefill.png

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.

autocomplete-page.gif
page-picker.pngadmin-search-suggest.png
awm-page.gif

Users sections improved

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.

userPicker-createWiki.png
userPicker-sharePage.png
usersAndGroupsCompactPicker.png
groups.png
adminSubWikiGroups.png

Notifications

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.

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

Results.png

Under the hood

It' 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. Untill 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 to 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 or use the default JCaptcha that provides image, sound and text CAPTCHA formats.

captcha-jcaptcha-options.png
captcha-recaptcha.png

standard.png

New macros

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

image-example.png
example.png
kanban3.png
orgchart2.png
standard.png

XWiki Store

XWiki's Extension Manager is now connected to the XWiki Store and will list the professional extensions.

standard.png

Top User Features

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

Notifications.png

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.

async-panels.png

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.

Iceberg_XS.png

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. 

NotificationsMacro.png
NotificationsMacroInCKEditor.png

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

autocomplete-page.gif

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.

captcha-defaultCaptchaSelection.png
captcha-jcaptcha-options.png
captcha-recaptcha.png
comments-captcha-jcaptcha.png
comments-captcha-recaptcha.png
registration-captcha-jcaptcha.png
registration-captcha-recaptcha.png

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.

page-picker.png
user-picker.png
admin-search-suggest.png
admin-theme-suggest.png

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.

NotificationsMacro.png

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

awm-page.gif

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.

NotificationsWithRSS.png

The Notifications Macro now includes a RSS view

userPicker-view.png
usersAndGroupsCompactPicker.png
userPicker-groupSheet.png
userPicker-awm.png
userPicker-createWiki.png
userPicker-wikiOwner.png
userPicker-wikiUsers.png
userPicker-messageSender.png
userPicker-solrFacet.png
userPicker-sharePage.png

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.

permalinkModal.png
deleteModal.png

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.

ckeditor-macro-prefill.png

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.

groups.png

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.

FollowedUsers.png

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.

Results.png

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.

FiltersLivetable.png

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.

NotificationReadFilter.png

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.

menu_rename_simpleuser.png
menu_rename_cancelled.png
menu_rename_advanceduser.png

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. 

page-picker-01.png
page-picker-02.png

Auto-suggestion of pages

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

  • Administration Descriptor section
  • Template Provider Sheet

clean-recycle-bin.gif

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.

FilterMinorEvent.png

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.

renameextension.png

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.

image-example.png

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

editprotection.png

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

AutoWatch.png

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.

NetWorkTab.png

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.

navigationPanelConfig.png

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.

visiblesave.gif

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:

protections.png

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.

Filesystem store improvements has changed format

Support for case insensitive filesystems has been added in the filesystem store. Among other things it means that most of the existing paths need to be modified (upper case characters are now escaped). There is an automatic migration for it but be careful if you are using some custom tool manipulating directly the store files (since the format has changed).

NotificationsAdministration.png

Default Notifications

In the global settings, administrators can select which applications and/or event types should be enabled by default for all users. The user can then override the default settings, but if he/she doesn't set anything, the preferences of the wiki where he/she belongs to are applied.

The inheritance is "Main Wiki preferences < Current Wiki preferences < User preferences".

navigationPanelConfig.png

Improved Navigation Panel Administration

The Navigation Panel administration section has been improved with support for drag & drop. You can now drag pages from the navigation tree to exclude them and back to the tree to include them. See the Navigation Panel documentation for more information.

AutoWatchModeAdmin.png
AutoWatchModeConfig.png

Ability to set the default auto watch mode in the administration

It is now possible, for administrators, to set the default auto watch page behavior.

port.png

External URL generation improvements

It's now possible to set the port to use when generating an URL for a wiki in the each wiki descriptor. When the port is not set for a wiki, XWiki fallback on the main wiki descriptor.

Subwiki secure property (which indicate if HTTPS should be used instead of HTTP when generating a URL for the wiki) now inherit main wiki value if not explicitly set.

The first time XWiki is accessed the main wiki descriptor is generated using what can be found in the request's URL. For example if you access your wiki using https:mydomain:9898/xwiki/ you will end up with the following main wiki descriptor:

  • alias: mydomain
  • secure: true
  • port: 9898

Also XWiki now supports the Forwarded (RFC7239) standard HTTP header when extracting information from the URL used by the client.

Notifications Auto Watch is now disabled by default

An important bug has been discovered in the Notification Applications that prevents using the Auto Watch feature when the wiki contains a lot of pages. For this reason, the default behavior for the Auto Watch feature has been set to not automatically follow any page. Nevertheless, users and administrators can still decide to change their own settings.

XWiki on WildFly

XWiki now deploys fine out of the box on WildFly 14.x.

Notifications Filters Store

Due to scaling issue, we have changed the way the notification filter preferences are stored in the wiki. They are not saved in the user profile pages anymore, but in their own database table.

A migration to the new store is necessary for existing filter preferences. It is done automatically when you first start XWiki after upgrading, but it may take time.

Thanks to this improvement, we have re-enabled the default behavior for the Auto Watch feature so that users automatically watch pages they have contributed to.

adminUsers.png
adminSubWikiUsers.png
adminCreateUser.png
adminEditUser.png
adminDeleteUser.png

Improved Users Administration Section

The Users section from the Wiki Administration has been improved:

  • Shows the user avatar
  • Shows the user scope (Global vs. Local) when you are on a subwiki
  • Has nicer modal popups for creating, editing and deleting the users

Larger attachments by default

Till now the default limit for attachments was set at 32MB. It's now been increased to 100GB.

adminGroups.png
adminSubWikiGroups.png
adminCreateGroup.png
adminCreateGroupKO.png
adminCreateGroupOK.png
adminEditGroup.png
adminDeleteGroup.png

Improved Groups Administration Section

The Groups section from the Wiki Administration has been improved:

  • Shows the group avatar
  • Shows the member type (User vs. Group) when listing the members of a group
  • Shows the group scope (Global vs. Local) when you are on a subwiki
  • Has nicer modal popups for creating, editing and deleting the groups

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

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

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

Context save/restore

New tools have been introduced to help save and restore contextual information. It's useful for example when transferring contextual information from one thread to another to execute asynchronous tasks. This is done trough org.xwiki.context.concurrent.ContextStoreManager.

It's possible to add support for more contextual information by implementing org.xwiki.context.concurrent.ContextStore components. See documentation for more details.

On Jobs side a new context property have been added to the org.xwiki.job.Request to automatically restored passed context data before executing the job.

Create a job to delete all from the recycle bin

It is now possible to create a job for permanently delete elements from the recycle bin. It is supported in the Refactoring Script Service as explained in its documentation.

Allow wiki macros to indicate the type of parameters

You can now specify the Java type of a wiki macro parameter. It used to not be possible and all wiki macro parameters were Strings.

Macro content can be declared to be inline editable

Some part of the macro content can be declared as inline editable: the user will then be able to edit those parts of the content directly in the wysiwyg editor.

In order to make this available you need to specify 2 information when declaring the macro:

  1. the type of the macro content
  2. the parts of the macro that can be editable inline

Specify the type of the macro content

 

You need to specify it in the constructor of the DefaultContentDescriptor: 

public DefaultContentDescriptor(String description, boolean mandatory, Type type)

The type of a content which can be editable inline, is List<Block>.
In order to simplify its declaration, we created a constant that can be immediately used:

new DefaultContentDescriptor("Content of the message", true, Block.LIST_BLOCK_TYPE));

Specify the parts of the macro that can be editable inline

When declaring the result of the macro by overridding execute method, you can specify which parts of the macro will be editable inline, by specifying some metadata.

For example, if you want to declare a block containing a logo which is always the same and a block which will be editable inline you can specify it like that:

ResourceReference imageReference = // declare the reference to the image logo
Block logoBlock = new ImageBlock(imageReference, true);
List<Block> content = this.contentParser.parse(content, context, false, context.isInline()).getChildren(); // parse the existing content and get its children blocks
Block editableContent = new MetadataBlock(content, this.getNonGeneratedContentMetadata()); // specify the right metadata in order to make the content editable inline
return Arrays.asList(logoBlock, editableContent);

The obtained result for the rendering will look like:

<!--startmacro:myMacro|-||-|content-->
<span id="logo"><img src="mylogo.png" /></span>
<div data-xwiki-non-generated-content="java.util.List&lt; org.xwiki.rendering.block.Block &gt;" class="xwiki-metadata-container">
    <p>my editable content</p>
</div>
<!--stopmacro-->

The syntax used inside the editable part can be declared by using a syntax metadata. 

Consider that nested macro will be editable inline, only if they also declare an editable content. On the same idea, if a nested macro declare an editable content, it can be used only if the parent macro also declare an editable content.

Please note that between 10.10RC1 and 10.10 the metadata changed its name.
So with 10.10RC1, in the above snippets you should replace the method getNonGeneratedContentMetadata by getUnchangedContentMetadata, and the html attribute data-xwiki-non-generated-content by data-xwiki-unchanged-content.

Use RequestFactory to create a request from the refactoring script service

The refactoring script service has been refactored: you need to access the new RequestFactory in order to create any kind of request.
For example a script using :

#set ($renameRequest = $services.refactoring.createRenameRequest($source, 'NewName')) 

should now use: 

#set ($renameRequest = $services.refactoring.requestFactory.createRenameRequest($source, 'NewName')) 

All the API related to refactoring operations themselves remains at the same place. See the Refactoring Module Documentation for all information.

REST API now supports the use of minor revision for page changes

Add ?minorRevision=true to your REST calls and the page will be updated with minor revision. See the whole documentation for the REST API.

Jobs improvements

  • A framework has been introduced to make easier to write jobs UI with question/answer support. You can see more details in the Job Module documentation.
  • AbstractJobStatus now implement CancellableJobStatus interface which allow generic code to control jobs that can be canceled
  • it's now possible to get the time left before a job question timeout using newJobStatus#getQuestionTimeLeft method

Translation fallback

It's now possible to pass a list of keys to test one by one until one is found. See Scripting for more details.

Priority between Notification Filters

Notifications Filter has now a getPriority() method, to handle advanced use-cases when a filter needs to have priority over some others.

Document Tree Exclusions

The Document Tree macro has a new parameter named "exclusions" that allows you to exclude a list of nodes from the tree. For instance, in order to exclude the "XWiki" top level node you can use:

{{documentTree exclusions="document:xwiki:XWiki.WebHome" /}}

Check the documentation for more information.

The identity of the current user is now available in javascript

JavaScript developers can now get the reference of the current user thanks to the xwiki-meta module that you can use like this:

require(['xwiki-meta'], function (xm) {
  console.log('Hello: ' + XWiki.Model.serialize(xm.userReference));
 // Will display "Hello xwiki:XWiki.Admin" in the console
});

after-content-header.jpg

After document header extension point

It is now possible to inject some content after the document header, that is below the title / update info / actions block, by implementing the org.xwiki.platform.content.header.after UI Extension Point.

New XAR entry types

The following new XAR entry types have been added:

  • customizable

Date Script Services

A new script service called $services.date is now available. It currently implements the "time ago" displays (such as "12 minutes ago") and it support a lot of locales. See: Date Script Service.

Improvement of the icon API

It is now possible to manually pull icon theme resources and get a metadata map of an icon to customize the display.

See the Icon Theme Application extension for documentation.

User Picker Velocity Macro Changes

The #userPicker Velocity macro has been modified to have a compact display. There is no toggle to switch between local and global suggestions as the picker retrieves suggestions from both the current wiki and the main wiki depending on the current wiki's user scope. You can overwrite this if you want using the data-userScope parameter.

#set ($userPickerParameters = {
  'id': 'wikiOwner',
  'name': 'owner',
  'value': $descriptor.ownerId,
  'data-userScope': 'GLOBAL_ONLY'
})
#set ($multipleSelection = false)
#userPicker($multipleSelection $userPickerParameters)

The JavaScript library used to fetch the suggestions and to display them has been replaced, causing modifications to the HTML structure of the user picker. This means that you may have to update your code in case you did customizations on top of the old library. The new library we use is selectize.js.

Group manager

A new org.xwiki.user.group.GroupManager and corresponding services.user.group script service are now available.

See more details on User Module.

Default empty choice for list properties

In the default list property editor an empty choice (generally displayed as "---" but it can be translated) is now always added for non multi select based editing. This avoid hacks like the "---" value which used to be used in various XWikiPreferences properties choices.

Detailed Release Notes

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

Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [xwiki:ReleaseNotes.Code.ReleaseNotesArchiveMacro.WebHome]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.

Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [xwiki:ReleaseNotes.ReleaseNotesXWiki10x.WebHome]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.

Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [xwiki:ReleaseNotes.ReleaseNotesXWiki10x.WebHome]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.

About

About

Support

Platform

User Guide

Admin Guide

Developer Guide

Projects

XWiki

Extensions

Other

Contribute

Status

Practices

Under the Hood

Get Involved

Get Connected