ReleaseNotesXWikiEnterprise32

Version 1.1 by Sergiu Dumitriu on 2011/10/11
Warning: For security reasons, the document is displayed in restricted mode as it is not the current version. There may be differences and errors due to this.

Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [xwiki:ReleaseNotes.ReleaseNotesXWikiEnterprise32]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.

This is the third release of the 3.x cycle. Following the goals established for the 3.x cycle, this release pushes forward in the directions of the Application Within Minutes and Extension Manager features. The highlights of this release are: 

  • many extension manager improvements
  • new implementation of the sheet system making it more easy to bind sheets to objects, while freeing the document content and title fields for better usage
  • user dashboards giving each user the possibility to configure their own home page
  • converted the panels application to the new XWiki syntax
  • improved search results scoring
  • storage improvements, bringing in numerous performance and compatibility improvements
  • easier activation and configuration of Google Analytics
  • wiki workspaces as a more collaborative way of managing an XWiki virtual farm
  • CSRF prevention is enabled by default

And on the developers' front:

  • xwiki-commons and xwiki-rendering are now published on the central Maven2 repository
  • some major code cleanup due to the retirement of some very old plugins and the move of legacy/deprecated code into separate modules

We've setup a Jira dashboard to present the work done for the whole 3.2 release. In summary, 341 issues have been closed by 12 committers (and other contributors providing patches), out of which 150 are fixed bugs.

New and Noteworthy (since XWiki Enterprise 3.1)

Extension Manager improvements

New implementation of the sheet system

In preparation for the Application Within Minutes major feature, this release introduces a new way of associating objects with the sheets used for displaying them. Whereas until now the content of the document had to explicitly contain an {{include}} statement in order to display an attached object, an object can pull its sheet automatically. This frees up the document content for a more useful purpose.

The new sheet detection mechanism allows for more flexibility, since sheets can not only be bound to a specific document, as with the old {{include}} mechanism, or globally on a class, but can also be differentiated on a specific action (allowing to use different sheets for view, edit or export), for different users or groups, or forced explicitly via request parameters.

The /inline/ action has been deprecated too, since form editing can also be performed using the /edit/ action, either automatically for documents containing sheet-bound objects, or explicitly forced using the editor=inline request parameter.

Most of the classes/sheets included in the XWiki Enterprise package have been updated already to use the new mechanism. Upgraded wiki instances containing documents using the old sheet inclusion mechanism will continue to work, but it's recommended to update them.

You can read more about this feature on the Sheet Module documentation page.

User Dashboards

After wiki- and space-wide dashboards, this milestone brings support for personal dashboards. Each user can define their own dashboard in their profile document, which they can either view in their profile document, or display instead of the homepage default dashboard.

userdashboard.png

Converted the Panels application to the new XWiki syntax

Although only a rewrite, with no new features, this makes it easier to edit panels. Several panels have also been cleaned up and optimized, minimizing the use of inline HTML, relying on wiki markup instead.

Improved search results scoring

An old complaint has been the fact that the search results returned by the Lucene plugin were rarely useful, with the desired document far from the top of the returned list. This has now been improved, and results are scored differently depending on the field where the search query matches them. A hit on the document title will ensure that the document will be among the first results, while a hit on the owner document's name of an attached image will place the image towards the end.

search.png

Storage improvements

