Release Notes for XWiki 6.4-milestone-1
- New and Noteworthy (since XWiki 6.3)
- For Developers
- Translations
- Tested Browsers & Databases
- Known issues
- Backward Compatibility and Migration Notes
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).
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:
Writer out = new StringWriter();
engine.evaluate(new VelocityContext(), out, "namespace", "#mymacro()")
System.out.println(out.toString())
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()")
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:
...
@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 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)
Upgrades
The following dependencies have been upgraded:
Translations
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:
Browser | Test Result | |
---|---|---|
Google Chrome 39 | Not Tested | |
Mozilla Firefox 34 | Jira Tickets Marked as Fixed in the Release Notes | |
Internet Explorer 8 | Not Tested | |
Internet Explorer 9 | Not Tested |
Here is the list of databases we support and how they have been tested for this release:
Database | Test Result | |
---|---|---|
HyperSQL 2.3.2 | Not Tested | |
MySQL 5.6.17 | Not Tested | |
Oracle 11.2 | Not Tested | |
PostgreSQL 9.3.4 | Jira Tickets Marked as Fixed in the Release Notes |
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
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 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, com.google.gwt.user.client.rpc.AsyncCallback)' has been added to an interface
org.xwiki.gwt.wysiwyg.client.plugin.macro.MacroServiceAsync: Method 'public void getMacroDescriptors(java.lang.String, java.lang.String, com.google.gwt.user.client.rpc.AsyncCallback)' has been added to an interface
New method require to clean the Velocity engines cache: