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.

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

Here are the top 10 features that we wish to mention (arbitrarily hand-picked; it's hard to pick 10 out of 307 improvements and new features):

  1. Flavors
  2. New default Color Theme
  3. Page fields now support auto-suggestion
  4. Inline Macro Content Editing
  5. Link Autocomplete in WYSIWYG Editor
  6. New CAPTCHA API and CAPTCHA implementations
  7. Improved performances
  8. New Notifications Macro
  9. Notifications fully replace the Watchlist
  10. Activity Stream is not bundled anymore
  11. Auto-suggest for pages
  12. Removed misleading shortcut
  13. Minor changes do not generate notifications anymore
  14. Rename/Move protection
  15. Hiding notifications that are read
  16. The name of the wiki is now displayed in the notifications
  17. Figure Macro
  18. Delete all from the recycle bin
  19. Auto-suggestion of pages
  20. Navigation Panel Configuration
  21. Notification Filter Preferences that concern hidden pages are not listed anymore
  22. Macro Content Prefill in WYSIWYG Editor
  23. User membership in the profile
  24. The Notifications Macro now includes a RSS view
  25. Updated the comments modals
  26. The notifications macro can now handle tags
  27. Compact User Picker
  28. All filters preferences are displayed in the same livetable
  29. The "network" tab is back in the user profile
  30. Auto Notifications on changes
  31. New Page picker in the App Within Minutes field palette
  32. Edit protection
  33. Followed users in the user profile
  34. Visible Save
  35. Prevent users from deleting/moving/renaming pages containing used XClass
  36. Improved Multi-Term Search Relevancy
  37. XAR entry types improvements
  38. Filesystem store by default
  39. Filesystem store improvements has changed format
  40. Improved Users Administration Section
  41. Larger attachments by default
  42. Improved Groups Administration Section
  43. Default Notifications
  44. External URL generation improvements
  45. Notifications Auto Watch is now disabled by default
  46. Improved Navigation Panel Administration
  47. XWiki on WildFly
  48. Notifications Filters Store
  49. Ability to set the default auto watch mode in the administration
  50. New document type in XAR extensions
  51. New Page API
  52. No more unset xobject property
  53. New asynchronous rendering framework
  54. Page picker velocity macro
  55. Improvement of the icon API
  56. Context save/restore
  57. Default empty choice for list properties
  58. Document Tree Exclusions
  59. Date Script Services
  60. The identity of the current user is now available in javascript
  61. Use RequestFactory to create a request from the refactoring script service
  62. Group manager
  63. REST API now supports the use of minor revision for page changes
  64. Create a job to delete all from the recycle bin
  65. Jobs improvements
  66. Priority between Notification Filters
  67. After document header extension point
  68. New XAR entry types
  69. User Picker Velocity Macro Changes
  70. Allow wiki macros to indicate the type of parameters
  71. Translation fallback
  72. Macro content can be declared to be inline editable
  73. Version 10.x.x
  74. Version 10.9.x
  75. Version 10.8.x
  76. Version 10.7.x
  77. Version 10.6.x
  78. Version 10.5.x
  79. Version 10.4.x
  80. Version 10.3.x
  81. Version 10.2.x
  82. Version 10.11.x
  83. Version 10.10.x
  84. Version 10.0.x

Flavors

We switched from the old "XWiki Enterprise" package and we now provide the "XWiki Standard" flavor. When creating a new wiki, Administrators can choose which flavor they want.

In XWiki, a flavor is simply a bundle of extensions that serve a particular usage. We expect in the future that the community members will provide additional flavors built on top of XWiki. Imagine a flavor for application development, one for documentation, one for procedures or even a flavor created especially for your team. Using flavors you can customize your XWiki to the smallest details.

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

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. 

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.

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.

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

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

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.


Removed misleading shortcut

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

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.

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.

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.

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

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.

Auto-suggestion of pages

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

  • Administration Descriptor section
  • Template Provider Sheet

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.

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.

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 now includes a RSS view

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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. 

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.

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

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.

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

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

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.

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.

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.

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.

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.

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.

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


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.

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.

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.

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.

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.

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
});

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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