Second milestone of the XWiki Enterprise 2.5 version (Roadmap).

The highlights of this release are: support for viewing attached office documents in the wiki, an experimental Extension Manager, experimental CSRF protection, a new User Directory, further improvements to the edit UI, more consistent use of user avatars, support for activating a special accessibility stylesheet, and an experimental xwiki/2.1 wiki syntax.

New and Noteworthy (since XWiki Enterprise 2.4)

Support for viewing attached office documents in the wiki

XWiki now supports viewing attached office documents without saving them on the client side.

We also included a new Macro for the WYSIWYG Editor. It allows to embed a office file into a page.

Experimental Extension Manager

The new Extension Manager will allow you to install new extensions to your XWiki XE. Please note that this is an experimental feature. Use it at your own risk.

New User Directory

Added User Directory section on the Quick Links tab on the left of the page. This will show you the users that the XWiki instance has, along with their avatar image. This page also allows to filter users by username.

Further improvements to the edit UI

After the improvements to the object and class editors introduced in 1.8 and 2.4, the wiki and WYSIWYG editors also see some enhancements in this release, bringing in some of the proposed changes from an older proposal, with some additional improvements. Specifically:

• A new label for the content area in the wiki editor:

  

• A more descriptive label for the version summary field
• Better positioning of the "minor edit" option
• Better positioning and display of the "autosave" option

  

More consistent use of user avatars

As proposed on the design page, avatars come in three default sizes:

• small avatars, 30px wide, used in secondary actions and where there's very little space available
• medium avatars, 50px wide, the preferred and most frequent display option for avatars
• large avatars,120px wide, to be used where a large version of the avatar must be displayed (for example in the user profile)

Accordingly, the wiki dashboard has been changed to use the medium avatars, and as a new feature user avatars are displayed in the comments area.

Four new velocity macros have been added for making it easier to display avatars:

• #smallUserAvatar('XWiki.username')
• #mediumUserAvatar('XWiki.username')
• #largeUserAvatar('XWiki.username')
• #resizedUserAvatar('XWiki.username', 100) which allows resizing an avatar to a custom size

More image manipulation settings

For a long time it was possible to scale attached images on the server, thus reducing the download time and ensuring consistent scaling of images across browsers. This is achieved by appending width and/or height query string parameters to the URL of the image. This feature has been further enhanced:

• It is now possible to force the same aspect ratio of the original picture even when both width/height parameters were used (the keepAspectRatio parameter). In case the requested width and height don't match the original aspect ratio, the image is resized to fit inside the rectangle defined by the two parameters, i.e. the resized image will not exceed the requested dimensions.
• The size of the generated JPGs can be further tweaked by specifying an encoding quality (the configurable default is at 30%, but will be changed to 50% before the final release). This does not affect lossless image formats such as PNG.
• The WYSIWYG editor also supports the width and height parameters, setting them as needed when manually resizing the image in the editor.

Note that this does not affect images from the filesystem, which are served directly by the servlet conainer and do not pass through XWiki's image handling code. Also note that in case the image processing triggers any errors, the original image will be sent unchanged, so the requested image dimensions are not guaranteed.

Example:

Gives:

Better handling of attachment versions when rolling back documents

Rolling back a document will also roll back the correct attachment version, including restoring a deleted attachment from the trash (if not manually deleted from there). Even if an attachment was deleted and re-uploaded several times, the platform will try to find the right version for the attachment, if it still exists in the attachment trash. As an improvement, if the attachment did not change, then a new version is not created.

Preliminary optional accessibility stylesheet

Moving further on the quest for better accessibility in the XWiki platform, we introduced a preliminary stylesheet which makes the skin slightly more accessible to people with visual disabilities: bigger fonts by default, and underlined links to make them more easily distinguished by colorblind people. This stylesheet can either be activated globally in a wiki, or individually from each user's preferences.

Enabling the special stylesheet:

Bigger fonts and underlined links:

Experimental xwiki/2.1 wiki syntax

The xwiki wiki syntax sees further improvements as xwiki/2.1, still in an experimental stage. A new feature is an enhanced syntax for links, which is more generic and allows easier extensions with new link types, demonstrated in this release with support for path and interwiki links.

Basic syntax:

Special queryString and anchor parameters which will be used as the query string, respectively anchor when forming URLs.

Document references are still the implicit default, with the explicit doc: reference type. The other standard reference types are url, path, mailto, attach, image, interwiki.

Path links allow to link to a relative path on the server, which makes it easier to combine wiki syntax and velocity code, using $doc.getURL, in order to link to non-view actions on documents.

Interwiki links

Basic syntax:

By default no sister wikis are defined. You can define some in xwiki.properties by adding rendering.interWikiDefinitions values:

Various Security improvements

Continuing a push for better security started this summer, 2.5M2 fixes some of the few remaining cross-site scripting and SQL injections holes, and tightens the scope of programming rights. Of particular concern:

• With a default skin, programming rights are no longer available after the main content of the page; this means that the panels and the bottom tabs can't use restricted APIs anymore.
• To explicitly drop programming rights, a new API method was introduced: $xcontext.dropPermissions()
• An experimental Cross-Site Request Forgery prevention mechanism is included, though not enabled by default. To enable it and test/upgrade your custom applications for compatibility, edit xwiki.properties and flip on the core.csrf.enabled setting.

Backward Compatibility and Migration Notes

General Notes

You may also want to import the default wiki XAR in order to benefit from the improvements listed above.

It is strongly recommended to set up a testing/development environment, enable this feature and fully test all the code. In most cases things should work with no additional changes. If the default edit mode is not used, or if the default velocity templates are not used, it should be enough to add the following line:

API Breakages

The following APIs were modified since XWiki Enterprise 2.4: