The highlights of this release are:

  • support for viewing attached office documents in the wiki
  • a new User Directory
  • an experimental Extension Manager
  • improvements to action menus
  • further improvements to the edit UI
  • support for activating a special accessibility stylesheet
  • more consistent use of user avatars
  • an experimental xwiki/2.1 wiki syntax
  • a mechanism for inserting custom links in the header
  • the introduction of cancelable events
  • better external search engine indexing support
  • experimental CSRF protection
  • experimental Cryptographic Module

New and Noteworthy (since XWiki Enterprise 2.4.4)

Support for viewing attached office documents in the wiki

XWiki now supports viewing attached office documents without saving them on the client side. Click on the eye icon near the edit and delete buttons corresponding to the attachment you want to preview.

OfficePreview.png

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

MacroOfficeViewer

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.

group-avatar.png

Experimental Extension Manager

The new Extension Manager will allow you to install new extensions to XWiki Enterprise. Please note that this is an experimental feature, with limited features and a raw user interface. Use it at your own risk.

ExtensionManager.png

Improvements to Action Menus

  • New Add menu: Use the "Add" menu to create new spaces, pages, add attachments and comments.

    AddMenu.png

  • Improved Wiki and Space menus: You may now access the document index straight from the wiki & space menus.

    WikiMenu.png        SpaceMenu.png

  • New Page menu: Integrates the Watch, Copy, Rename and Delete actions.

    PageMenu.png

  • The Edit, Export, More actions and Profile menus also benefited from a refresh.

Visible content menu when scrolling down

When scrolling down on a document, the content menu will follow, so the user will not have to scroll up on top of the page in order to access it.

ActionMenu.png

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:

    edit-header.png

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

    edit-footer.png

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:

a11y-enable.png

Bigger fonts and underlined links:

a11y.png

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.

comment-avatars.png

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

User avatars are also displayed in annotations.

annotation-avatars.png

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 50%). 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.
/xwiki/bin/download/Spage/Page/logo.jpg?width=1024&height=768&keepAspectRatio=true&quality=0.8

Note that this does not affect images from the filesystem, which are served directly by the servlet container 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:

{{velocity}}{{html wiki=false}}
<img src="$doc.getAttachmentURL('mw.jpg', 'download', 'width=150&quality=1')"/>
<img src="$doc.getAttachmentURL('mw.jpg', 'download', 'width=150')"/>
<img src="$doc.getAttachmentURL('mw.jpg', 'download', 'width=150&quality=0')"/>
<img src="$doc.getAttachmentURL('mw.jpg', 'download', 'width=150&height=100&quality=0.7')"/>
<img src="$doc.getAttachmentURL('mw.jpg', 'download', 'width=150&height=100&quality=0.7&keepAspectRatio=true')"/>
{{/html}}{{/velocity}}

Gives:

img.png

Mechanism for inserting custom links in the header

As a new part of the UI extensions mechanism, similar to skin extensions, applications can now insert custom <link> elements in the HTML header of the page, which allows to insert, for example:

  • custom navigational links (universal edit, paged navigation, index, author...)
  • custom RSS feed links
  • custom metadata links (DOAP, FOAF, generic RDF...)

Usage example:

$xwiki.linkx.use($xwiki.getURL('Blog.BlogRss', 'view', "xpage=plain&blog=${blogDoc.fullName}"),
  {'rel' : 'alternate', 'type' : 'application/rss+xml', 'title' : $title})

Experimental xwiki/2.1 wiki syntax

The xwiki wiki syntax sees further improvements as xwiki/2.1 is 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:

[[label>>referenceType:referenceData]]

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

[[label>>doc:My.Page||queryString="a=b&c=d" anchor="HSection1"]]

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.

{{velocity}}[[reset the history>>path:$doc.getURL('reset')||queryString="confirm=1"]]{{/velocity}}

Basic syntax:

