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

This release makes it possible for users with just edit right to re-order pages in the navigation, fixes bugs and improves the performance of XWiki in particular for larger instances. This release contains security fixes, with the highest severity being 8.7/10.

New and Noteworthy (since XWiki 17.1.0)

Full list of issues fixed and Dashboard for 17.2.0.

For Users

Users with edit rights can pin pages in spaces

 
It was already possible for global administrators and administrators of spaces to pin pages for organizing the navigation panel. Now the feature is also available for people having edit rights on a space: a new tab is available in the page children view, available from the more action menu. From this new tab, it is possible for a user to entirely reorganize the pages of the space by using drag & drop or by using the action button to pin / unpin pages, pretty much like it was already possible in the navigation panel administration.

New user registration form updated order

 
Reverted the changes to the fields of the registration form merged in 16.10.0 . The form fields are now: first name, last name, username, password, password validation, email ( and then Captcha if enabled).

Miscellaneous

• Page rendering performance improvements: The macros of the main /view/ are now prepared (the part of the execution that does not depend on the context is cached). Also, preparation has been added to both the code macro and the wiki content passed to various wiki macros. This should improve the performance of quite a lot of complex pages (especially those containing velocity or code macros).

For Admins

• New configuration to improve indexing performance at startup: By default, the Solr search index is synchronized with the document database when XWiki starts. For this, XWiki queries and compares batches of documents from both the Solr search index and the database. As those queries can take a lot of time in large wikis, the batch size has been increased from 100 to 1000 by default and has been made configurable to allow further increasing it to reduce the number of queries at the expense of a higher memory usage. Increasing this option is recommended for large wikis (for example, more than 100k pages in a single wiki), in particular if you notice that performance is slow and that there is a high load on the database after startup. You can find all options related to synchronization on startup in the documentation.

• Filter stream export supports excluding property types: The XWiki instance input stream supports excluding certain property types now. This can be used to exclude, for example, "Email" and "Password" properties from an export.

For Developers

• DocumentModelBridge#isNew: A new API has been exposed in DocumentModelBridge to know if that document instance is stored or not already.

• Delete an attachment through script: The script Document API now provide a public API remove an attachment.

• New Velocity instanceOf: A new API was added to the Velocity $objecttool to check if a Java Object extend/implement a given class. For example $objecttool.instanceOf($myObject, 'java.lang.Number').

• Added a way to define macro property features as mandatory with the `@PropertyFeature` annotation: The @PropertyFeature annotation used to define the feature of a property, typically used in java Macro parameter definitions, now supports a mandatory attribute. A mandatory feature is a feature for which at least one field fulfilling this feature must have a value. E.g. The reference feature of the include macro is implemented by two properties: reference and page. Making the feature mandatory with:

  @PropertyFeature(value = "reference", mandatory = true)

  Means that at least one of the properties reference or page MUST have a value for the provided macro parameters to be valid. This is an intermediate level between making both properties mandatory and having no mandatory property.

Upgrades

The following runtime dependencies have been upgraded (they have a different release cycle than XWiki Commons, XWiki Rendering and XWiki Platform):

Translations

The following translations have been updated: 

• Spanish
• French
• Simplified Chinese
• Traditional Chinese

Security Issues

Security issues are not listed in issue lists or dashboards to avoid disclosing ways to use them, but they will appear automatically in them once they're disclosed. See the XWiki Security Policy for more details.

Known issues

• Bugs we know about

Backward Compatibility and Migration Notes

General Notes

• When upgrading make sure you compare and merge the following XWiki configuration files since some parameters may have been modified, removed or added:
  • xwiki.cfg
  • xwiki.properties
  • web.xml
  • hibernate.cfg.xml
• Add xwiki.store.migration=1 in xwiki.cfg so that XWiki will attempt to automatically migrate your current database to any new schema. Make sure you backup your Database before doing anything.

Issues specific to XWiki 17.2.0

Protection against concurrent modification of cached document

It's considered bad practice to directly modify the document from the cache (mainly because it can badly impact other requests/threads). This version introduces automatic protections to avoid this situation as much as possible by doing the following: if the XWikiDocument instance in the document store has been modified, any attempt to access it will result in the reloading of the document from the store and the replacement of the "corrupted" document from the cache.

But also a warning is logged when the mistake is made so that the related code is identified and fixed, because the protection cannot fix all cases, for example:

To avoid the warning, one must clone the XWikiDocument before modifying it. That's something that has already been done automatically for a long time when using the Document script API.
It would be great to report those warnings if you encounter any, but it's also possible to disable them easily because they are considered deprecation logs: control them using the property  logging.deprecated.enabled in the xwiki.properties configuration file.

API Breakages

The following APIs were modified since XWiki 17.1.0:

No breakage!

Credits

The following people have contributed code and translations to this release (sorted alphabetically):

• Alex Cotiugă 
• Alvaro 
• Anmol 
• Gankov Andrey 
• LEE CHENG WEI 
• LucasC 
• Manuel Leduc 
• Marius Dumitru Florea 
• Mend Renovate 
• Michael Hamann 
• Simon Urli 
• Thomas Mortagne 
• Vincent Massol 
• dependabot[bot] 
• slauriere 
• zon1002