Changes Report

VFS content type

It's now possible to explicitly indicate the Content-Type to return with the HTTP response containing the file. See VFS API for more details.

Support targeting groups in Notifications

Using a TargetableEvent in the Notification API now allows to target also Groups and not only Users anymore.

Exclude Heading in Include/Display Macros

It's now possible to exclude the heading from an included page for both Include and Display macros, if the first element of that page is a heading.

Ability to hide macro parameters in WYSIWYG

Thanks to the introduction of a new @ProperyDisplayHidden annotation that can be placed on Macro parameter classes, it's now possible to hide the parameter inside the WYSIWYG's Macro editor. This is useful to hide complex parameters that should only be used in wiki edit mode for example.

Example:

public class IncludeMacroParameters
{
...
    /**
     * @param type the type of the reference
     * @since 3.4M1
     */
    @PropertyDescription("the type of the reference")
    @PropertyGroup("stringReference")
    @PropertyAdvanced
    // Marking it as Display Hidden because it's complex and we don't want to confuse our users.
    @PropertyDisplayHidden
    public void setType(EntityType type)
    {
        this.type = type;
    }

    /**
     * @param page the reference of the page to include
     * @since 10.6RC1
     */
    @PropertyDescription("The reference of the page to include")
    @PropertyDisplayType(PageReference.class)
    @PropertyFeature("reference")
    // Display hidden because we don't want to confuse our users by proposing two ways to enter the reference to
    // include and ATM we don't have a picker for PageReference types and we do have a picker for EntityReference string
    // one so we choose to keep the other one visible and hide this one. We're keeping the property so that we don't
    // break backward compatibility when using the macro in wiki edit mode.
    @PropertyDisplayHidden
    public void setPage(String page)
    {
        this.reference = page;
        this.type = EntityType.PAGE;
    }
}

Mail Obfuscation APIs

There are now 2 new APIs related to Email Address Obfuscation:

• API to get whether or not email addresses should be obfuscated. Scripting example:

  #if ($services.mail.general.shouldObfuscate())
  ...

• API to obfuscate an email address. Scripting example:

  $services.mail.general.obfuscate('[email protected]')

Deprecated Mail Script Services

The $services.mailsender and $services.mailstorage Script Service entry points have been deprecated in favor of $services.mail.sender and $services.mail.storage.

Mail Address Conversion

There's now a Converter to convert from a String to an InternetAddress and vice versa. It's especially important since we've modified the User API's get/setEmail() to use an InternetAddress. This allows using Velocity scripts that call APIs accepting an InternetAddress by passing a string. For example:

$services.user.properties.setEmail("[email protected]")

Mail Address HTML Displayer

An HTML Displayer for email addresses (i.e. objects of type javax.mail.internet.InternetAddress) has been added (it displays the email address obfuscated if obfuscation is on). It's not used anywhere but can be called. Scripting example:

{{velocity}}
#set ($email = $services.user.properties.email)
{{html}}
$services.display.html.display('javax.mail.internet.InternetAddress', $email)
{{/html}}
{{/velocity}}

Configuration permissions

It's now possible to implement permission checking for ConfigurationSource properties, to decide who has the rights to view or modify them. To implement this check for your ConfigurationSource component, you need to implement the ConfigurationSourceAuthorization component role.

Configuration modifications

There's now a setProperties() API to modify ConfigurationSource properties. Scripting example:

{{groovy}}
import org.xwiki.configuration.*

def cs = services.component.getInstance(ConfigurationSource.class, 'mailsend')
cs.setProperties(['host' : 'localhost'])
println cs.getProperty('host')
{{/groovy}}

More locale-oriented APIs

We deprecated Document#getTranslationList() in favor of the new Document#getTranslationLocales() so if you have Velocity scripts using $doc.translationList you'll notice a deprecation warning in the server logs which you can avoid by using $doc.translationLocales instead.

We also added XWiki#getAvailableLocales() so you can now replace

$xwiki.getXWikiPreference('languages').split('\s*[|, ]\s*')

with $xwiki.availableLocales in your Velocity scripts.

New experimental event store

A new Solr based event store has been introduced. It's still disabled by default (will be enabled as soon as the user notification use case is fully refactored to use it) and meant to be used more and more to replace the current Hibernate based event and event status store.

Configuration option to disable in-place editing

A new configuration option is available in xwiki.properties to disable the in-place editing of plain wiki pages.

#-# [Since 12.5]
#-# Indicate if the XWiki documents should be edited in-place, without leaving the view mode, whenever possible (e.g. if
#-# the default edit mode for that document and the preferred editor both support in-place editing). When enabled,
#-# clicking on the document Edit button makes the document title and content editable in-place, without leaving the view
#-# mode. When disabled, clicking on the document Edit button loads the default (stand-alone) edit mode for that
#-# document.
#-#
#-# The default is:
# edit.document.inPlaceEditing.enabled = true

Toggle Rendered Diff Context

You can now use the "Show context" toggle button to show / hide all the unmodified parts of the page rendered content when comparing two versions of a wiki page from its history. Check the user guide for more information.

User Avatar macro with user picker

When inserting the User Avatar macro from the WYSIWYG editor you can now select the target user with a user picker.

JMX Monitor of Apache DBCP and Hibernate

JMX Monitoring of Apache DBCP and Hibernate are now enabled by default.

Comment form not displayed by default

The comment form is now hidden by default. This allows improving the loading performance of XWiki pages and makes the UI less cluttered.

A button allows you to display the comment form when you need to add a new comment.

Add a Solr store for ratings

It is now possible to store Ratings information in a Solr core: this should improve the scalability of the extension. Please note that the migration of data from one store to another is not yet supported.

Non-minified Javascript

Non-minified versions of JavaScript files are now also bundled by default in XWiki. This makes it much simpler to debug JavaScript issues in production. Just look for the non-minified (source) code using the developer tools provided by the browser. Since the minified code indicates the source map and the source map indicates the source file, the browser ends up loading all 3 (when the developer tools are open). If you can't find the source code then you can force the browser to load it by reloading the current page with ?minify=false in the URL.

New Comment button

The comments section at the bottom of pages used to have the comment editor visible. There's now a Comment button to click when wanting to add a comment. This was done for 3 reasons:

• For consistency with other actions where you have to click a button to do them (annotate, edit, create, etc).
• It makes the UI a bit less cluttered and avoids focusing the attention on comments which was very visible, especially since we moved to using the WYSIWYG editor by default in comments.
• It also improves the loading performance of XWiki pages since the editor doesn't need to be loaded when viewing pages