This is the release notes for XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager. They share the same release notes as they are released together and have the same version.

<insert description of release here>

New and Noteworthy (since XWiki 4.5.3)

Full list of issues fixed and Dashboard for 5.0.

Extension Manager improvements

We added more information to the Description section and we added the ability to retrieve the list of stable versions that are available in the configured extension repositories.

EM-extensionDescription.png

We also grouped the action buttons (e.g. Install and Install of farm) as you can see in the image above. This allowed us to move the Apply button that you had to click to confirm an extension action like install from the bottom of the Progress section to the extension actions section. The Install and Install of farm buttons are still available in the drop down menu to allow you recompute the install plan if you want to.

EM-continueInstall.png

See the Extension Manager Application documentation for more information.

Extension Updater

We added a new section to the Extension Manager administration UI that lists the available extension updates.

EM-extensionUpdater.png

Distribution Wizard improvements

We fixed an important bug in Distribution Wizard () that was preventing you from properly upgrading the installed extensions in the last step. We now list extensions by the namespace (wiki) where they have been installed. For now you have to review and upgrade each extension individually. We hope to improve this soon by allowing you upgrade more extensions at once.

DW-upgradeExtensions.png

New wiki mode step

By default you can now get the same distribution wizard you used to have for main wiki only on subwikis too. When enabled it means that each wiki administrator is able to take care of his own wiki upgrade and farm administrator will only deal with main wiki.

There are two modes:

  • ALL IN ONE: the former Distribution Wizard behavior where everything is done at main wiki level
  • WIKI: on main wiki only the main wiki is upgraded and each wiki gets its own Distribution Wizard and its own status

A new step to setup the upgrade mode has been added.

upgrademode.png

WYSIWYG Editor improvements

Automatic Paste Cleaning

Starting with this version, whenever you paste some content into the rich text area of the WYSIWYG Editor that content is (by default) automatically cleaned before being inserted into the rest of the content.

You can disable the automatic cleaning from the WYSIWYG Editor administration section if you wish:

WYSIWYGEditor-AdminSection-cleanPasteAutomatically.png

Office Import using the Office Macro

We added an option to the WYSIWYG Editor's Import Office Document dialog to allow you to import an office file using the Office Macro. This is useful if you don't plan to edit the content of the office file after the import or if you don't want to mix the content of the office file with the content of the wiki page.

xwe-importOfficeDocumentDialog.png

The generated wiki syntax looks like this:

{{office attachment="presentation.odp"/}}

Of course, you need to have the Office server connected in order to use this feature.

Release Application

A new Release application is available to help you in releasing software projects.

release1.png

New security authorization module replaces the old RightService

With this new module, we bring the following improvements:

  • More efficient and performant authorization management thanks to a smart access rules and decision cache.
  • More generic and consistant right policy based on declarative definition of rights.
  • Extensible solution, allowing registration of new rights.
  • Customizable thanks to pluggable authentication settlers using configuration.

Read the full documentation of this module for complete details.

With this new module, the access policies also evolve and this introduce some major changes that you should consider if you are migrating an existing installation. Please read those changes in the migration chapter below.

Virtual mode is always enabled

Virtual mode and multiwiki is now part of XWiki's model and can no longer be disabled. What this means is that the difference between the 2 main products (XE and XEM) is getting smaller and smaller.

In the past, XEM differed from XE by the fact that it allowed the creation of multiple wikis (called subwikis) because it had the property xwiki.virtual=1 by default in xwiki.cfg, where as XE had xwiki.virtual=0 by default. Coupled with the Wiki Manager Application and the Workspace Application which were bundled by default, this allowed XEM to create and manage subwikis, while XE could not. This was causing confusion to users that had installed one product and later on, found out that they needed the other.

To avoid confusion and to simplify our development as well, we have defaulted to a virtual mode enabled by default, allowing you to create and manage subwikis/workspaces no matter what product you have downloaded. For instance, if you have downloaded XE, you now only have to install one or two extensions (Wiki Manager Application and/or Workspace Application) using the extension manager and you are all set. Most likely we will also switch to a single product scheme in the future.

Replace "xwiki.virtual.redirect" with an error template (or page)

This xwiki.cfg setting allowed the admin to redirect to a specified URL an user that tried to access an nonexistent wiki. However, it was enabled by default and the default value was http://127.0.0.1:9080/xwiki/bin/Main/ThisWikiDoesNotExist which was definitely wrong and was causing more problems than it solved. See for an example.

We have decided to drop this feature and replace it with an error template wikidoesnotexist.vm that can be overridden by a document in the main wiki named XWiki.WikiDoesNotExist, to be consistent with what we are doing for other XWiki entities (documents, attachments, etc).

However, to avoid hitting problems with accessing your main wiki, this feature is disabled by default and can be enabled by uncommenting xwiki.virtual.failOnWikiDoesNotExist in xwiki.cfg and setting its value to 1. Otherwise, by default, the user will always get server the content of the main wiki if the wiki he requested is not found.

For those that want to achieve the same behavior as before (by redirecting to a fixed URL every time), they have to enable xwiki.virtual.failOnWikiDoesNotExist in xwiki.cfg and then redirect to the desired URL either in wikidoesnotexist.vm or in the main wiki's XWiki.WikiDoesNotExist.

