XWiki Enterprise 2.5 Milestone 2

Version 35.2 by Sergiu Dumitriu on 2010/10/04

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

Experimental Extension Manager

New User Directory

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

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

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

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

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:

a11y-enable.png

Bigger fonts and underlined links:

a11y.png

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:

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

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

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()}" />

API Breakages

The following APIs were modified since XWiki Enterprise 2.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