Release Notes for XWiki 6.4-milestone-1

Last modified by Thomas Mortagne on 2017/03/24

This is the release notes for XWiki Commons, XWiki Rendering, XWiki Platform and XWiki Enterprise. They share the same release notes as they are released together and have the same version.

6.4 branch is mainly dedicated to improvement and bugfixes on things introduced during 6.x and in general. This version also introduce some developer oriented improvements: allow wiki based skins to overwrite macro.vm template, allow filesystem skins indicating explicitly the skin they are inheriting from, allow any component to be injected with its ComponentDescriptor, Panels and UI extensions are now executed with the right of their author so among other things they can use APIs requiring Programming rights.

New and Noteworthy (since XWiki 6.3)

Full list of issues fixed and Dashboard for 6.4.

New Parameters for Document Tree Macro

We added 3 new parameters to the Document Tree Macro:

  • filterByClass: show only the documents that have an object of the specified type. The value of this parameter is the full name of an XWiki document that holds a class definition. For example, 'Blog.CategoryClass' can be used to show only the documents that represent blog categories.
  • openTo: the id of the node to open the tree to. All the ancestors of the specified node, up to the root of the tree, will be opened also.
  • showOnlyViewable: show only the wiki, space and document nodes for which the current user has view right. If this is set to false then the wiki, space and document nodes that are not viewable by the current user are listed in the tree using their names. The user won't be able to see their content by following their links though (the user will just be aware of their existence).


  • It's now possible to send Registration emails in HTML (by default they're sent in plain text). This is achieved by fully supporting any MIME content in the "Validation Email Content" and "Confirmation Email Content" sections of the Registration Administration UI. For example for the "Validation Email Content" field, you could use the following template to send HTML emails:
    #set ($wikiname = $request.serverName)
    #set ($host = ${request.getRequestURL()})
    #set ($host = ${host.substring(0, ${host.indexOf('/', ${mathtool.add(${host.indexOf('//')}, 2)})})})
    Subject: Validate your account on ${wikiname}
    Content-type: text/html; charset=iso-8859-1

    <p>Hello <b>${xwiki.getUserName("XWiki.$xwikiname", false)}</b>,</p>
    <p>This email address was used to register a new account on ${wikiname}. If you did not make the request, please ignore this message.</p>
    <p>In order to activate your account, please follow this link:
    ${host}${xwiki.getURL('XWiki.AccountValidation', 'view', "validkey=${validkey}&xwikiname=${xwikiname}")}</p>

See the full list of JIRA issues fixed in this release.

For Developers

Velocity changes

Remove a Velocity Engine from the cache

org.xwiki.velocity.VelocityFactory now provide an API to remove a cached Velocity Engine.

Overriding Velocimacros in wiki-based skins

It's now possible to override the macros.vm template in a wiki based skin (object property and attachment). Any modification to this template is also taken into account (the Velocity engine is recreated when the template is modified).

Cleanup unprotected namespaces

VelocityEngine automatically get rid of the passed namespace at the end of execution unless it's protected.

In practice in means that the following:

engine.evaluate(new VelocityContext(), new StringWriter(), "namespace", "#macro(mymacro)toto#end")

Writer out = new StringWriter();
engine.evaluate(new VelocityContext(), out, "namespace", "#mymacro()")


will now print


To get


you need the following


