Changes Report

Allow to inject Javascript/CSS in Notification displayers

It is now possible to use the Skin Extension Plugin in the custom Notification displayers: this might allow to use custom javascript for the notifications.

Allow to unregister components in Extension Mojo

If you use some XWiki Maven Build Tools such as the Extension Plugin or the Packager Plugin, we introduced a new parameter disabledComponents in those mojos to allow to unregister some components during their execution.

A typical usage of such parameter can be to prevent the execution of a MandatoryDocumentInitializer, for example:

<configuration>
  <disabledComponents>
    <disabledComponent>
      <type>com.xpn.xwiki.doc.MandatoryDocumentInitializer</type>
      <role>XWiki.XWikiServerXwiki</role>
    </disabledComponent>
  </disabledComponents>
</configuration>

Solr multi-core

It's now possible to "reserve" a dedicated Solr core for the specific storage needs of an extension. See Solr Search Application for more details.

SuperAdmin and Guest configuration

The configuration properties for the Guest and SuperaAdmin virtual users can now be overridden. This is achieved by modifying the xwiki.properties file.

For example:

user.preferences.superadmin.editor = Wysiwyg
user.preferences.guest.editor = Text
user.preferences.guest.displayHiddenDocuments = 1

On MySQL, the character set utf8mb4 is now set on the main database for new instances installed via our debian packages.

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.