Release Notes for XWiki 8.0 Milestone 1

Version 39.1 by Thomas Mortagne on 2016/02/03

This is the release notes for XWiki Commons, XWiki Rendering, XWiki Platform and XWiki Enterprise. They share the same release notes as they are released together and have the same version.

<insert description of release here>

New and Noteworthy (since XWiki 7.4)

Full list of issues fixed and Dashboard for 8.0-milestone-1.

<feature N>

<description of feature N>

Asynchronous Copy and Rename Page

The copy and rename page operations are now performed asynchronously, in a background thread, when triggered from the UI. Clicking on the Copy/Rename button takes you to a status page where you can see the options that have been selected and the progress of the operation. The advanced users have access to the operation log.


The progress bar is replaced with the operation status at the end in order to let you know if the operation succeeded or failed. You can use the breadcrumbs to navigate to the new page or the old one.


See the Page Lifecycle documentation for more information.

Improved Location Picker

The location picker used on the Create, Copy and Rename page UI is now hiding the advanced edit fields (wiki, parent and name) for simple users. Simple users will have to use the tree picker to select the target location. As a consequence the form validation is now performed on the fields that are visible to the current user.


Link syntax improvements for Nested Pages

With the addition of Nested Pages, a discrepancy appeared between the UI and the wiki syntax. The UI always talks about (nested) pages and never about spaces, but in the wiki syntax you would still have to specify both the space and the name of a page when linking to it (e.g. writing [[Some.Nested.Page.WebHome]] if you want to create a link to the nested page Some.Nested.Page). The same applies to image: or attach: syntax. The technical reason for this was that, at the wiki syntax level, untyped links were always being resolved to doc: type links.

To improve this, we have added a new space: type link which allows you to simply write [[space:Some.Nested.Page]] and have made this the new default type that untyped links resolve to.

The outcome is that you can now simply type [[Some.Nested.Page]] and you will create a link to the nested page Some.Nested.Page.

For backwards compatibility with the existing untyped links, we have implemented the same mechanism we have applied for URLs, which is to:

  • first try to link to a terminal page (i.e. if Some.Nested.Page is actually a terminal page inside the Some.Nested space; this was the previous default behavior)
  • if no such terminal page exists, then link to the non-terminal page (i.e. Some.Nested.Page.WebHome) for both when the non-terminal page exists or when it does not (and should be a wanted link)

The same thing applies for image: (e.g. image:[email protected] translates technically to image:[email protected]) and for attach: syntax (e.g. attach:[email protected] translates technically to attach:[email protected]).

Color Theme Displayer

In the administration, an error message is displayed if the configured color theme is invalid. It could happen after an upgrade if you were using an old Colibri Theme.



See the full list of JIRA issues fixed in this release.

For Developers

Extension Manager improvements

Feature version

Each extension feature now have its own version. See Extension Module Virtual Extensions for more details.

Namespace constraint

It's now possible to indicate a constraint on where an extension can be installed (only root namespace, etc.).

In Maven you can do that using <xwiki.extension.namespaces> custom property. See Maven Connector for more details.

Compare Extensions

org.xwiki.extension.Extension and org.xwiki.extension.ExtensionId now implement  Comparable to make easier manipulate them (order lists, find out if we are doing an upgrade or a downgrade, etc.).

Edit Action Events

Two new JavaScript events are available in edit mode:

  • xwiki:actions:beforePreview
    This event is fired after the user clicks on the "Preview" button from an edit mode, but before the edit form is validated. You can use this event to update the form fields before they are submitted to the preview action.
  • xwiki:actions:beforeSave
    This event is fired after the user clicks on the "Save" or "Save & Continue" button from an edit mode, but before the edit form is validated. You can use this event to update the form fields before they are submitted to the save action.

See the JavaScript API documentation for more information.

Deprecated and Retired projects


The following dependencies have been upgraded:


  • Replaced a few String based APIs by Locale based equivalent
  • Generated URLs for document-based skin extensions (SSX and JSX) now contain the version of the document, so when a change is made to the extension the browser don't use an outdated version from its cache.
  • Support for chaining uberspectors, first introduced in XWiki as an enhancement of Velocity 1.5, has been part of the official library since Velocity 1.6. As such, we're deprecating our custom classes that provide this functionality. If you have custom uberspectors that implement org.xwiki.velocity.introspection.ChainableUberspector or extend org.xwiki.velocity.introspection.AbstractChainableUberspector, update them to org.apache.velocity.util.introspection.ChainableUberspector and org.apache.velocity.util.introspection.AbstractChainableUberspector. If you have a custom list of uberspectors specified under runtime.introspector.uberspect.chainClasses, just use the runtime.introspector.uberspect property for defining the list.
  • the XWiki Select Widget now offers a javascript API in the form of a jQuery plugin, to get the current value or clear the selection.
  • the WYSIWYG editor script service has a new method to render a document as a full HTML page. You can use it like this:

    <textarea class="wysiwyg">$escapetool.xml($services.wysiwyg.render('Some.Content.Template'))</textarea>
    The main difference between this API and the existing $doc.getRenderedContent() is that it replaces the skin extension hooks with the corresponding resource includes (e.g. style sheets includes), allowing us to define a WYSIWYG editor content template in a wiki page.


The following translations have been updated: 

Tested Browsers & Databases

The QA Tests are executed after the release has been done. Thus, they are being prepared now and will be published soon.

Performances tests compared to <last super stable version>

<a summary of the comparison with latest super stable version>

More details on <link to the test report>.

Known issues

Backward Compatibility and Migration Notes

General Notes

When upgrading make sure you compare your xwiki.cfg, and web.xml files with the newest version since some configuration parameters may have been modified or added. Note that you should add so that XWiki will attempt to automatically migrate your current database to the new schema. Make sure you backup your Database before doing anything.

Issues specific to XWiki 8.0 Milestone 1

  • The WebDAV feature is now configured using Servlet 3.0 annotations. Make sure you deploy XWiki in a Servlet Container that is configured to discover Servlet 3.0 annotations (at least for the XWiki xwiki-platform-webdav-server-*.jar JAR). If you're upgrading also make sure you edit your web.xml to remove all the Servlet and Filter definitions for WebDAV (search for dav in web.xml).
  • With the improvement done in the wiki links, image: and attach: syntax, existing untyped links pointing to inexistent documents (e.g. [[Doc]]) will no longer be resolved to point to a new terminal document in the same space (i.e. <currentSpace>.Doc, when <currentSpace>.Doc does not exist), but will be resolved to point to a new non-terminal document in the top level (i.e. Doc.WebHome). The reason is because we don`t currently have a way to specify a relative link to a nested document (i.e. space) and we only use absolute links. This only affects wanted links, since for existing documents the backwards compatibility mechanism preserves the previous behavior.
  • Mail API Unique Message Identifier (since 7.4.1): In order to solve XWIKI-12165, the unique identifier of each mime message sent has been change to a SHA1 based on the Message-ID header and the list of recipients of the mails, ensuring uniqueness during a newsletter or mailing sending. To introduce this change, the MailContentStore and the MailListener API has been broken, and now use a new ExtendedMimeMessage instead of the simple MimeMessage for all arguments. The values messageId returned or used as argument in the API is no more equivalent to the Message-ID header, but is now the unique identifier returned by ExtendedMimeMessage#getUniqueMessageId(). Finally, the MessageMimeMessageFactory now returns cloned MimeMessage without changing the Message-ID.

API Breakages

The following APIs were modified since XWiki 7.4:

<clirr output here>

Get Connected