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 7.1)

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

Nested Pages

It's now possible to create wiki pages inside other wiki pages. More specifically we've decided to drop the concept of Space in the UI (it's still there at the API/platform level) and instead, to replace it with the concept of Nested Pages.

We've also decided to drop the concept of Parent/Child relationship since it was too complex for end users to have 2 hierarchies: the Space/Page hierarchy and the Parent/Child hierarchy. The Parent/Child hierarchy also had limitations: you couldn't inherit page permissions for example. Thus the idea is to have a single hierarchy based on Nested Pages.

Advantages of Nested Pages:

  • The URL reflects the page hierarchy
  • Finer-grained control: Ability to set permissions at each level
  • Generally speaking, a nicer and simpler way to organize your content hierarchically
  • Moving and Deleting pages updates the hierarchy

Terminology:

  • Nested Page (a.k.a Non-Terminal Page): This is a wiki page that can have children pages. Technically a Nested Page is implemented as a Nested Space (i.e. a WebHome page).
  • Non-Nested Page (a.k.a Terminal Page): This a wiki page that cannot have children pages. Applications and script can create Terminal Pages. Advanced Users will also be able to create Terminal Pages from the UI. Standard Users will only be able to create Nested Pages.
  • Nested Space: A Space which has another Space as parent. As mentioned above, a Nested Page is technically implemented as a Nested Space. You will used the term Nested Space when speaking technically about XWiki APIs for example but when talking about UI you should favor using the term Nested Page instead.

For more information, see Content Organization.

Script right

A new Script Right has been added to allow controlling who has the right to write Scripts. Specifically anyone with Edit rights can edit a page and write a Script in it. However, when the page is rendered the script will only execute if the last author of the page has the Script right.

scriptright.png

Example when the author of a script doesn't have the Script right:

scriptRightsErrorNotAllowed.png

Miscellaneous

<insert misc user stuff and important bug fix descriptions here in a list, when they are too small to warrant a section by themselves - Change the version in the URL below!>

  • When a space home page has an empty title (and the space home page doesn't have a sheet or the sheet doesn't control the title) then the displayed title is now the space name instead of 'WebHome'.
  • The Document Tree Macro has a new parameter called showSpaceAsDocument which allows you to merge the space nodes with the space home page nodes.
  • The list of available template providers is now sorted by document full name.
  • The Orphaned Pages tab from the Document Index is now displayed only when the Parent-Child Hierarchy Mode is enabled (which is not the case by default).

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

For Developers

Nested Spaces

Since Nested Spaces were already planned and supported in APIs like DocumentReference there are not too many changes for those who were using recent APIs but there is still some and here are the main ones.

Space Reference instead of Space name

The heart of the implementation is that the field that used to contain the unique document space now contain the possibly Nested Space Reference. In practice it means that:

  • "." (dot), ":" (colon) and "\" (baskslash) characters, which are part of a Space name will now be escaped (using the "\" character) in the space (XWD_WEB) field from the Document's table in the Database. For example a space named Space:with.special\char will be stored as Space\:with\.special\\char.
  • Same as for the database, the XWikiDocument/Document#getSpace() methods now return a serialized Reference to the Space instead of what used to be the unique Space name (basically it return what's in the database). Same logic for XWikiDocument#setSpace(). Those field have been deprecated a long time ago but they are still used in lots of places...
  • Various APIs are also affected by this Space name to Space Reference input change:
    • XWiki#getSpaceDocsName methods (both in the public and private XWiki API)
    • All the default XWikiURLFactory implementation methods accepting a Space as parameter have been modified to accept a serialized Space Reference. Extensions/code implementing XWikiURLFactory (or extending classes implementing XWikiURLFactory such as XWikiServletURLFactory) will need to be modified to handle nested spaces passed in the space parameter of the various APIs. Here's how to parse Spaces passed as a String:
      private EntityReferenceResolver<String> relativeEntityReferenceResolver =
          Utils.getComponent(EntityReferenceResolver.TYPE_STRING, "relative");
      ...
      or
      ...
      @Inject
      @Named("relative")
      private EntityReferenceResolver<String> relativeEntityReferenceResolver;
      ...
      private List<String> extractSpaceNames(String spaces)
      {
          List<String> spaceNames = new ArrayList<>();
         // Parse the spaces list into Space References
         EntityReference spaceReference = this.relativeEntityReferenceResolver.resolve(spaces, EntityType.SPACE);
         for (EntityReference reference : spaceReference.getReversedReferenceChain()) {
              spaceNames.add(reference.getName());
         }
         return spaceNames;
      }
    • Extensions/code implementing ExportURLFactoryActionHandler will also need to be modified to handle nested Spaces passed in the space parameter.
  • Extensions/code implementing EntityReferenceSerializer or DocumentReferenceResolver must now handle Nested Spaces (in the past they were already supposed to handle Nested Spaces but since it was not used they could take shortcuts and it wasn't visible. It's now going to fail, see XWIKI-12191).

Space separator properly taken into account

The Reference syntax specification was already indication that "." was supposed to be escaped in the space part of the Reference but it was not really taken into account so not escaping it was not making any difference. This is now fixed in the various standard String Reference resolvers so a Reference that don't follow the specification and did not escaped the "." in the space part will be cut is several nested spaces. Anything that was serialized with one of the standard serializers was properly escaped so not worry here, the issue will be more for hand written or hardcoded String References.

New XAR format

To support exporting/importing nested spaces some changes has been made to the XAR format. The format remain upward and downward compatible (except that you won't get nested spaces in your < 7.2 instance obviously).

Two new attributes has been added to the <xwikidoc> root XML element

  • reference: the complete local Reference of the document in standard Reference format. <web> and <name> are deprecated (but still set). <web> keep containing the (unescaped) space name when there is only one space and will contain the space Reference when there is several (when imported in a < 7.2 instance a document exported from a nested space will end up in a space having as name the space reference).
  • locale: the locale of the document. <language> is deprecated. It was not technically needed in the context of nested spaces but it makes having the Reference as attribute more consistent. It also make getting all the entries from a new format XAR easier and faster since document space and name would be placed anywhere in the document.

REST module

  • The REST module now supports Nested Spaces. Example of url to access the page A.B.C.MyPage: /xwiki/rest/wikis/xwiki/spaces/A/spaces/B/spaces/C/pages/MyPage.

URL modules

The URL modules have been modified to support Nested Spaces. As a consequence the URL formats supported by the standard URL scheme have been modified.

New Rename/Delete Jobs

New code has been developed to support Nested Documents/Nested Spaces and Script Services have been provided and they now run inside Jobs to better handle the fact that they are long-running operations.

However you can start to test this by using the following Script Services APIs:

  • Copy a Space
    #set ($source = $services.model.resolveSpace('Path.To.Source'))
    #set ($destination = $services.model.resolveSpace('Path.To.New.Parent'))
    $services.refactoring.copy($source, $destination).join()
  • Copy a Space As
    #set ($source = $services.model.resolveSpace('Path.To.Source'))
    #set ($destination = $services.model.resolveSpace('Path.To.New.Name'))
    $services.refactoring.copyAs($source, $destination).join()
  • Move a Space
    #set ($source = $services.model.resolveSpace('Path.To.Source'))
    #set ($destination = $services.model.resolveSpace('Path.To.New.Parent'))
    $services.refactoring.move($source, $destination).join()
  • Move a Document
    #set ($source = $services.model.resolveDocument('Path.To.Source.WebHome'))
    #set ($destination = $services.model.resolveSpace('Path.To.New.Parent'))
    $services.refactoring.move($source, $destination).join()
  • Rename a Space
    #set ($source = $services.model.resolveSpace('Path.To.Source'))
    $services.refactoring.rename($source, 'NewName').join()
  • Rename a Document
    #set ($source = $services.model.resolveDocument('Path.To.Source.WebHome'))
    $services.refactoring.rename($source, 'NewName').join()
  • Delete a Document
    #set ($source = $services.model.resolveDocument('Path.To.Source.WebHome'))
    $services.refactoring.delete($source).join()
  • Delete a Space
    #set ($source = $services.model.resolveSpace('Path.To.Source'))
    $services.refactoring.delete($source).join()
  • Convert a Terminal Document to a Nested Document
    #set ($source = $services.model.resolveDocument('Path.To.Page'))
    $services.refactoring.convertToNestedDocument($source).join()
  • Convert a Nested Document to a Terminal Document
    #set ($source = $services.model.resolveDocument('Path.To.Source.WebHome'))
    $services.refactoring.convertToTerminalDocument($source).join()

New create action parameters and logic

The create action now accepts a spaceReference parameter and a name parameter, together with an optional tocreate=terminal parameter (usable on non-terinal documents). The previous space parameters was not scalable in the context of Nested Spaces since it was just a top-level space name so it did not allow the creation of deeper space levels. More details are available in the create action's documentation.

These logic is now also available in the improved create UI, with the terminal pages option appearing only for advanced users and being checked or unchecked by default, depending on the type of the current document:
createUINestedDocuments.png

New Reference-related APIs

Various new API around References has been introduced while adding support for nested spaces.

Complete References Providers

Complete References Providers (for DocumentReference, SpaceReference and WikiReference) with default or current hints. They allow getting complete Reference created from each default or current part of those references (for example in SpaceReference you end up with the space of the XWikiContext document and the XWikiContext wiki)

@Inject
Provider<DocumentReference> defaultDocumentReference;

@Inject
@Named("current")
Provider<DocumentReference> currentDocumentReference;

org.xwiki.model.reference.EntityReferenceProvider

org.xwiki.model.reference.EntityReferenceProvider replaces org.xwiki.model.reference.EntityReferenceValueProvider. It's essentially the same thing but with EntityReference instead of string which allow getting multiple spaces when you ask for the current EntityType.SPACE for example.

@Inject
EntityReferenceProvider provider;

Properly support any kind of References in getDocument and getURL

com.xpn.xwiki.XWiki#getDocument(EntityReference) and com.xpn.xwiki.api.XWiki#getDocument(EntityReference) support any kind of Reference properly (e.g. a Space Reference will return the space home page, an Object Reference will return the Object Document Reference, etc).

Same for com.xpn.xwiki.XWiki#getURL(EntityReference) and com.xpn.xwiki.api.XWiki#getURL(EntityReference).

New helpers in EntityReference

  • boolean equals(EntityReference otherReference, EntityType to): same as equals but only take into account Reference parts up to the passed entity type (included)
  • boolean equals(EntityReference otherReference, EntityType from, EntityType to): same as equals but only take into account Reference parts between passed entity types (included)
  • boolean equalsNonRecursive(EntityReference otherReference): same as equals but does not take into account the parent

New helpers in LocalDocumentReference

  • LocalDocumentReference(String pageName, EntityReference spaceReference): allowed created a LocalDocumentReference from a Space Reference instead of just the space name

org.xwiki.model.reference.SpaceReferenceResolver

New default String and EntityReference based SpaceReferenceResolver has been added. It's the same behavior then DocumentReferenceBehavior but for spaces.

@Inject
SpaceReferenceResolver<String> stringResolver;

@Inject
SpaceReferenceResolver<EntityReference> referenceResolver;

New model Script Service helpers

  • new help to escape an entity name according to default Reference syntax as in:
    $services.model.escape('some.space:with\specialchars', 'SPACE')

    will print

    some\.space\:with\\specialchars
  • you can retrieve a node from an EntityReferenceTree using its reference:
    #set ($alice = $services.model.resolveDocument('wiki:Users.Alice.WebHome'))
    #set ($bob = $services.model.resolveDocument('wiki:Users.Directory'))
    #set ($tree = $services.model.toTree($alice, $bob))
    #set ($usersNode = $tree.get($bob.lastSpaceReference))

New components to generate REST URLs

  • The component RestURLGenerator has been added. Its role, in the long terme, is to generate a REST URL for any kind of EntityReference. It currently handles DocumentReference and SpaceReference.
  • The corresponding script service has been added: $services.rest with the method $services.rest.url($entityReference).

Resolve nested spaces in JavaScript

var spaceReference = XWiki.Model.resolve('A.B.C', XWiki.EntityType.SPACE);
spaceReference.getReversedReferenceChain().map(function(entityReference) {
 return entityReference.name;
}).join(' > ');
// Produces: A > B > C

See the JavaScript API documentation for more details.

New readonly XWikiContext provider

You can inject a new "readonly" XWikiContext the following way:

@Inject
@Named("readonly")
Provider<XWikiContext> roXWikiContextProvider;

The difference with default provider is that the readonly one won't try to create a new XWikiContext and will return null if it can't find any. It's been introduce for some low level components that were used during XWikiContext creation but in general it should be used by any component that only search for some XWikiContext property that might be null even in a valid XWikiContext.

Deprecated and Retired projects

<description of deprecated and retired projects>

Upgrades

The following dependencies have been upgraded:

Miscellaneous

  • Objects, attachments and the document's class are now clearly not considered content, but metadata. Thus, any change in these will set the document's (XWikiDocument) metadataDirty flag to true and not touch the document's contentDirty flag unless there is an actual change in the document's content or title fields. This is also in line with the original intent of the contentAuthor document field. The direct impact of this is that the contentAuthor field will be updated only when the content is changed and thus the programming/script rights of a document will be changed much less often than before and much less by accident.
  • custom Maven properties which have a special meaning (like xwiki.extension.features) are not duplicated in Extension custom properties anymore
  • standard fields names have been added to org.xwiki.extension.rating.RatingExtension
  • URL configuration now use default ConfigurationSource provider instead of only xwiki.properties one which means it's possible to overwrite properties for each wiki among other things
  • Added ability to set and change the URL scheme to use in the Execution Context. This allows code to dynamically change the generated URLs when Rendering a document (useful when performing an Export for example).
  • Started a new filesystem URL Scheme for exporting Resources to the filesystem and generating URLs to them (useful for the HTML Export for example). At the moment, only the webjars Resource Type is using it and all other Resource Types are using the old XWikiURLFactory class.
  • A new DocumentModelBridge.getContentAuthorReference() method has been added to allow accessing the content author of a document without depending on oldcore.
  • Deprecate XWiki.parseContent(...) since it is was misleading and outdated. Its documentation mentioned that the passed content is parsed as velocity code, but it was actually doing much more than that and had some unwanted side-effect. Instead, use the parse/renderer that is specific to the type of content you have. See more details in XWIKI-12299.
  • A new script service is available to retrieve the status of a specified job or the status of the currently running job from a specified group. See the Job Module documentation for details.

Translations

The following translations have been updated: 

Tested Browsers & Databases

Performances tests compared to 6.4.5

There hasn't really been much performance work on this version so we get mostly the same result than in 7.1 release note. The important point here was to check if nested spaces ha much impact on performances.

Summary

"similar": difference is lower than 10%
"slightly": difference is lower than 20%

Note hat most of the speed related values are an average of very moving results, a lot of things is happening during a HTTP request and it's far from stable duration (that's why 10% may sounds a lot for something called "similar" but the variable can go up and down around 5% sometimes so 10% average is really not that much of a clear win).

Speed

ActionsDifference
Jetty startupsimilar
First accessnot existing page without UIsimilar
not existing page with UIsimilar
Reloadnot existing page without UIsimilar
not existing page with UI20% faster
Main.WebHome with UI20% faster
Main.WebHome without UI30% faster
SOLRFull SOLR reindexsimilar
SOLR sync when index is emptysimilar
SOLR sync when there is nothing to dosimilar
Result of search finding lots of results25% faster
Result of search finding one result20% faster
RenderingPage with 1000 macros without UI/34
Page with 1000 html macros without UI/6

Memory

ActionsDifference
Heap Memory after jetty startupsimilar
Heap Memory after full SOLR index+50MB

More details on performance comparison on single wiki between 7.2 and 6.4.5.

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 7.2

<issues specific to the project>

API Breakages

The following APIs were modified since XWiki 7.1:

<clirr output here>
Tags:
   

Get Connected