The new delivery endpoint provides direct access to specific content through the REST API. The content can be pages, components, stories or anything else stored in a workspace. You can define an endpoint with a few lines of YAML. The response is concise JSON, designed to meet the needs of front-end developers.
Content tags make new ways of finding and re-using content possible. Tag similar content items for personalized targeting or tag current items for periodic campaigns. You can render content based on tags and consume tagged content via REST. Tagging is quick and modern – the system autocompletes as you type.
Changes for authors
- The Tags field autocompletes tags as you type.
- Tags app let's you delete and rename tags and see where a tag is used.
tagfntemplating functions let you consume tagged content in templates.
Once tagging is enabled for a content app, authors can quickly create and apply tags by selecting item(s) and using a simple keyboard shortcut T or the Add tags action to open the tagging dialog.
You can search through your content on the basis of tags using the
tag: prefix in any search field, as well as see all the places any given tag is used thanks to the Tags app.
Workspace and node type changes
- Any marketing tag, used by the Marketing Tags app, is now a
marketing-tagnode type and is stored in the
- Any content tag, used by the Tags app, is a
tagnode type and is stored in the
Publishing replaces activation
While still available for use in the 5.6 branch, the original Activation module has been refactored into the Publishing module. The corresponding extension module Transactional Activation module has also been refactored into the Publishing Transactional module. This refactoring brings transparency to the configuration of publishing content from the author instance to the public instance. For more information see Publishing and activation.
Since the Publishing module is now the default option provided with Magnolia bundles and webapps, see Upgrading to Magnolia 5.6.x: Publishing vs Activation and custom commands before migrating to Magnolia 5.6.
Virtual URI mappings subapp deprecated
The Virtual URI mappings subapp, a part of the About app, has been deprecated. Virtual URI mappings were so the default virtual URI mappings used in Magnolia modules have been updated as well, see Mapping classes . Use the Definitions app instead to view the mappings, since mappings can now be configured as YAML files or as nodes in JCR.
Google Analytics module deprecated
The Google Analytics module has been deprecated and removed from EE bundles. The module has modern replacements: Google Universal Visualization Analytics and Marketing Tags (module and app), which together provide the same functionality. Another reason for the deprecation of the module is that it used obsolete technology, namely third-party plugins that are no longer actively maintained.
Nevertheless, we keep the dependency in the EE parent POM for backward compatibility and to provide a smooth transition for customers who still depend on the old Google Analytics module.
OAuth 2.0 available as an SMTP authentication method
Google considers every application that doesn't authenticate over the OAuth 2.0 to be less secure (see New Security Measures Will Affect Older (non-OAuth 2.0) Applications), so the Mail module and app have been upgraded to support also the OAuth 2.0 method.
Changes for developers
Easy REST with new delivery endpoint
The UI in Magnolia 5.6 is built on Vaadin 8.1.5 (see Vaadin 8.1.5 release notes and Vaadin 8.1.5 Java API docs). Since the upgrade to Vaadin 8 may affect the way your custom modules work, please read Vaadin 8 and custom modules before upgrading.
ClientErrorInterceptor removed from the REST client
ClientErrorInterceptor does not exist in RESTeasy 3, its capabilities were removed from our client implementation, the REST client module.
Commenting and Forum modules not bundled
Commenting and Forum modules are no longer included in Magnolia bundles. The reason is simply that fewer Magnolia customers using these modules anymore. The number of new JIRA issues entered against the modules started to taper off couple of years ago:
We also put the modules into maintenance mode, which means we continue to fix bugs but we do not make any improvements or add new features. Maintenance mode typically lasts for a year after which we deprecate the modules in line with our Deprecation policy.
If you are looking for commenting or forum services, you have several options:
- Magnolia commenting service – Magnolia offers a basic commenting service in the cloud. It's a REST-based service hosted by Magnolia International. The service is secure, contains no advertising, works also for intranet sites and avoids having to cluster the comments in a multi-instance setup. You can connect the service to an on-premises or cloud Magnolia instance. See a live example on Magnolia's own blog. Contact Magnolia Services if you are interested in this option.
- Third-party integration – Most Magnolia sites today choose to integrate a third-party commenting or forum system. There are several on-premises and hosted services on the market such as Disqus, IntenseDebate and Discourse. Forum services have evolved to support features such as badges, reputation management and search engine optimization that are beyond what the Magnolia Forum module offers today.
- Legacy modules – You can still get the Magnolia Forum and Commenting modules from Nexus for your own Magnolia bundles. The Forum module also requires the magnolia-core-compatibility .jar to be in the classpath to function properly.
No more STK bundles and webapps
We no longer provide STK-based webapps and bundles. Standard Templating Kit (STK) was deprecated on September 15, 2017 and will reach end of life on December 31, 2018.
The replacement for STK is Magnolia Templating Kit (MTK). MTK is quicker to learn than STK and requires fewer skills. MTK is aimed at the increasing number of front-end developers who looked for something leaner and less time-consuming. MTE is front-end framework agnostic, which means you can integrate it with any modern framework such as Bootstrap or Foundation.
If you still rely on STK, see how to create a custom webapp with STK modules yourself.
BOM for third-party modules
Previously, dependency management information about third-party modules was defined in the parent POMs of
magnolia.ui. You may now optionally use a software BOM (Bill of materials) project instead. The project can then be imported in all modules. This ensures that the versions of the third-party modules are the same.
For more details about BOM and how to use it in your project please see the BOM for third-party modules page.
Virtual URI mapping classes
Since virtual URI mappings have been relocated to the Virtual URI module, all of the following mapping classes now also implement VirtualUriMapping:
See also Mapping classes.
Apache Log4j 2 is an upgrade to Log4j that brings in significant improvements for logging configurations. If you currently have a custom Log4j config file then you will need to migrate it to the new format of version 2. For more details, see the log4j2.xml update section in Upgrading to Magnolia 5.6.x. Alternatively, you can use the compatibility bridge until you have time to migrate.
Content API removed
Despite being deprecated in Magnolia 4.5 (see the links at bottom of the page), the so-called "old Content API" continued to live and some Magnolia modules were still using it. With Magnolia 5.6 we've begun removing the old content API from our modules. See Removal of old Content API for details about what we have done and what you need to know if you are upgrading custom bundles with custom modules.
See the 5.6 changelog for all the changes.
- Activation 5.6
- Advanced Cache 1.9
- Blossom 3.2
- Cache 5.6
- Categorization 2.6
- Commenting 2.4
- Community Edition 5.6
- Contacts 1.6
- Content Dependencies 1.8
- Content Editor 1.1
- Content Tags 1.0
- Content Translation Support 2.2
- DAM 2.3
- Definitions app 1.1
- Demo Projects 1.2
- Diff 2.0
- Enterprise Edition 5.6
- External Forms 1.4
- Form 2.4
- Forum 3.7
- Google Sitemap 2.5
- Groovy 2.6
- Imaging 3.4
- In-place templating 2.4.5
- Jackrabbit Backup 2.2
- Jcr Tools 1.2
- LDAP support 1.9.2
- Log Tools 1.1
- Magnolia 5.6
- Mail 5.5
- Marketing Tags Manager 1.3
- Multisite 1.3
- Observation 2.1
- Pages 5.6
- Password Manager 1.2
- Personalization 1.5
- Public User Registration 2.7
- Publishing 1.0
- Publishing Transactional 1.0
- Resources 2.6
- REST Client 1.5
- REST Framework 2.0
- RSS Aggregator 2.6
- Site 1.2
- Soft Locking 2.7
- Standard Templating Kit 3.1
- Synchronization 1.8
- Task Management 1.2.3
- Templating Essentials 1.2
- Templating Samples 5.4
- Third-party library BOM 5.6
- Tools 1.9
- UI 5.6
- Vaadin Compatibility Addons 1.0
- Workflow 5.7
- XA Activation (exchange-transactional) 2.5
Change in the URL path for documentation
The URL path for documentation now always includes the version of the current major release. For example, documentation for Magnolia 5.6 is available at https://documentation.magnolia-cms.com/display/DOCS56/, not at https://documentation.magnolia-cms.com/display/DOCS/. Page requests for the old URL (DOCS) will be redirected as page requests for Magnolia 5.6 documentation.
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 Pieter Ardinois, Sven Bach, Michael Büchele, Grégory Joseph, Jarkko Mantysaari, Nicole Stutz and Sebastian Tauch.
Extra special thanks go to Richard Unger for submitting the initial update of the Log Tools app.