Changes Report
Async Form Validation
A new JavaScript API is available to help implement asynchronous form validation. It can be used like this:
require(['jquery', 'xwiki-form-validation-async'], function($) {
const titleInput = $('input[name=title]');
const validateTitle = () => {
if (!titleInput.val()) {
return Promise.reject();
} else {
return new Promise((resolve, reject) => {
...
});
}
};
titleInput.on('input', () => {
// Schedule the asynchronous validation after 500ms. The namespace is used to prevent replacing validations added by
// other modules.
titleInput.validateAsync(validateTitle, /* delay: */ 500, /* namespace: */ 'myModule');
});
});Cross wiki refactoring of links by default
Cross wiki refactoring of links is now much faster (being in a different wiki does not anymore have any specific performance impact when refactoring links) and enabled by default.
Attachment selector can use the temporary attachment store
When uploading an attachment using the attachment selector, and the attachment has savemode sets to form, new attachments are not saved directly on the document anymore.
Instead, the attachment is kept in a temporary attachment store and only persisted when the form containing the attachment selector is saved.
Temporary attachments are presented with a clock icon (
) when presented in the attachments selection modal.
Improved PDF Template
The default PDF template provided by the PDF Export Application has now better support for multi-page export:
- the title of each exported wiki page is now included both in the content and in the table of contents (and from 14.9 final it is also styled differently in order to distinguish it from normal content headings)
- the PDF header shows the title of the "current" wiki page, i.e. the wiki page that provided the content for the current PDF page
- each exported wiki page starts on a new PDF page
Checkout the documentation for more information.
PDF Export Administration
The administration section provided by the PDF Export Application has been extended to support:
- selecting and configuring the tool used to generated the PDF
- showing the state of the PDF generator
- and since 14.9 final, setting the page ready timeout, that is the number of seconds to wait for the web page to be ready for print before aborting the PDF export
Checkout the documentation for more information.
Figure macro type configuration
Is is now possible to manually set the type of a figure macro, instead of relying on the automatic type detection feature.
New script service for URL security operations
A new script service has been introduced to allow performing security checks on URL. The script service currently provides a single method which can be used like that:
{{velocity}}
#set ($myURL = "http://xwiki.org")
#set ($safeURI = $services.security.url.parseToSafeURI($myURL))
## The URI is null if not safe.
#if ($safeURI)
## use it as an URI object.
#end
{{/velocity}}New tags right check strategy configuration
It is now possible to configure the algorithm used when checking view rights on tags (returned by the Tags API) by editing xwiki.properties.
#-# [Since 14.4.8, 14.10.4, 15.0RC1]
#-# Configure the tag selection algorithm to use.
#-# The default algorithm is "exhaustive", which check all elements (documents and tags) for view right before returning
#-# them. This exhaustive check can lead to tag clouds and tag lists being slow to compute on instances with very large
#-# amounts of tags or tagged documents (more than 5000 of elements).
#-# Note that it is advised to keep using the default implementation as much as possible, and to switch to the "unsafe"
#-# option only when all performance improvements options have been exhausted
#-# (see https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Performances/)
#-# The "unsafe" algorithm does not perform any right checks. It is approximately 10 times faster than "exhaustive"
#-# but does not provide any guarantee that the current user won't be able to view a tag he/she is not allowed to.
#-# Therefore, we cannot recommend to use it unless tags performance is critical AND tags and document references are
#-# not considered as critical information.
# tag.rightCheckStrategy.hint=exhaustive
# tag.rightCheckStrategy.hint=unsafeImproved Display of What's New
The display of the What's New Application has been improved to allow an easier differentiation between the different news items and better accessibility.
Improved required rights reporting
The reporting presented by the required rights analyzer is now just a summary of the impacted rights first, with the possibility to expand the details. This is done to prevent showing technical items to users by default.
Required rights enabled by default
The required rights check before editing is now enabled by default. It can still be disabled by changing the required rights configuration in case it is not desired or there should be any issues.
More required rights analyzers
More required rights analyzers have been implemented, warning about rights required for UI extensions, HTML via the raw macro and correctly analyzing the content and parameters for the context and cache macro.
Warning when the dimensions are larger than the selected image
A warning message is displayed to the user when the width or height of an image are larger than the dimensions of the selected image.
New source support for content and context macros
The content and context macros now have an alternative way to indicate the content to parse, which allows executing content coming from a script value. See Content Macro for more details.
PDF Internal Links
The PDF export is now generating internal links as much as possible. By internal links we mean links that make the PDF viewer scroll the target content into view rather than opening it in a web browser. The following types of internal links are supported:
- links to a fragment from the same page that is included in the PDF export (e.g. #HDescription)
- links to a fragment from another page that is included in the PDF export (e.g. /xwiki/bin/view/Other/Page#HDescription)
- links to another page that is included in the PDF export (e.g. /xwiki/bin/view/Other/Page)
Internal links that use fragment identifiers are updated automatically, before printing the content to PDF, to target the corresponding global fragment identifier that is generated by the shared id generator used when rendering multiple pages for PDF export. In other words, having multiple sections with the same name in the PDF export shouldn't cause any problems because the links that target them are updated properly.
Checkout the PDF Export Application documentation for more information.
Responsive Content in PDF Export
XWiki's user interface (UI) adapts automatically to the screen size (i.e. it's responsive), thanks to Bootstrap's grid system, and this sometimes applies even to the wiki page content. For instance the page content could be split into columns, the number of columns depending on the available screen width: a single column on extra small devices, 2 columns on small devices, 3 columns on medium and large devices. When exporting such a page to PDF the outcome can be different than what you see in view mode because the available width depends on the print page size which is different than the screen size. Starting with this version we're adapting Bootstrap's grid system for print media, in order to have a more predictable outcome:
- extra small print: anything less than A4 portrait width => should match the behaviour from extra small screens
- small print: A4 portrait up to A4 landscape => should match the behaviour from small screens
- medium print: A4 landscape up to A3 landscape => should match the behaviour from medium screens
- large print: A3 landscape and up => should match the behaviour from large screens
By default the PDF export uses the A4 print page size so it should match the behaviour from small screens. See the PDF Export Application for more information.
Icon Macro
A new icon macro has been introduced. It supports displaying an icon from the current or a chosen icon set and can thus be used to display icons that are consistent with XWiki's UI.
Increasing contrast
Some elements of the XWiki interface systematically didn't achieve the minimum contrast defined in the Web Content Accessibility Guidelines.
Instances using Iceberg - the default color theme - or no color theme, are now patched to avoid those systematic violations.
Contrast is notably higher on buttons or light texts.
Changes for the Iceberg UI:
- Navigation bar is very slightly darker
- Links are slightly darker
- Breadcrumb text is darker.
- Muted text (e.g. description of a template when creating a page, [+] to add tags, ...) is darker
- The buttons have more contrast:
- Blue buttons have a slightly darker background
- Red buttons have a darker background
- Green buttons have a darker background
- Yellow buttons have a lighter background and their text is swapped from white to black
Changes for the no-theme UI:
- The anchors in the right side drawer are darker.
- Breadcrumb text is darker.
- Muted text is darker
- The buttons have more contrast:
- Blue buttons have a slightly darker background
- Red buttons have a darker background
- Green buttons have a darker background
- Yellow buttons' text swapped from white to black
Choose the authentication service at runtime
It's now possible to choose the authentication service to use at runtime (for authenticators which support it).
