Release Notes for XWiki 14.6-rc-1
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 brings paginated attachments, multiple categories support for wiki macros and cancelable multi-page PDF exports. Admins can now control where the PDF export is performed (server-side or client-side) and also security related aspects, such as what HTML elements attributes are allowed in wiki syntax or the HTML macro. The old events store has also been moved to legacy, as it will eventually stop being bundled by default. On the other hand, the CKEditor integration was moved from Contrib into XWiki Platform. Finally, an important security-related migration is now available and configurable regarding the notification and regeneration of user passwords for potentially affected users.
New and Noteworthy (since XWiki 14.5)
Full list of issues fixed and Dashboard for 14.6.
For Users
Ckeditor Macro Dialog filters by categories
The CKEditor Macros dialog now allows to filter by several categories. In addition, all the listed macros are now displaying their categories.
In addition, macros with an hidden category are not displayed to users who have Display hidden pages set to False in their preferences. Hidden macros categories are Deprecated and Internal by default, and can be configured by Admins since 14.8+.
Cancel PDF Export
You can now cancel a running multi-page PDF export job, either because you triggered it by mistake (for a large subtree of pages) or because it takes too long, or any other reason. See the PDF Export Application documentation for more information.
Wiki macros can have several categories
The wiki macros can have several categories. The deprecated Default category is replaced by Default categories.
Add pagination for Attachments
The attachments tab is now displayed using a Livetable, with only 5 rows displayed at a time to avoid a crowded section. This way, on pages with multiple attached files users can use the navigation and filtering options to search for specific attachments.
Macro Categories listed in the available macros page
The list of all the categories of the macros are now listed in the available macros page.
Miscellaneous
Java macros can have several categories: The java macros can have several categories. The deprecated setDefaultCategory is replaced by setDefaultCategories. For instance:
/**
* Create and initialize the descriptor of the macro.
*/
public ExampleMacro()
{
super("Example", DESCRIPTION, ExampleMacroParameters.class);
setDefaultCategories(java.util.Collections.singleton("Tutorial"));
}
For Admins
Force client-side PDF generation: The PDF Export application has a new global setting to control whether the PDF is generated server-side (e.g. using a headless Chrome web browser running inside a Docker container) or client-side, using the user's web browser:
# [Since 14.6RC1]
# Whether the PDF export should be performed server-side, e.g. using a headless Chrome web browser running inside a
# Docker container, or client-side, using the user's web browser instead; defaults to server-side PDF generation
export.pdf.serverSide=trueNote that client-side generation has the downside that different users may get a different PDF result for the same wiki page (same content).
New Options for Allowed HTML Elements and Attributes: New options for HTML cleaning were added that allow precise control which attributes and elements are allowed in XWiki syntax but also in the HTML macro in restricted contexts. The default settings should be fine but in case you notice any breakage due to attributes no longer working or want to restrict certain features like inline-styling, consult the documentation on these options. Do not hesitate to contact us on the forum or the chat in case you notice unexpected breakages or other issues with this change.
For Developers
Moved the old event store to legacy
The old events store is still bundled with XWiki for now. However, it has now been moved to legacy in order to make sure it is not actively used in the product, to discourage others from directly using it (by mistake) and as a first step before actually stopping to bundle it.
Miscellaneous
Figure Type Identification: A data-xwiki-rendering-figure-type property is added to the rendered figures macro. Its value is table if the figure contains a single table, and figure otherwise.
Provide a way to list the categories of a macro: The MacroCategoryManager from Rendering Macro Transformation provides a getMacroCategories operation that takes a MacroId object and return the set of categories of the macro. The default implementation takes into account the macro categories overriding that can be done in xwiki.properties.
Script service to access the macro categories: Calling $services.rendering.getMacroCategories($macroId) returns a Set of the categories of the macro. See XWiki Platform - Rendering - XWiki-specific Implementation.
New HTML Sanitizer: A new HTML Sanitizer component has been added that allows checking if a certain HTML element, attribute and attribute value are considered safe according to the current configuration. This can be used when validating user input. The sanitizer also supports SVG and MathML with the features available when they are embedded in HTML documents.
Moved Modules
CKEditor Integration is now part of XWiki Platform. The extension will still be maintained as an independent contribution extension, for bug fixes only, until the 14.4.x and 13.10.x branches become unsupported. Please create new issues on the XWiki Plaform Jira project. Issues can still be created in the CKEditor Integration Jira project only for bug that are impacting branches 14.4.x and 13.10.x.
Upgrades
The following runtime dependencies have been upgraded (they have a different release cycle than XWiki Commons, XWiki Rendering and XWiki Platform):
- node 16.15.1
- @vue/cli-plugin-babel 5.0.8
- vue-i18n 8.27.2
- vue-tippy 4.14.0
- eslint-plugin-vue 8.7.1
- less 4.1.3
- less-loader 10.0.0
- @testing-library/jest-dom 5.16.4
- @babel/eslint-parser 7.18.2
- Woodstox 6.3.0
- JNA 5.12.1
- Protobuf Java 3.21.2
- Byte Buddy 1.12.12
- Liquibase 4.12.0
- MariaDB connector 3.0.6
- jsoup 1.15.2
- Tika 2.4.1
- Revapi Java 0.27.0 and Maven plugin 0.14.7
- log4j API 2.18.0
- Commons Configuration 2.8.0
- Hibernate 5.6.10
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:
Browser | Tested on: | |
---|---|---|
Mozilla Firefox 102 | Not Tested | |
Google Chrome 103 | Not Tested | |
Microsoft Edge 103 | Jira Tickets Marked as Fixed in the Release Notes | |
Safari 15 | Not Tested |
Here is the list of databases we support and how they have been tested for this release:
Database | Tested on: | |
---|---|---|
HyperSQL 2.6.1 | Not Tested | |
PostgreSQL 14 | Not Tested | |
MariaDB 10.6 | Not tested | |
MySQL 8 | Jira Tickets Marked as Fixed in the Release Notes | |
Oracle 19c | Not Tested |
Here is the list of Servlet Containers we support and how they have been tested for this release:
Servlet Container | Tested on: | |
---|---|---|
Tomcat 9.0.65 | Jira Tickets Marked as Fixed in the Release Notes | |
Jetty 10.0.7 (XWiki Standalone packaging) | ||
Jetty 10.0.7 | Not 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.
Migration sending emails
A migration is provided as part of this upgrade that might trigger a reset password of some users. As part of this operation, some emails are automatically being sent by default: a first mail informing about a possible data leak, and a second mail for asking users to reset their password.
It's possible to chose whether the mails should be sent or not by editing the following properties:
#-# [Since 14.4.3]
#-# [Since 13.10.8]
#-# This option is only used when performing a migration from a wiki before the versions mentioned above.
#-#
#-# This parameter defines if as part of the migration R140600000XWIKI19869 the passwords of impacted user should be
#-# reset or not. It's advised to keep this value as true, now for some usecases advertised administrators might want
#-# their users to keep their passwords nevertheless, then enable the configuration and set it to false before the
#-# migration is executed.
# security.migration.R140600000XWIKI19869.resetPassword = true
#-# [Since 14.6RC1]
#-# [Since 14.4.3]
#-# [Since 13.10.8]
#-# This option is only used when performing a migration from a wiki before the versions mentioned above.
#-#
#-# This parameter defines if reset password emails should be sent as part of the migration R140600000XWIKI19869.
#-# By default this value is set to true, so emails will be automatically produced. Now it's possible for admin to set
#-# this option to false: note that in such case a file containing the list of users for whom a reset password email
#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).
#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to
#-# send the emails, so it's possible to perform the migration and send the emails only later if needed.
# security.migration.R140600000XWIKI19869.sendResetPasswordEmail = true
#-# [Since 14.6RC1]
#-# [Since 14.4.3]
#-# [Since 13.10.8]
#-# This option is only used when performing a migration from a wiki before the versions mentioned above.
#-#
#-# This parameter defines if a security email information should be sent as part of the migration R140600000XWIKI19869.
#-# By default this value is set to true, so emails will be automatically produced. Now it's possible for admin to set
#-# this option to false: note that in such case a file containing the list of users for whom a reset password email
#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).
#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to
#-# send the emails, so it's possible to perform the migration and send the emails only later if needed.
# security.migration.R140600000XWIKI19869.sendSecurityEmail = true
Note that the mails are sent after the migration is actually performed, during the wiki intialization by reading a file named 140600000XWIKI19869DataMigration-users.txt created in the permanent directory during the migration. So it's possible for an administrator to set the properties for sending the emails to false for performing the migration, and to actually set them back to true before a next restart to send the emails at this moment. Be aware that the file is deleted as soon as the emails are processed to be sent: in case of failure for sending the emails, please check the administration of the wiki to see the status of the created emails.
It's also possible for administrators to configure the template of the first mail by creating a file named 140600000XWIKI19869-mail.txt in the permanent directory. The format of this template is the following:
Subject:<the subject of the email>
<the plain text content of the email>
By default, the mail template is the following:
Subject: Important security issue Dear user, due to a bug your password was stored in plain text in our wiki. We cannot exclude that your plain text password was exposed in a data leak. Therefore, you might receive a second email to choose a new password. Please contact the administrator in case of problem or for further questions.
API Breakages
The following APIs were modified since XWiki 14.5:
No breakage!
Credits
The following people have contributed code and translations to this release (sorted alphabetically):
Andreas Jonsson
Eduard Moraru
Manuel Leduc
Marius Dumitru Florea
Michael Hamann
Oana-Lavinia Florean
Simon Urli
Simpel
Thomas Mortagne
Vincent Massol
oanalavinia
xrichard