Release Notes for XWiki Enterprise 4.1.3
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.
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.
