Magnolia 5.6 reached end of life on June 25, 2020. This branch is no longer supported, see End-of-life policy.

Page tree
Skip to end of metadata
Go to start of metadata

This release supersedes Magnolia 5.6.4. The previous release contained a reference to a snapshot version by mistake.

A new version of the REST delivery endpoint brings a number of useful features that make it easier to connect front-end javascript apps, external systems or implement other headless scenarios in Magnolia.

You can now request a specific language to return. For a content item that references other items, you can now get direct URLs to them. If the referenced item is an asset, you can get the URL to the asset in the size that you need via the asset renditions.

The new Tour Finder in the travel demo uses the REST delivery endpoint to demonstrate a single-page app in Magnolia.

This release also expands on the problem reporting introduced in 5.6.3 to help developers maintain clean projects. Now any missing or deprecated page templates or themes referenced by a site are reported. A new Deprecated level in the Definitions app Problems view helps developers find and review deprecated items easily.

Changes for developers

Tour Finder

The Magnolia Travel demo project now ships with the Tour Finder, a demonstration of a JavaScript-based single-page application (SPA) in Magnolia that showcases REST Delivery endpoint API v2. The Tour Finder page uses three Delivery endpoint configurations (tours, tourTypes, destinations). In response to the visitor's choices, it instantly refreshes a list of tours without reloading the web page.


Requesting a localized variant of an item

When sending a REST request to the delivery endpoint v2, you can use the lang parameter to specify which language variant you want returned in the response. Sending lang=all fetches all language variants available in the JCR repository.

In parallel to the lang parameter, you can also request a specific language version by setting and sending the Accept-Language header with the request. For more information, see Requesting localized content with the delivery endpoint.


Referencing assets, creating links to items and to asset renditions

Another improvement to the delivery endpoint v2 is that you can create relative links to any referenced item and you can also reference assets. If a referenced asset resides in the Magnolia DAM, the asset resolver can generate links to asset renditions (variations).

In addition, if Dublin Core metadata exists for an asset, the resolver returns this in the response. For more information, see Resolving references with the delivery endpoint.


Multiple REST endpoints

In the delivery endpoint v2 JcrDeliveryEndpointDefinition class you can configure not just one but several endpoints. For more information, see Delivery endpoint API v2 configuration.


REST results are unsorted by default

Until now the results provided by the delivery endpoint were sorted alphabetically on node names (same as with the ORDER BY LOWER(NAME(t)) statement in the JCR-SQL2 query) even though no orderBy parameter was set in the request URL.

With delivery endpoint v2, the results are returned unsorted. This however does not mean "in natural order" since many other aspects may be involved, such as the setting of the respectDocumentOrder property or index consistency. For more information, see Apache Jackrabbit Search and Rebuilding the Index


The orderBy parameter works without the direction attribute

Previously, setting the orderBy parameter in a REST request without specifying the sort direction produced an error. This has been fixed in this release. If no direction is specified (asc or desc), the system applies asc.


This Magnolia release also comes with an important bugfix for developers of light modules. The existing contents of a directory linked via a symbolic link is now reloaded by Magnolia when you add the link to a running Magnolia instance.


Reporting of deprecated and non-existing definitions from site definitions

The Definitions app now reports references to non-existing and deprecated page template and theme definitions referenced from site definitions.

(warning) Even though the Definitions app shows the sites registry, you cannot define or decorate a site via YAML.


Fixed full text search of documents

Indexing and full text search of documents works again as expected after we upgraded third-party dependencies for Apache POI and Apache Commons Compress.




See the 5.6.4 changelog and the 5.6.5 changelog for all the changes. 

If you are upgrading from an earlier version, read the Upgrading to Magnolia 5.6.x page first and check the Known issues section on it.

Updated modules

Please be aware that the version numbers for the Magnolia main and UI projects are not in sync with the version number of this release. 

If you are updating from an earlier version:
Projects based on an older maven archetype may not build correctly starting with Magnolia 5.6.3 - because the version of the Magnolia main modules is not the same as the Magnolia bundle anymore. If you experience a problem, please update your project parent pom.

  • Community Edition 5.6.5
  • Content Editor 1.1.4
  • Content Tags 1.0.2
  • Definitions app 1.1.2
  • Demo Projects 1.2.3
  • Enterprise Edition 5.6.5
  • Form 2.4.1
  • Groovy 2.6.2
  • Jackrabbit Backup 2.2.2
  • LDAP support 1.10
  • Magnolia 5.6.4
  • Multisite 1.3.3
  • Pages 5.6.3
  • Personalization 1.5.2
  • Publishing 1.0.3
  • REST Client 1.5.2
  • REST Framework 2.1
  • Site 1.2.2
  • Synchronization 1.8.2
  • Templating Essentials 1.2.1
  • Third-party library BOM 5.6.3
  • UI 5.6.3
  • UI 5.6.4
  • Weblogic 2.2


The Magnolia team would also like to thank everyone who reported issues, contributed patches, or simply commented on issues for this release. Your continued interest helps us make Magnolia better. Special thanks go to: Espen Jervidalo, Bret Lederle, Pietro Pagani, Christophe Rodriguez, Frank Sommer and Tom Wespi.

  • No labels


  1. Great work on the REST framework!

    Could you please keep the external-dependencies bom and the core in sync with the bundle version? It's not really clear for some people that you need to use the bundle-parent 5.6.5 with the external-dependencies 5.6.3. This makes the pom.xml kinda messy (problem since 5.6.3).

    1. Hi Jordie,

      I understand the difficulties, but they have separate lifecycle. Otherwise for every change in bom or core or bundle we would need to release all of it again ... and do the pre-release QA and all the other tasks that are necessary. Or in some cases we would end up releasing boms w/o actually making any changes in them which would mess up things as well for those looking for what was changed or in which version they became out-of-date.

      We will think of improving the process to make it more obvious, but currently going to releasing everything every time is not an option.

      Thank you for your understanding.



      1. Hi Jan,

        I just found out that the bundle-parent also contains the correct version for in the external-dependencies in the dependency-management part. So we can use the external-dependencies without setting the version:



        1. Perfect. Thanks for sharing!

        2. Apparently the bundle-parent already have the following dependency included in their dependency-management:

              <!-- Importing dependency management from 3rd parties -->

          So, it seems that explicitly adding the external-dependencies to our parent pom.xml is not needed at all because it's already included through the bundle-parent.