[[label>>interwiki:wikiAlias:path/data]]
[[Interwiki links>>interwiki:wikipedia:Interwiki_links]]

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

rendering.interWikiDefinitions = wikipedia = http://en.wikipedia.org/wiki/
rendering.interWikiDefinitions = udic = http://www.urbandictionary.com/define.php?term=

Introduced XWiki Cryptographic Module

This module exposes high level api, allowing developers to bolster their security using cryptography for both integrity and confidentiality.
You can find more information about the cryptographic module including examples at the code zone page for the XWiki Cryptographic Module.

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.

Introduced cancelable events

This allows to cancel document saving, better security with script execution and canceling an event that has errors on initialization.

Better external search engine indexing support

Google search results now always point to canonical view of pages.

New macros for the Space List and Tag Cloud

  • Space List Macro. This macro creates a box with links to all the spaces existing in the wiki.
  • TagCloud Macro. Generates a TagCloud from all the tags within the wiki.

WYSIWYG and Rendering improvements

Display macro parameter names instead of IDs, generalized the syntax for links, added support for query string for image links, fixed a random error when loading several WYSIWYG instances in parallel.

Performance improvements

Fixed a performance issue with the Jump To Page feature.

Security improvements

Continuing a push for better security started this summer, 2.5 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, the panels and the bottom tabs can no longer use restricted APIs.
  • 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.
  • Fixed a broken check on rights from the Rest system
  • Fixed a missing author update when editing classes.

Translations

  • All the translations have been updated

Known issues

Backward Compatibility and Migration Notes

General Notes

If you're running in a multiwiki setup you'll also need to define the property xwiki.store.migration.databases=all to your xwiki.cfg file or explicitly name all databases to be migrated as in xwiki.store.migration.databases=db1,db2,....

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

Always make sure you compare your xwiki.cfg file with the newest version since some configuration parameters were added. Note 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.

Experimental support for CSRF protection is included in this release, although not enabled by default. This mechanism changes the way data is supposed to be saved, a change which will not completely break custom applications in most cases, but which might insert an extra validation step needed for actually saving the data.

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:

<input type="hidden" name="form_token" value="$!{services.csrf.getToken()}" />

Migration Notes

The main entry point for the search UI is now the Main.Search page that will use the configured search engine (Lucene by default). If you want to refer to Lucene or Database search explicitly you can use the Main.LuceneSearch and Main.DatabaseSearch pages. Note that nothing is broken here (Main.WebSearch page is still there and internally it includes the Main.DatabaseSearch page), it's just the new clean way of targeting the search page.

Removed deprecated flickr plugin

The old flickr plugin was outdated and the API was broken, so, as a consequence, it has been removed. A new plugin will be available in the future. Meanwhile you can still find it in the contrib-retired at this link.

Update your web.xml

Some servlet filters (SetCharacterEncodingFilter, used to handle character encoding and SavedRequestRestorerFilter, used to restore requests on login) were refactored and moved to another package. Make sure you update your WEB-INF/web.xml to the current version, otherwise XWiki server will fail to start.

API Breakages

The following APIs were modified since XWiki Enterprise 2.4.4:

[ERROR] org.xwiki.rendering.transformation.MacroTransformationContext: Method 'public org.xwiki.rendering.internal.transformation.MacroTransformation getMacroTransformation()' has been removed
[ERROR] org.xwiki.rendering.transformation.MacroTransformationContext: Method 'public void setMacroTransformation(org.xwiki.rendering.internal.transformation.MacroTransformation)' has been removed
[ERROR] org.xwiki.rendering.transformation.Transformation: Method 'public void transform(org.xwiki.rendering.block.Block, org.xwiki.rendering.transformation.TransformationContext)' has been added to an interface
[ERROR] org.xwiki.rendering.transformation.TransformationManager: Method 'public void performTransformations(org.xwiki.rendering.block.Block, org.xwiki.rendering.transformation.TransformationContext)' has been added to an interface
Tags:
   

Get Connected