The version of Hibernate used by XWiki has been upgraded to 3.6.7, bringing in numerous performance and compatibility improvements. The mapping and configuration files have also been reviewed, upgraded and simplified. Now InnoDB is used by default when creating a new database or table in MySQL (this used to be a recommendation only, now it's the default). Further performance enhancements for default installations come from the fact that the proper indexes needed for efficient database access are now auto-created at startup, eliminating the need for manual configuration.

Easier activation and configuration of Google Analytics

In older versions XWiki did provide a velocity template that could be edited to enable Google Analytics. Still, this required either access to the server or overriding a template in the skin document, which was not that easy to discover. Starting with this version, there's a custom section in the wiki Administration which makes it extremely easy to enable Google Analytics tracking.

analytics.png

The new implementation also allows to define different tracking accounts for each wiki, and also to use more than one tracking account per wiki.

Wiki Workspaces

We have adopted the Workspace Application as an XWiki platform project. In a few words, the Workspace Application allows regular users to create workspaces where they can collaborate on a specific topic. A workspaces is, in essence, a regular subwikis that is to be used by a group of global users. It allows global users to join or be invited and to easily navigate through the available workspaces and back to the main wiki.

The Workspace Application suits best for intranets or any other use case that involves having only global users and going back and forward through projects or departments that are separated in subwikis. On the other hand, the Workspace Application is not intended to be used in environments such as wiki farms, where each subwiki is a bubble, having it's own users and not knowing/caring about other subwikis or the main wiki. This later use case is better served by XWiki Enterprise Manager.

Create workspace button
Main wiki section displayed in top menu while in a workspace
Workspace Users section in the workspace's administration section replacing 'Registration' and 'Users'
Workspace Directory listing available workspaces and available actions

The Workspace Application is not bundled by default with any XWiki product, but it can be installed as an extension.

Various

Support for OpenOffice 3.3

For Developers

CSRF prevention is enabled by default

Cross-site request forgery is an exploit done via JavaScript, which allows a malicious/broken site to include javascript that performs actions on another site on behalf of the currently logged in user. Starting with 3.2, XWiki comes with a prevention mechanism enabled by default. Although it was introduced earlier, in 2.5, it wasn't enabled by default since several actions were broken by this change. Now almost everything should work fine, please report any actions that are still broken.

This feature can break custom applications that don't use the standard form edition mode and instead implement their own forms or form handling mechanism.

If your application has been broken by this change, usually all it takes to make it compatible with the CSRF prevention mechanism is to add a hidden field inside the submitted forms, or to add a request parameter to the data-altering URLs:

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

Inside URLs:
$doc.getURL('action', "parameters=values&form_token=$!{services.csrf.getToken()}")
$xwiki.getURL('Some.Document', 'action', "parameters=values&form_token=$!{services.csrf.getToken()}")

Improvements to the Suggestion and Spotlight Search widgets

Suggest widget option to support injection of content after or before a source of suggestions
Support "center" as alignment option for the suggest widget (relatively to its input field)
Support displaying a hint next to suggest display values (for example a category, etc.)
Use the unified loading indicator in search suggest widget
Suggest key navigation is not working properly when in multi-source mode and using shownoresult=false
Suggest widget should never show results once the suggest field has been blurred

New JavaScript testing framework

Unit tests for JavaScript code can now be written using the Jasmine framework for behavioral-driven development.

Example tests for the input suggestions widget:

describe("Suggest", function() {
  describe("Emphasis Matcher", function() {
    it("emphasizes a single match", function() {
     var result = XWiki.widgets.Suggest.prototype.emphasizeMatches("Typed", "Value with Typed word");
      expect("Value with <em>Typed</em> word").toEqual(result);
    });

    it("emphasizes several matches", function() {
     var result = XWiki.widgets.Suggest.prototype.emphasizeMatches("Words Typed", "A Selection Of Words Been Typed");
      expect("A Selection Of <em>Words</em> Been <em>Typed</em>").toEqual(result);
    });

    it("emphasizes repeated matches", function() {
     var result = XWiki.widgets.Suggest.prototype.emphasizeMatches("To Be", "To Be, Or Not To Be");
      expect("<em>To</em> <em>Be</em>, Or Not <em>To</em> <em>Be</em>").toEqual(result);
    });

    it("preserves original case", function() {
     var result = XWiki.widgets.Suggest.prototype.emphasizeMatches("wOrDs TypEd By An eMo kID", "Words Typed By John Doe");
      expect("<em>Words</em> <em>Typed</em> <em>By</em> John Doe").toEqual(result);
    });

    it("is neutral when there are no match", function() {
     var result = XWiki.widgets.Suggest.prototype.emphasizeMatches("Rock'n'roll", "Bring me A bowl of coffee before I turn into a goat");
      expect("Bring me A bowl of coffee before I turn into a goat").toEqual(result);
    });
  });
});

Named parameters for the event stream

The new event stream module now has support for arbitrary named parameters to be associated with the stored events. This is a better way of dealing with extra parameters than the old up to 5 numbered parameters supported by the old ActivityStream plugin. The limitation is that both the name and the value must be strings of at most 255 characters. Read more about the event stream module and how to use these named parameters in the module's documentation.

GPG signed artifacts

From now on, all build artifacts will be signed by one of the XWiki developers using a PGP signature. Such signatures are available in our maven repository as .asc files next to each artifact. We advise you to check the signatures of the files you download to make sure there are no problems with them.

To check the signatures, you should:

# Install GPG, if it's not already installed on your system
# Download both the artifact and its .asc counterpart
# Run gpg --verify --keyserver-options auto-key-retrieve=true artifact-file.jar.asc

xwiki-commons and xwiki-rendering published on the central maven repository

Starting with this version, xwiki-commons and xwiki-rendering are deployed on the central maven repository, which makes it easier to reuse modules from these projects inside a third party application, unrelated to XWiki.

Moved legacy code into separate modules

By default, the platform is now free of legacy code. Deprecated features have been officially removed, but are still included via aspects for backwards compatibility in the final distribution packages. For each module that had legacy code, there's a corresponding module in xwiki-commons-legacy or xwiki-platform-legacy that generates an extended jar containing the deprecated classes or methods on top of the clean code.

New location for storing persistent data

Due to a bug in the old core, it was very hard to configure a directory where data could be safely stored. Now, this bug has been fixed, a new API for accessing this directory has been introduced, a few components have been updated to use this location, and in the default standalone distribution a new data/ directory is configured to store permanent data.

Deprecated and Retired projects

The swizzle-based plugin for interacting with Jira has been replaced by a new jira module which uses the new REST APIs offered by Jira instead of the deprecated XML-RPC services.

Some deprecated classes/methods have been moved into legacy modules:

Several very old and unmaintained projects have been retired:

Upgrades

The following dependencies have been upgraded:

  • Aether 1.13
  • batik-rasterizer 1.7
  • commons-configuration 1.7
  • commons-lang 3.0.1
  • Doxia 1.2
  • Groovy 1.8.2
  • Hibernate 3.6.7 Final (and related dependencies)
  • HTML Cleaner 2.2
  • Jetty 7.4.5
  • jruby 1.6.3
  • Logback 0.9.30
  • Lucene 3.4
  • Reflections 0.9.5
  • Selenium 2.7.0
  • slf4j 1.6.2

Miscellaneous

Besides the major features described above this release brings lots of bug fixes as well as improvements in various domains of XWiki, including the Spotlight search, color theme usage and refreshing. See the release notes for 3.2 Milestone 1, Milestone 2, Milestone 3 and Release Candidate 1 for details.

Translations

  • The following translations have been updated: de, fr, it, lv, nl, sv, zh

Known issues

Test Report

You can check the manual test report to learn about what was tested and the results on various browsers.

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.

Migration Notes

  • removed oscache from the default distribution

API Breakages

The following xwiki-core APIs were modified since XWiki Enterprise 3.1:

TODO
Tags:
   

Get Connected