Miscellaneous

  • Add support for Numbered Lists and Verbatim for the LaTex Renderer
  • Ability to more easily create multiple FAQ spaces.
  • The FAQ Application can now be translated into multiple languages + added translation for French.
  • Automatically register translations for the Annotations application
  • autowww is not enabled by default and mandatory (can not be disabled), since with virtual mode enabled by default if could prove problematic to access your main wiki without a proper wiki descriptor set up. The main reason why you could have needed to disable it was if you actually had subwiki named www and you wanted to access it instead of the main wiki. Now the autowww feature checks for this case and serves the right content.
  • Increased Permgen requirements from recommended 128MB to 196MB
  • The Jetty distribution now uses Jetty 8.1.9.v20130131

See the full list of JIRA issues fixed in this release.

For Developers

Button Group Widget

We added a small widget to group form buttons.

buttonGroup.png

It can be used either with a static list of buttons, when you know beforehand that you have more than 1 button and you know the main one, or with a dynamic list of buttons, if you want the buttons to be grouped on the client side if there are more than one.

The static button group works even with JavaScript disabled (in a modern browser):

<p class="buttons">
  <span class="buttonwrapper button-group">
    <button>Action</button><a href="#foo" class="dropdown-toggle" tabindex="0"><span/></a>
    <span id="foo" class="dropdown-menu">
      <button>First item</button>
      <input type="submit" value="Second item" class="button" />
      <a href="#third">Third item</a>
    </span>
  </span>
</p>

The dynamic group obviously requires JavaScript. The first button found in the group is considered the main one. The buttons are grouped only if there are more than one. If the main button is secondary then the button group is styled as a secondary button.

<span class="dynamic-button-group">
  <span class="buttonwrapper">
    <button>One</button>
  </span>
  <span class="buttonwrapper">
    <input type="submit" class="button secondary" value="Two" />
  </span>
  <span class="buttonwrapper">
    <a href="#three" class="secondary">Three</a>
  </span>
</span>

In both cases you need to include the widget resources:

#set ($discard = $xwiki.ssfx.use('uicomponents/widgets/buttonGroup.css', true))
#set ($discard = $xwiki.jsfx.use('uicomponents/widgets/buttonGroup.js'))

JQuery in XWiki using AMD/Require.js

Now with require.js you can pull in jQuery and use it when you need it without incurring the performance penalty when you don't need it.
To use jquery, use the script below:

{{html}}
<script>
require(['jquery'], function($) {
    $('#document-title>h1').text('JQuery in action');
});
</script>
{{/html}}

You can learn more about the power of AMD javascript modules by reading require.js documentation.

Joda Time plugin adds Duration API

The Joda Time plugin API was extended with 2 new methods for creating durations. Here's an example:

{{velocity}}
#set ($endDate = $xwiki.jodatime.getDateTime($endDateTimeStamp))
#set ($currentDate = $xwiki.jodatime.getDateTime())
#set ($duration = $xwiki.jodatime.getDuration($endDate, $currentDate))
The number of days passed since the end date is: $duration.standardDays
{{/velocity}}

Check the Duration javadoc for more information.

Document rollback events

We introduced two new document events: DocumentRollingBackEvent and DocumentRolledBackEvent. The first one is triggered before the document is saved (before the DocumentUpdatingEvent) and the second is triggered after the document is saved (after the DocumentUpdatedEvent). Checkout the Observation Module documentation to see how you can listen to these events.

Translate log

It's possible to provide a translation key with any log to let log displayer use some localization framework to find proper translation for it.

See Logging Module for more details.

XWikiDocument authors and public access

The document reference used to indicate that a document has been created/modified by a public access user (or guest user) is now null. It's following what is already the XWikiContext behavior which means that you can now safely compare context user reference and document authors reference since both of these APIs have the same behavior regarding unauthenticated users.

Back to JUnit

XWiki Commons used to force using the junit-dep Maven dependency instead of the junit one at build time because of embedded libraries in the JUnit jar. Since it's not the case anymore (it was fixed in JUnit 4.11) the enforcer rule and everything about junit-dep has been removed from our pom.xml files.

The main change for external projects if that if you depended on junit-dep and didn't specify the version your project won't build anymore and you should change the dependency for junit.

Deprecated and Retired projects

No deprecated nor retired projects in this release.

Upgrades

The following dependencies have been upgraded:

  • Apache Ivy 2.3.0
  • Groovy 2.1.3
  • GWT 2.5.1 and SmartGWT 3.1
  • Hamcrest 1.3
  • httpclient 4.2.3
  • JGroups 3.2.7.Final
  • Joda Time 2.2
  • JUnit 4.11
  • Jython 2.5.4-rc1
  • Liquibase 2.0.5
  • LogBack 1.0.11
  • Pygments 1.6
  • SLF4J 1.7.5
  • Tika 1.3
  • XStream 1.4.4

Miscellaneous

  • More API added to the Model Script Service
  • You can now specify a target user or an email address in the share page URL like this:
    /xwiki/bin/view/Space/Page?viewer=share&target=foo@bar.org&target=XWiki.mflorea
  • Added methods to query existing wikis: api.XWiki.getWikiNames() and api.XWiki.hasSubWikis()
  • XWiki is now always in virtual mode so development needs to consider the fact that the main wiki may not be the only wiki available.
  • With the transition to virtual mode by default, the XWiki.XWikiServerClass is now a mandatory class to be used when creating a wiki descriptor. Its existence will be, like all mandatory classes, checked when XWiki starts, but only for the main wiki. It was formerly initialized by and part of the wiki-manager module but it's now part of the core. Also, the XWiki.XWikiServerClassSheet has been moved to the wiki-manager-ui module.

Translations

The following translations have been updated: 

Tested Browsers & Databases

Known issues

Backward Compatibility and Migration Notes

General Notes

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

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

<issues specific to the project>

API Breakages

The following APIs were modified since XWiki 4.5.3:

<clirr output here>
Tags:
   

Get Connected