try {
  engine.evaluate(new VelocityContext(), new StringWriter(), "namespace", "#macro(mymacro)toto#end")

  Writer out = new StringWriter();
  engine.evaluate(new VelocityContext(), out, "namespace", "#mymacro()")

} finally {

Skins system improvements

Support for a new configuration file has been introduced in filesystem skins.

Right now it supports a parent property to indicate another skin to inherit from. If set to an empty value (parent=) the skin will directly inherit from the WAR; if not set at all it will behave as before which means inherit from whatever is configured in xwiki.cfg's xwiki.defaultbaseskin property.

Component Metadata Access

If your Component implementation needs to get access to its component metadata (i.e. its ComponentDescriptor) then it can get it injected automatically. For example:

import org.xwiki.component.descriptor.ComponentDescriptor;
public class MyComponentImpl implements MyComponent
   private ComponentDescriptor<MyComponent> descriptor;

   public void doSomething()
        String hint = this.descriptor.getRoleHint();

Panels executed with the rights of their author

It's now possible to write script requiring programming right in panels as long as you have programming right, same as wiki macros.

UI extensions executed with the rights of their author

What you can execute in UI extension used to depend on current document author right, it's now based on the own ui extension author.


  • Added new APIs to get all the icon themes present on the wiki, and all icons that these icon themes contain.
    $services.icon.getIconNames("Font Awesome")
  • A new parameter has been added to the get action and the plain xpage: htmlHeaderAndFooter, which add the HTML headers (<html>,<head>,<body>, etc...) and footers (</body>, </html>, etc...). It could be useful to create light popups that display only the document content without any UI.
  • XWikiAttachment now provide setAuthorReference and getAuthorReference APIs
  • org.xwiki.logging.event.LogEvent now have a getTimestamp() method returning the number of milliseconds elapsed from 1/1/1970 until logging event was created.
  • A SOLR-based implementation of the standard REST search resource has been added
  • The Solr Query parameter xwiki.supportedLocales has a new default value: the list of supported locales configured for the current wiki (where you execute the search).
  • The @Component annotation is no longer inheritable. Thus each component implementation class must now define it and not rely on it being present in some Abstract class.
  • The XWiki build now verifies that all components are correctly listed in META-INF/components.txt files and that the threading model is explicitly defined (i.e. that either @Singleton or @InstantiationStrategy(ComponentInstantiationStrategy.PER_LOOKUP) is used). If not, the build fails. A new @Component annotation parameter has been added for explicitly mentioning that a Component should not be statically registered (these components are usually used in tests). It's used as follows:
    @Component(staticRegistration = false)


The following dependencies have been upgraded:


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:

BrowserTest Result
Chrome30.pngGoogle Chrome 39Not Tested
Firefox30.pngMozilla Firefox 34 Jira Tickets Marked as Fixed in the Release Notes
IE30.pngInternet Explorer 8Not Tested
IE30.pngInternet Explorer 9Not Tested

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

DatabaseTest Result
hypersql.pngHyperSQL 2.3.2Not Tested
mysql.pngMySQL 5.6.17Not Tested
oracle.pngOracle 11.2Not Tested
postgresql.pngPostgreSQL 9.3.4 Jira Tickets Marked as Fixed in the Release Notes

For the full list of tests see this page.

Known issues

Backward Compatibility and Migration Notes

General Notes

When upgrading make sure you compare your xwiki.cfg, and web.xml files with the newest version since some configuration parameters may have been modified or added. Note that you should add so that XWiki will attempt to automatically migrate your current database to the new schema. Make sure you backup your Database before doing anything.

Issues specific to XWiki 6.4-milestone-1

  • VelocityEngine automatically get rid of the passed namespace at the end of execution unless it's protected. See Velocity section.
  • If upgrading the content in the DistributionWizard, and the upgrade is from XWiki 6.2.x or 6.3, you might get a conflict for the document Blog.BlogSheet. Unless you have done modifications to that document, please keep the new version; otherwise please keep the merged, or if not available, keep your version. For details see issue XWIKI-11450.

API Breakages

WYSIWYG's MacroService API was not previously considering a multiwiki environment. Added a few new methods:

org.xwiki.gwt.wysiwyg.client.plugin.macro.MacroService: Method 'public org.xwiki.gwt.wysiwyg.client.plugin.macro.MacroDescriptor getMacroDescriptor(java.lang.String, java.lang.String, java.lang.String)' has been added to an interface
org.xwiki.gwt.wysiwyg.client.plugin.macro.MacroService: Method 'public java.util.List getMacroDescriptors(java.lang.String, java.lang.String)' has been added to an interface
org.xwiki.gwt.wysiwyg.client.plugin.macro.MacroServiceAsync: Method 'public void getMacroDescriptor(java.lang.String, java.lang.String, java.lang.String,' has been added to an interface
org.xwiki.gwt.wysiwyg.client.plugin.macro.MacroServiceAsync: Method 'public void getMacroDescriptors(java.lang.String, java.lang.String,' has been added to an interface

New method require to clean the Velocity engines cache:

org.xwiki.velocity.VelocityFactory: Method 'public org.xwiki.velocity.VelocityEngine removeVelocityEngine(java.lang.String)' has been added to an interface

Get Connected