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 add support for attachment usage refactoring when moving or renaming attachments, and introduce the Client-side PDF Export extension, allowing users to export wiki pages to PDF using the browser's print to PDF feature.
For developers, it is now possible to possible to execute JavaScript code after the page is fully ready. In addition, the custom event propertiesEdit is not stronly typed (i.e., not only strings).

The following regressions were introduced in this release (and found after it was released). Please check them out and if they impact you we recommend waiting to upgrade to a version where they are fixed.

New and Noteworthy (since XWiki 14.1)

Full list of issues fixed and Dashboard for 14.2.

For Users

Attachments usage refactoring

 
When moving an attachment, the pages using the moved attachment are now automatically refactored to point to the new location of the attachment. Advanced users can deactivate this refactoring in the move attachment form.

Client-side PDF Export

 
This release introduces a new extension that allows users to export wiki pages to PDF using the browser's print to PDF feature. It's not bundled in XWiki Standard yet but you can install it with the Extension Manager. The advantage of the client-side PDF export over the current server-side FOP-based export is that the result is closer to the way the wiki page looks in view mode (most of the skin styles are preserved). See the PDF Export Application for more information.

Miscellaneous

  • Attachments backlinks indexation: An indexation of the attachments is now done on the wikis. This means that if PageA includes an attachment (or an image) from PageB, PageA will be listed in the backlinks of PageB.

    Indexing the attachments requires a full reindexing of both the pages links and attachments usage of the wiki. This means that for a brief period of time, some pages backlinks might be partially incomplete, especially on large wikis.

  • Disabling lightbox for specific content: The image lightbox feature can now be disabled for an element and its children by adding xwiki-lightbox=false to the parent of the excluded content. This can be used by macros or extensions rendering images as part of the page content so that these images don't appear in the lightbox view.

  • Automatically generated anchors for images: XWiki now automatically generates anchors (ids) for images as it does for heading. This makes it easier to, e.g., reference images using the Reference Macro. Automatically generated ids can be overridden by manually setting the image's id parameter.

For Admins

No changes!

For Developers

Typed custom event properties

 
Stream events support custom parameters since the new store implementation, but it was only strings. The old "parameter" related APIs have been renamed to "custom" APIs to support any Object as value. The standard store implementation natively support String, all Numbers, Boolean, Date, byte[] and any Iterable or array of the other types (anything else is converted to String). See Event Stream Module for more details about stream events.

Detect Page Ready

 
It's now possible to detect and execute JavaScript code after the page is fully ready, i.e. after all resources have been loaded and there are no pending HTTP requests or promises:

require(['xwiki-page-ready'], function(pageReady) {
  pageReady.afterPageReady(() => {
    console.log('Page is ready!');
  });
});

This is currently used by the client-side PDF export to know when the page is ready for print and by the automated functional tests to know when to start interacting with the page (simulating user actions). See the Page Ready module documentation for more information.

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: 

Tested Browsers & Databases

Here is the list of browsers we support and how they have been tested for this release:

 BrowserTested on:
Chrome30.pngGoogle Chrome 99Not Tested
Firefox30.pngMozilla Firefox 98Jira Tickets Marked as Fixed in the Release Notes
Edge30.pngMicrosoft Edge 99Tests run and results
Safari30.pngSafari 15Not Tested

Here is the list of databases we support and how they have been tested for this release:

 DatabaseTested on:
hypersql.pngHyperSQL 2.6.1Not Tested
mariadb.pngMariaDB 10.6Tests run and results
postgresql.pngPostgreSQL 14Jira Tickets Marked as Fixed in the Release Notes
mysql.pngMySQL 8Not Tested
oracle.pngOracle 19cNot Tested

Here is the list of Servlet Containers we support and how they have been tested for this release:

 Servlet ContainerTested on:
tomcat-icon.pngTomcat 9.0.60
jetty-icon.pngJetty 10.0.7 (XWiki Standalone packaging)Not Tested
jetty-icon.pngJetty 10.0.7Not Tested

Known issues

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.

API Breakages

The following APIs were modified since XWiki 14.1:

Real breakages

Real backward compatibility breakages that we have unwillingly accepted to do for the reasons mentioned in each violation below.

  • Removed since the class does not need to be serializable.
    • Violation type:
      java.class.noLongerImplementsInterface
    • Code:
      ## Old:
      class com.xpn.xwiki.doc.XWikiLink

      ## New:
      class com.xpn.xwiki.doc.XWikiLink

Unstable APIs

Not real backward compatibility breakages since they were done on APIs marked @Unstable (a.k.a Young APIs). Thus it's part of the contract that they can be broken until they become stable. They're listed purely for reference in case you decided to still use them (and thus agreed to be broken).

  • This class was meant to be internal and is internal now. This should not cause breakages as it was documented that the class would be removed at some point (and marked as unstable).
    • Violation type:
      java.class.removed
    • Code:
      ## Old:
      class org.xwiki.xml.html.XWikiHTML5TagProvider
  • Young API
    • Violation type:
      java.method.addedToInterface
    • Code:
      ## Old:


      ## New:
      method java.util.Optional<org.xwiki.rendering.block.MacroBlock> org.xwiki.rendering.macro.MacroRefactoring::replaceReference(org.xwiki.rendering.block.MacroBlock, org.xwiki.model.reference.DocumentReference, org.xwiki.model.reference.AttachmentReference, org.xwiki.model.reference.AttachmentReference, boolean) throws org.xwiki.rendering.macro.MacroRefactoringException
  • Young API
    • Violation type:
      java.method.addedToInterface
    • Code:
      ## Old:


      ## New:
      method java.util.concurrent.CompletableFuture<org.xwiki.index.internal.TaskData> org.xwiki.index.TaskManager::addTask(java.lang.String, long, java.lang.String)
  • Young API
    • Violation type:
      java.method.removed
    • Code:
      ## Old:
      method java.util.concurrent.CompletableFuture<org.xwiki.index.internal.TaskData> org.xwiki.index.TaskManager::replaceTask(java.lang.String, long, java.lang.String, java.lang.String)

Credits

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

  • Alexis Tual
  • Clément Aubin
  • Gankov Andrey
  • I Knownothing
  • Manuel Leduc
  • Marius Dumitru Florea
  • Michael Hamann
  • Oana-Lavinia Florean
  • ParkHK
  • Phạm Huy Thiên
  • Simon Urli
  • Simpel
  • Thomas Mortagne
  • Vincent Massol
Tags:
   

Get Connected