Release Notes for XWiki 8.0 Milestone 1

Version 51.10 by Eduard Moraru on 2016/02/09

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.

This is the first milestone release of the 8.x cycle. With this occasion we deprecated and retired multiple projects like Colibri Skin, Color Themes, old XWiki 1.0 syntax, etc. We also continued to polish our Nested Pages feature introduced in 7.2, by adding improvements such as: asynchronous copy and rename page actions, improved location picker for simple users and the ability to omit "WebHome" in wiki links syntax.

New and Noteworthy (since XWiki 7.4)

Full list of issues fixed and Dashboard for 8.0.

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.

copyProgress.png

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.

renameStatus.png

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.

simpleLocationPickerValidation.png

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 an existing 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]).

More details and examples can be found in the XWiki link syntax documentation page on your XWiki instance.

Relative links to sibling Nested Pages

To better support backwards compatibility with the pre-Nested-Pages behavior when the current document is a non-terminal document and an untyped relative link (e.g [[Page]]) has not been resolved using the above mentioned algorithm (i.e. as a terminal or non-terminal child of the current page), we perform 2 additional checks:

  • we try to link to an existing terminal page that is a sibling of the current page (i.e. [[Page]] is resolved to the equivalent of [[doc:currentPageParent.Page]])
  • if no such terminal page exists, then link to the non-terminal page that is a sibling of the current page (i.e. [[Page]] is resolved to the equivalent of [[doc:currentPageParent.Page.WebHome]]) for both when the non-terminal page exists or when it does not (and should be a wanted link)

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.

ColorThemeDisplayer.png

Disable header and footer in PDF export

It's now possible to disabled the display of header and footer (usually the page name and date) when exporting a PDF.

pdfExportOptions.png

Miscellaneous

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.

New SVG Rasterizing API

New API to convert a vector-based SVG content into some binary format that can be displayed in browser (i.e. rasterizing).

Deprecated and Retired projects

Upgrades

The following dependencies have been upgraded:

Miscellaneous

  • 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. See the upgrade instructions
  • 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.

  • Replaced a few String-based APIs by Locale-based equivalents
  • All Document Events are now Cancelable and it's now possible for an EventListener implementation to cancel saving a Document.

Translations

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.

Known issues

Backward Compatibility and Migration Notes

General Notes

When upgrading make sure you compare your xwiki.cfg, xwiki.properties and web.xml files with the newest version since some configuration parameters may have been modified or added. Note that you should add xwiki.store.migration=1 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 and is not bundled by default anymore.
    • If you were using this feature, you should check the Instructions to install it manually.
    • If you were not using it, you should make sure to edit your web.xml to remove all the Servlet and Filter definitions for WebDAV (search for dav in web.xml).
  • If you have custom Velocity 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. Otherwise your custom configuration will be ignored!

Mail API Unique Message Identifier

In order to solve XWIKI-12165, the unique identifier of each mime message sent has been changed 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.

We've introduced the possibility to explicitly create a link to a Space in XWiki Syntax 2.1, e.g. [[space:Space1.Space2]]. However if you had a subwiki named space the new notation will conflict with the syntax for referencing that wiki. Thus you'll need to edit existing links such as [[space:something]] to [[doc:space:something]]. And if you wish to reference a given space in the space subwiki, you'd write [[space:space:something]].

API Breakages

The following APIs were modified since XWiki 7.4:

<clirr output here>
Tags:
   

Get Connected