This is the release notes for XWiki Commons, XWiki Rendering, XWiki Platform and XWiki Enterprise. 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 7.0 Milestone 2)

Full list of issues fixed and Dashboard for 7.0.

Experimental Realtime Watchlist Notification

We have added a new notification option for WatchList that notifies users of changes on their watched documents in real time (i.e. as soon as they happen).

This feature is currently experimental and disabled by default. Fore more information on it and how to enable it, please see the documentation.

Miscellaneous

• Rendering page performances have been improved when using the Flamingo skin (thanks to the usage of Less4j for the integration of the LESS language).
• When deploying XWiki as ROOT you must now set the xwiki.webapppath property to empty as in:
  xwiki.webapppath=

  The reason is that XWiki cannot guess the webapp context from the URL in this case. This seemed to work on previous versions but it was actually leading to errors from time to time, depending on what URL was used when doing the first request on the XWiki instance.

• Debian packages based on Tomcat 8 have been added.
• Distribution Wizard should not ask to login when installing from scratch anymore
• Renamed the WatchList notification options to something simpler and clearer:

    

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

For Developers

Access Extension fields by name

Added a method in Extension to access a field (name, summary, version, etc.) value by name.

Skin Edition

• We have added a new Skin Application to easily edit a skin document.

    

• This application provides a new way to override a template. You do not need to edit the XWikiSkins class anymore.
• It also provides the ability to override a file stored in a subdirectory.
• It is now possible to override the LESS templates.

Extensions Repository improvements

• The new advanced extension search introduced in 7.0 Milestone 2 has been implemented on server side
• Source URL is now taken into account when importing an extension
• Search and advanced search are now implemented based on Solr which among other things make the search ordered by score by default and boost configuration has been associated to each extension element (high score for extension name and id, etc.)
• Extensions Repository REST service now return scm informations

Solr index changes

All String based object properties raw values are now stored in the Solr index with _string suffix (exactly like for static lists properties) in DOCUMENT types. This mean that when upgrading to 7.0 you should recreate the Solr index so that they are added.

Deprecated and Retired projects

• The WatchList plugin has been moved to legacy and was replaced by a component-based implementation. The legacy module still provides a plugin API for compatibility, but clients should move to the new script service instead.

Miscellaneous

• XAR Mojos now also format and verify attachment authors.
• MandatoryDocumentInitializer components can now use a @Priority annotation to specify the order in which they should be executed. See XWIKI-11905.
• A new isMainWikiOnly() method is available in AbstractMandatoryDocumentInitializer for overriding to specify that the document should be initialized on the main wiki only.
• A new setDocumentFields() method is available in AbstractMandatoryDocumentInitializer to be called when initializing a regular document (which is not a class).
• A new component based implementation of the watchlist module is now available (replacing the plugin one). See the documentation for more information.
• The XWiki pages for the XClass Application (a.k.a Class Wizard or Class Editor Wizard) which were located in the xwiki-enterprise GitHub repository have been moved into a xwiki-platform-xclass Maven module in the xwiki-platform GitHub repository.
• Added access to the document XDOM in com.xpn.xwiki.api.Document. That means you can now do $doc.getXDOM() and $doc.setContent($xdom).
• The default preferences (the XWikiPreferences document) has been moved from xwiki-enterprise-ui-admin-user to xwiki-enterprise-ui-mainwikipreferences.

Upgrades

The following dependencies have been upgraded:

• Groovy 2.4.2

Translations

The following translations have been updated: 

• Catalan
• Czech
• Danish
• German
• Spanish
• French
• Galician
• Italian
• Korean
• Latvian
• Portuguese (Brazil)
• Romanian
• Russian
• Slovak
• Swedish
• Turkish
• Vietnamese
• Simplified Chinese
• Traditional Chinese

Tested Browsers & Databases

Known issues

• Bugs we know about

Backward Compatibility and Migration Notes

General Notes

When upgrading make sure you compare your xwiki.cfg, xwiki.properties and web.xml files with the newest version since some configuration parameters may have been modified or 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 7.0 RC 1

• The WatchList plugin has been moved to legacy and was replaced by a component-based implementation. The legacy module still provides a plugin API for compatibility, but clients should move to the new script service instead.
• The Solr index changed so it needs to be recreated in case some new feature would expect to find the new fields
• Debian packages based on Tomcat 5 and 6 has been removed since they are not supported by XWiki itself anymore
• XWiki now requires to be deployed in a Servlet Container support Servlet 3.0.1. For example:
  • Jetty 8.x
  • Tomcat 7.x
  • Glassfish 3.x
  • WebSphere 8.x
  • WebLogic 12.x
  • JBoss AS 6.x/7.x
  • Resin 4.0.1

API Breakages

The following APIs were modified since XWiki 6.4.3:

• In Velocity $jsontool.serialize($object) method return null when failing to serialize the passed object (it used to return whatever it was able to write before failing to serialize an element). This should not cause much issue since expecting to get a partial invalid JSON content is most probably a very rare use case.