Release Notes for XWiki Enterprise 4.1.3

Last modified by Thomas Mortagne on 2017/03/24

We've found an important issue in this release regarding the extension manager when installing JAR extensions that provide components or script services (see XCOMMONS-231 and XCOMMONS-232). While adding UI support for installing an extension on the current wiki versus the entire farm we made a change on how extensions are installed in XWiki Enterprise, precisely, we started using the wiki namespace (even though XWiki Enterprise is a single wiki) to be consistent with what happens in multiwiki mode. Unfortunately this has revealed that the support for installing JAR extension is subwikis is not very good. Specifically, the script services defined in the installed extension are not properly registered and the components that perform dynamic component lookup (by having the component manager injected) cannot retrieve components from the namespace where the extension was installed, i.e. none of the components defined in the extension. This issue is fixed in 4.1.4 and 4.2 Milestone 1 releases, which we recommend using instead.

Due to a mistake in the code, the R40001XWIKI7540 migration was being unintentionally skipped. This is now fixed and anyone that is upgrading should avoid this release and directly use 4.1.4 instead.

If you are migrating from an earlier version than 4.0, and your database contains statistics collected using a version earlier than 2.2, you will probably encounter an issue during our automated database migration. To avoid that issue, you will need to clean up your statistics by executing some SQL commands described in issue XWIKI-8129. Be sure to apply these before attempting the migration. If your are in doubt, apply it, these could not hurt. If you don't, you will face duplicate IDs errors during the migration process, and it will fail, preventing you to run your wiki.

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.

Specific to XWiki Enterprise 4.1.3

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.

API Breakages

No breakage.

Get Connected