Release Notes for XWiki 6.4-milestone-1

Version 29.1 by Vincent Massol on 2014/12/01

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.

<insert description of release here>

New and Noteworthy (since XWiki 6.3)

Full list of issues fixed and Dashboard for <version>.

Miscellaneous

  • 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()")

System.out.println(out.toString())

will now print

#mymacro()

To get

toto

you need the following

engine.startedUsingMacroNamespace("namespace")

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

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

  System.out.println(out.toString())
} finally {
  engine.stoppedUsingMacroNamespace("namespace")
}

Skins system improvements

Support for a new skin.properties 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;
...
@Component
@Singleton
public class MyComponentImpl implements MyComponent
{
   @Inject
   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.

Miscellaneous

  • Added new APIs to get all the icon themes present on the wiki, and all icons that these icon themes contain.
    $services.icon.getIconSetNames()
    $services.icon.getIconNames()
    $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 @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)

Deprecated and Retired projects

<description of deprecated and retired projects>

Upgrades

The following dependencies have been upgraded:

Translations

The following translations have been updated: 

Tested Browsers & Databases

Performances tests compared to <last super stable version>

<a summary of the comparison with latest super stable version>

More details on <link to the test report>.

Known issues

Backward Compatibility and Migration Notes

General Notes

When upgrading make sure you compare your xwiki.cfg, xwiki.properties and web.xml files with the newest version since some configuration parameters may have been modified or added. Note that you should add xwiki.store.migration=1 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

The following APIs were modified since <project> <version - 1>:

<clirr output here>
Tags:
   

Get Connected