Magnolia 5.3 reached end of life on June 30, 2017. This branch is no longer supported, see End-of-life policy.

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

What's new?

Fixed publishing and unpublishing of segments and personas

Publishing and unpublishing of segments and personas including child nodes was failing. The fix involves changing the supertype (node type) of personas and segments from mgnl:contentNode to mgnl:content. The fix also removes any incorrectly created nodes from the mgnlVersion workspace. This will lead to a loss of versions of personas and segments.

Publication with Java updates 1.7.0_85 and 1.8.0_65

Java updates 1.7.0_85 and 1.8.0_65 introduced strict validation of HTTP header field values. Colon (:) is no longer an allowed character, as specified inHTTP 1.1. This change broke the publishing action in Magnolia since we passed a message header that contained mgnl:deleted. The issue was fixed by renaming the value to mgnl-deleted.

Symptom: You see the following error when you publish content in Magnolia running on Java 1.7.0_85 / 1.8.0_65 or later.

ERROR dule.exchangetransactional.TransactionalSyndicator: Failed to activate content.
info.magnolia.cms.exchange.ExchangeException: java.lang.IllegalArgumentException: 
Illegal character(s) in message header field: mgnl:deleted

If you cannot publish content or a client reports this issue to you, please check if automatic Java updates are enabled on your system. It is possible that your system got updated to the latest Java version automatically before your Magnolia installation was ready.

You can either roll back the Java update or update to Magnolia 5.3.12 now. We advise all clients who plan to update to the latest Java maintenance release to first update their Magnolia installations.

Bootstrapping content into cluster nodes

A new property magnolia.repositories.jackrabbit.cluster.master identifies a Magnolia instance as a cluster master node. During installation and update Magnolia bootstraps content only into master nodes. This ensures that other (replica) nodes installed later don't override already bootstrapped content.

Example: Public instance A is defined as a cluster master node. The instance starts and creates a clustered forum workspace and bootstraps some content such as rules of conduct. Second public instance B is defined as a replica node. It starts moments later but does not bootstrap the same workspace again.

Usage: Add the new property to your magnolia.properties file and set its value:

  • true defines the instance as a master node. Content is bootstrapped.
  • false defines the instance as a replica node. Content is not bootstrapped.
magnolia.properties
magnolia.repositories.jackrabbit.cluster.config=WEB-INF/config/repo-conf/clustered-jackrabbit-bundle-mysql-search.xml
magnolia.repositories.jackrabbit.cluster.master=true

(warning) Always define the cluster.config and cluster.master properties together as shown above if any of your workspaces are clustered.

Related topics:

Cache header negotiation

Cache headers for first request after cache flush and future requests are now consistent. 

Response content types

The MIME type for JavaScript was changed to be uniform through the whole Web. Magnolia now uses application/javascript instead of the obsolete application/x-javascript.

You can now use the ContentTypeFilter to validate the MIME type of responses. The feature is disabled by default and can be configured in the Content type filter.

Other

An aggregated change log for 5.3.12 contains all the changes.

Should I update?

This release is a recommended update for all users of Magnolia 5.3.

Updated modules

This release includes the following new module versions: 

  • Activation 5.3.4
  • Cache 5.3.3
  • Enterprise Edition 5.3.12
  • Forms  2.2.14
  • Imaging 3.1.5
  • Magnolia 5.3.12
  • Personalization 1.1.4
  • Resources 2.3.6
  • UI 5.3.12 
  • XA Activation (exchange-transactional) 2.2.3

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: Casper Biever, Piotr Bojdoł, Mariusz Chruscielewski, Thomas Duffey, Joerg Von Frantzius, Rory Gibson, Rico Jansen, Chris Jennings, Pietro Pagani, Frank Sommer, Steve Surace, Marek Swiecznik, Edgar Vonk and Tom Wespi. 

How to update from Magnolia 5.3.11 and earlier

Follow the standard update procedure.

How to update from Magnolia 5.2 and earlier

To update your project, follow the standard update procedure, then make the following changes:

  1. Update your content apps with the content app upgrade task. It automatically takes care of the following:
    • Using the content connector.

    • Updating configuration of availability rules and default rule classes

    • Updating selected action definitions with node-type based availability

  2. If you used the DAM: 
    • Replace DamManager with AssetProviderRegistry.
    • See DAM and the STK and DAM templating on how to use assets in your templates.
    • The DAM changes have no impact on the STK. There is no need to modify Freemarker scripts because the new DAM API is abstracted from STK.
  3. If you have a custom jBPM workflow:
    • In the info.magnolia.module.workflow.jbpm.JbpmWorkflowManager#completeWorkItem method, checking for present parameters is obsolete and refers to publication related workitems. The method is no longer used for completing a workitem in the new human task context. It is still valid in the context of completing service tasks, however.
    • Stop using the info.magnolia.module.workflow.jbpm.JbpmWorkflowManager#getWorkItem method. It was used to complete a work item for human tasks. Furthermore, the wrapper we initialize only holds the mgnlData map.

    • The previously hardcoded mgnlData parameter is now configurable in /modules/workflow/commands/workflow/activate/activate/parameterMapName.

  4. If you have custom widgets or Vaadin add-ons:
    • Magnolia's default widgetset was relocated to info.magnolia.widgetset.MagnoliaWidgetSet.
    • Update your webapps's magnolia.properties file.
    • Otherwise Magnolia will automatically fall back to the new widgetset but will issue warnings during upgrade, and whenever a user logs in to Magnolia.

How to update from Magnolia 4.5 and earlier

Are you running on Magnolia 4.5 or earlier? It’s time to move to version 5. Contact us for migration support and look at the migration process.

Known issues

Magnolia 5.3.12 ee-bundle may require you to allocate more memory the Java Virtual Machine (JVM). If you see a java.lang.OutOfMemoryError in the startup log or the system stops responding during installation, increase the Java heap size. The default maximum heap size is 512M. Try a higher amount such as 1024M. We are working on uncovering the root cause for the increased memory need; see Java out of memory.