Magnolia CORE 5.5.3 fixes a cross-site scripting (XSS) vulnerability and delivers the following changes and improvements:
Changes for authors
Change template in a personalized component variant
It is now easy to change the template in a component variant. This allows you to show a text component to one audience, an image to another audience or a video to a third audience. Select the component variant and change its template to one you think works best for the target audience. A video may work best for visitors who have previously watched videos, for example.
Visitor trait values are simplified
Values in the Visitor trait are now simplified: New, Returning or Logged in. Previously this trait allowed a combination of multiple values through checkboxes which lead to confusion about the actual status of the visitor. The trait now allows only values that are mutually exclusive via a radio button.
Also, we replaced the Registered visitor value with Returning visitor. Targeting a returning user is very common use case, much more common than a registered user who has not yet logged in. With this change we hope the visitor trait matches typical personalization scenarios better out of the box. You can add the old Registered option (radio button) back in the UI with configuration if you rely on this value. The underlying functionality still exists to process the option.
|Old values||New values|
maxAge property specifies how long a visitor is considered new before being assigned the status of a returning visitor. You can set the property in
/server/filters/visitor/visitorCookies/new/maxAge. The default value is 86400 seconds (24 hours).
Component variant icon displayed
Magnolia now displays thevariant icon on any page variants that contain further component variants in the Pages app. This makes it easier to see where both levels of personalization are used.
Actions are no longer triggered twice by double-clicking
We fixed a bug which allowed an action in the action bar to be triggered twice by double-clicking. There is now a check to see if an active request exists before the action is triggered for a second time.
Changes for developers
Translation exports can include composite fields
Subfields are included if:
info.magnolia.ui.form.field.definition.CompositeFieldDefinitionis registered as a control type to export.
- The subfields have an
i18nproperty set to
See Registering additional field types for more.
Fixed an exception thrown after downloading a translation file
The PathNotFound exception bound to the
downloadTranslationFile command in the Content Translation Support module no longer shows up after downloading a translation file. The correct path is specified by the
formPath property of the new
contentTransporter node in the module.
Updated REST API libraries to fix broken JSON output
Jackson 2 is now the de facto standard for all Magnolia webapps. The problematic JSON output where
nodes unexpectedly changed to
node has been resolved. The root cause was an update to third-party RESTful libraries. The JSON output now correctly refers to
values (as opposed to the singular
Node type change for personalization component variants
The parent node type of component variant nodes was changed from
mgnl:componentVariants. This change fixes a bug where re-publishing the original page deleted all variants from public instances.
An update task migrates content in your
website workspace automatically. You must update any existing bootstrap files yourself to be able to publish component variants.
To see an example in the demo, look at the node
/travel/main/0/variants in the JCR browser.
Security-related and other changes
- Fixed a cross-site scripting (XSS) vulnerability.
- On Windows OS, light module files are now correctly detected when added to the light module folder at runtime. MAGNOLIA-6945
- Fixed the incorrect retrieval of Dublin Core asset metadata from templating functions. MGNLDAM-563
This release also comes with a number of other bug fixes and improvements. An aggregated changelog for 5.5.3 contains all the changes.
This release is a recommended update for all users of Magnolia 5.
This release includes the following new module versions:
- Campaign Publisher 1.1.1
- Community Edition 5.5.3
- Content Translation Support 2.1.7
- DAM 2.2.3
- Demo Projects 1.1.3
- Enterprise Edition 5.5.3
- Imaging 3.3.1
- Language Bundles 1.0.10
- Magnolia 5.5.3
- Pages 5.5.3
- Personalization 1.4.3
- REST Framework 1.2.1
- UI 5.5.3
- Workflow 5.6.2
How to update from earlier versions
Updating to 5.5.x from any pre-5.5 version
- Please be aware that depending on the number of versions in the version workspace, the update to 5.5.x from any version below 5.5 may take from 1 to 2 hours since all of the versions have to migrated to a new structure.
- Since the default JCR persistency layer in our bundles has changed to H2 Database Engine with the 5.5 release, please make sure that you keep the
magnolia.repositories.jackrabbit.configproperty in the
magnolia.propertiesfile set to the database you used before updating. For example, for Derby set the property as follows:
Generally, follow the standard update procedure.
- Please check Important changes for Magnolia 5.2 and 5.3 users.
- Please check how to update from Magnolia 5.2 and earlier if required.
- Please check how to update from Magnolia 4.5 and earlier if required.
Changes for 5.4.x users
The following changes apply only to the users running Magnolia 5.4 (major release) and maintenance releases 5.4.1 to 5.4.3.
CE and EE users
Add the following lines in your
magnolia.properties file. They configure a directory for loading file system resources and the file types Magnolia should observe in the classpath and reload on-change:
If you had EE Pro 5.4.x or previous and are installing EE Pro 5.5.3
Due to component personalization bringing in new features to the page editor, you must replace the widgetset in the
magnolia.properties file. Either replace or add (depending on the update path):
Derby vs. H2
If you used a previous version of Magnolia with an Apache Derby database, make sure you keep your
magnolia.repositories.jackrabbit.config setting in your
Magnolia bundles now ship with the following default setting:This setting may not be compatible with your setup.
Important changes for Magnolia 5.2 and 5.3 users
If you had STK installed
If you continue to work with STK, use the new
magnolia-enterprise-pro-stk-bundle as a basis for your project. It includes Enterprise Pro, STK and the old demo project. You get all STK functionality out of the box. Exclude the demo-project if it's in your way.
In order to enable getting an HTML excerpt in a query result, you should update the configuration files of your Jackrabbit instances. Add the two
<param/> directives within your
Add the log configuration for org.reflections
How to update from Magnolia 5.2 and earlier
To update your project, follow the standard update procedure, then make the following changes:
- 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
- If you used the DAM:
- If you have a custom jBPM workflow:
- In the
info.magnolia.module.workflow.jbpm.JbpmWorkflowManager#completeWorkItemmethod, 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#getWorkItemmethod. It was used to complete a work item for human tasks. Furthermore, the wrapper we initialize only holds the
The previously hardcoded
mgnlDataparameter is now configurable in
- In the
- If you have custom widgets or Vaadin add-ons:
- Magnolia's default widgetset was relocated to
- Update your webapps's
- Otherwise Magnolia will automatically fall back to the new widgetset but will issue warnings during upgrade, and whenever a user logs in to Magnolia.
- Magnolia's default widgetset was relocated to
How to update from Magnolia 4.5 and earlier
Posting a comment does not work
Due to the removal of deprecated code, the Commenting module does not work. We will release a new version of it soon: MGNLFORUM-296 - Getting issue details... STATUS .
The Show action in the Configuration app doesn't open the correct location
When selecting properties in a definition that are actually extended from another node in the config workspace, opening the definition in the Configuration app will not work correctly, as the underlying node/property doesn't exist. For example,
points to config:/modules/site-app/apps/site/subApps/browser/actions/addFolder/icon
but all the actions are inherited from
/modules/ui-admincentral/apps/configuration/subApps/browser via extends.
Allocate more JVM memory
Magnolia 5.5.3 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
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: Sebastian Bauch, Nils Breunese, Michael Büchele, Marcus Büttner, Andrea Castelli, Jordie Diepeveen, Shubha Gowda, Grégory Joseph, Marcus Käppi, Karsten Martin, Federico Navarro, Sathyaprakash Rao, Pierre Sandrin, Frank Sommer, Sergej Steinbach, Vivian Steller, Torsten Landmann, Richard Unger and Nickolaus Wing.