Release Notes for XWiki Enterprise 4.1.3

Version 6.1 by Marius Dumitru Florea on 2012/07/12

This release fixes a serious issue preventing the migration from version 3.5.1 and earlier (especially when the wiki had statistics data in the database).
This version also provide a new migration procedure that is almost 200 times faster, fixing the problematic downtime for large wikis and wiki farm.

New and Noteworthy (since XWiki Enterprise 4.1.2)

Full Issue List

Extension Manager improvements

  • When displaying a conflict during XAR extension install the right future author of the document is indicated for "next" and "merged" versions.
  • Indicate the language of the imported document in the log when installing a XAR extension
  • From the main wiki of a wiki farm you now have the option to trigger extension jobs (install, uninstall, upgrade, etc.) that target all the wikis. For instance, as you can see below, you can install an extension on the entire wiki farm:

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 files with the newest version since some configuration parameters were added. Note that you should add so that XWiki will attempt to automatically migrate your current database(s) to the new schema. Make sure you backup your Database before doing anything.

New migration R40000XWIKI6990

A new id migration procedure is now used per default. It provide a 200x speed improvement compare to the original one, but in some rare cases, it could failed to migrate your database properly. It is really important that you keep a backup of your database ready in case of failure. If you encounter an issue with this new faster procedure, you may want to try the older procedure by first restoring your original database, and by adding the following line in your xwiki.cfg before restarting xwiki.

This will trigger the old, slower, but potentially safer mode for migrating your data.

If you still encounter issues while migrating your data, please ask us on our user mailing list and do not forget to provide a link to your failing logs so we may provide helpful hints.

Comments stored with a custom mapping or custom annotation class

If you happened to use a custom mapping for storing XWiki.XWikiComments objects in a separate table, you may have experienced problems with the migration R40001XWIKI7540. Dealing with custom mappings is outside the scope of the migration so now, if such a custom mapping is detected, the migration is simply skipped. The migration is also skipped if you use a custom annotation class for your annotation objects, other than the default AnnotationCode.AnnotationClass.

If you are in one of the two cases above and the migration is skipped, you will want to make sure that the Annotations docextra tab is still visible. To make it visible, set Administration > Look & Feel > Page Elements > Document metadata visibility > Show document annotations to Yes. You will continue to use your custom annotations (in the Annotations tab) or custom mapped comments (in the Comments tab) as before, without them being merged into one Comments tab, as it happens by default in the latest versions.

Please see for more details.

Custom displayers in the XWikiUsers class

If you have added some custom displayers to new or existing fields in the XWiki.XWikiUsers class, you need to check and make sure that they are written in the currently default wiki syntax. This is required because the XWikiUsers document will now always be forced to use the currently default wiki syntax, no matter what syntax you save it with. If your custom displayers are written in 1.0 syntax, for example, and the class document is in 2.1 syntax, they will not render.

Issues specific to XWiki Enterprise 4.1.3

Nothing specific.

API Breakages

No breakage.

Get Connected