This release is not finished yet, this is a work in progress

Second milestone of the 4.2 release.

New and Noteworthy (since XWiki Enterprise 4.2 Milestone 1)

New field types for email and list of pages

Two new types of class properties have been added:

  • The Email type extends the normal String type, adding by default a validation regular expression that should accept only a valid email address
  • The Page type extends the normal DBList type, and allows to select one or more documents from the current wiki

These two new properties are still in development, and further improvements will be implemented in the next milestone.

Computed class fields

Another new type of class fields adds support for virtual values computed live from other class values, data from the database, data obtained from an external service, or practically any other source of data. These fields are non-editable and aren't stored in the database, since they only provide some wiki content that will be rendered each time such a property is displayed.

Traditionally, this kind of computation would have been written directly in the sheet used to display instances of that class, but putting it in a class field allows easier reuse of the code, since the property will be displayed in livetables, when indexing the document in Lucene, when displaying documents in an index page, and so on.

Improvements to the Extension Repository Application

We modified the extension sheet to display the release notes for all the available versions of an extension. Check for instance the release notes for the Extended TODO Application:


Improvements to Extension Manager

An administrator of a subwiki can now install XAR extension (as long as it does not require a JAR extension).

For Developers

Default custom displayers for Easier customization of the way object fields are displayed

While XWiki allowed to specify a custom display for a given field, it was impossible to change the way field types, such as DateProperty or IntegerProperty, are displayed in general. Now it is possible to define custom displayers at the farm or wiki level, which gives the administrators more power to change the look and feel of the wiki. For example, this allows to use HTML5 input types for dates and numbers, to use custom suggestions for list of users fields, or to always add a validation input for all the password field types.

To use this feature, first you need to compute a type name for your property type. This is obtained from the java class simple name, removing the Class suffix, and lowercasing. For example, for numbers the java class used is com.xpn.xwiki.objects.classes.NumberClass, with the simple name NumberClass, which gives number as the type name. For a database list, we get dblist from DBListClass.

Next, there are three places where a default custom displayer can be defined.

  1. If a document whose name is the type capitalized and suffixed with Displayer exists in the XWiki space in the current wiki, then its content is used as the default custom displayer for that type of property. For example, localwiki:XWiki.NumberDisplayer and localwiki:XWiki.DblistDisplayer.
  2. If a document whose name is the type capitalized and suffixed with Displayer exists in the XWiki space in the main wiki, then its content is used as the default custom displayer for that type of property. For example, xwiki:XWiki.NumberDisplayer and xwiki:XWiki.DblistDisplayer.
  3. If a velocity template whose name is the type suffixed with .vm exists in the current skin, then it is evaluated as the default custom displayer for that type of property. A skin file can be defined in many places, such as an attachment of a skin document, a file in a named skin on the filesystem, or a file in the templates/ directory.

If a specific class property provides custom display code in the XClass, then that code takes priority over an eventual default custom displayer for that property.

As with property custom displayers, when evaluating the display code several objects are placed in the context:

  • name is the name of the property being displayed
  • prefix is the HTML name prefix to append to an eventual input field name, and contains the XClass name, an underscore, the object number, and another underscore, for example XWiki.XWikiUsers_0_
  • object is the object owning the displayed property, an instance of the public com.xpn.xwiki.api.Object class
  • type is the target display type, one of view, edit, hidden or search

New API to manipulate log level

Several method as been added to org.xwiki.logging.LoggerManager to manipulate the log level of registered loggers.

     * Associate the passed logger to the passed log level.
     * @param loggerName the logger
     * @param level the level of the logger

   void setLoggerLevel(String loggerName, LogLevel level);

     * @param loggerName the logger
     * @return the log level associated to the logger

    LogLevel getLoggerLevel(String loggerName);

     * @return all the registered loggers

    Collection<Logger> getLoggers();


The following dependencies have been upgraded:

  • GWT 2.5 RC1
  • Selenium 2.25


  • Office Importer/Exporter encoding issues have been fixed ().


The following translations have been updated: 

Tested Browsers

Here's the list of browsers tested with this version (i.e. browsers that we've tested as working - Check the list of supported browsers):


Known issues

Backward Compatibility and Migration Notes

General Notes

You may also want to import the default wiki XAR in order to benefit from all the improvements listed above.

Always make sure you compare your xwiki.cfg and files with the newest version since some configuration parameters were 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.

API Breakages

The following APIs were modified since 4.1.3:

<clirr output here>

Get Connected