Magnolia 5.6 reached end of life on June 25, 2020. This branch is no longer supported, see End-of-life policy.
Magnolia 5.6.3 fixes a critical bug in the Multisite module: MULTISITE-84 - Getting issue details... STATUS . Please skip Magnolia 5.6.2 and go directly to Magnolia 5.6.3.
This release introduces a mechanism to mark YAML-based definitions as deprecated. It helps you discover faster if a definition you depend on has been deprecated in favor of a better replacement.
You can see usages of the deprecated definitions in Definitions app. Check the app for problems every time you update Magnolia. We will use the new deprecation markup in Magnolia modules – we recommend you do the same to help developers who consume definitions from your modules.
In this release we also ship a sticker to visually identify your Magnolia instances. The sticker is displayed in AdminCentral next to your user name. Use it to label your instances by environment and type so that users can immediately tell where they are working: in "DEV author" or "PROD public 1" for instance. This popular suggestion reduces confusion and helps you avoid making the mistake of editing something in a wrong instance.
We also introduce a new filter to add HTTP response headers. An example shows how to support cross-origin resource sharing. CORS is particularly useful in a headless scenario where an external web page requests content from your Magnolia instance.
Finally, we fix a cross-site scripting vulnerability in STK and remind you that STK is now deprecated. It's time to retire any STK based sites and start fresh with your favorite front-end framework backed by MTE.
You can configure a sticker to clearly show in AdminCentral what type of instance and environment authors and developers are currently working in. Minimize the risk of accidental, unwanted or even harmful edits in AdminCentral, especially in complex chain-production installations.
Enable and configure the sticker using the following two properties in the configuration of Magnolia:
magnolia.ui.sticker.environment=LIVE magnolia.ui.sticker.color=#9A3332
This Magnolia release puts back the Select all checkbox in the Pulse:
The feature was removed with the release of Magnolia 5.6 due to decreased memory performance when the checkbox was used on extremely large datasets.
Beginning with this release, you can configure the maximum number of items the checkbox may select using a new property: /modules/ui-admincentral/config/pulse/selectAll@threshold
. By default, the checkbox selects a maximum of 1 000 items.
You can disable the checkbox by adding the enabled
property to its configuration and setting it to false
.
The introduction of the new info.magnolia.config.source.yaml.construct.WrapMetadata
construct allows you to deprecate YAML-based definitions. You can mark a YAML-based definition as deprecated like this:
deprecated: !metadata since: 5.5.6 description: The dialog uses the deprecated PlaceholderTextFieldDefinition. Please use the placeholder property instead.
The deprecated definition is displayed in the Definitions app:
The app reports the following deprecated or non-existing items:
In this release of Magnolia, the app does not yet report the following deprecations:
Three additional filter operators are now implemented in the REST delivery endpoint API: ne
, in
and not-in
. For a full list of supported operators and filter formats see filter options.
The new info.magnolia.cms.filters.AddHeadersFilter
implementation class allows you to configure a filter for adding HTTP headers to enable, for example, Cross-origin resource sharing (CORS).
You can now download a preconfigured Apache Tomcat servlet container that does not come with any Magnolia webapp. Use it to combine a specific Magnolia webapp with Tomcat without worrying about the configuration of the servlet and the selected webapp.
To create correct URIs to resources, the info.magnolia.module.resources.ResourceLinker
class of the Resources module and info.magnolia.multisite.MultiSiteResourceLinker
of the Multisite module do not add language prefixes such as en
or de
into the URI.
When you publish a deletion of a YAML configuration file hotfix, the original configuration is now correctly reloaded at YamlConfigurationSource#loadAndRegister
.
The following converter classes do not extend com.vaadin.v7.data.util.converter.Converter
anymore:
info.magnolia.ui.form.field.converter.IdentifierToPathConverter
info.magnolia.ui.form.field.converter.BaseIdentifierToPathConverter
info.magnolia.ui.form.field.converter.StringToCalendarConverter
Migrate your custom converters to extend the new info.magnolia.ui.form.field.converter.FieldValueConverter
.
.resources
URLMagnolia CORE 5.6.3 fixes a bug we found in the Multisite module shortly after releasing Magnolia CORE 5.6.2: a slash is incorrectly appended to the .resources
URL if the webapp is located under the Tomcat root.
The search improvements we implemented in the website
workspace ( MAGNOLIA-6188 ) affect the indexing performance of all workspaces. Therefore, the generic indexing configuration used for all workspaces /info/magnolia/jackrabbit/indexing_configuration.xml
has been deprecated.
The default indexing configuration is now stored in /info/magnolia/jackrabbit/indexing_configuration_default.xml
and should be used for all workspaces except the website
workspace. The website
workspace has its own separate configuration in /info/magnolia/jackrabbit/indexing_configuration_website.xml
.
It's possible to create your own targeted indexing configurations on a per workspace basis. See Search Index Configuration File for details on available options.
If you are updating to Magnolia 5.6.3 we recommend that you set the indexing configuration in each workspace.xml
configuration file to the default configuration using the indexingConfiguration
parameter:
<param name="indexingConfiguration" value="/info/magnolia/jackrabbit/indexing_configuration_default.xml"/>
When creating a compressed ZIP backup using the backup script in command line, you must now specify where you want to create the zip backup file.
To do so, you must use -z
with the new -zp
( --zipPath
) flag with a path to the zip backup file as the argument.
See the 5.6.2 changelog and the 5.6.3 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 even though this release is called Magnolia CORE 5.6.3, all but three modules in this release are taken from the 5.6.2 release and their version numbers remain unchanged. The three modules that have been updated and their version numbers increased in the 5.6.3 release are displayed in bold.
If you are updating from an earlier version:
Projects based on an older maven archetype may not build correctly - 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 .
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: David Caviedes Marquez, Thomas Duffey, Soisik Froger, Marc Johnen, Robert Kowalski, Philip Mundt, Adrien Sauvez and Tom Wespi.
9 Comments
Pierre Sandrin
The release seems to not yet be in the nexus repository. I can see 5.6.2 but not 5.6.3. When will it be available?
Christoph Meier
Hi Pierre
The artifacts should be there, for instance see https://nexus.magnolia-cms.com/content/repositories/magnolia.public.releases/info/magnolia/bundle/magnolia-community-demo-bundle/5.6.3/
What exactly are you missing or looking for?
Pierre Sandrin
Hi Christoph
I'm looking at https://nexus.magnolia-cms.com/#view-repositories;magnolia.public.releases~browsestorage and under info->magnolia->magnolia-core I can see 5.6.2 but not 5.6.3. It does not help to log in.
Also when running mvn install on a 5.6.3 Project i get:
...
Downloading: https://nexus.magnolia-cms.com/content/groups/public/info/magnolia/magnolia-core/5.6.3/magnolia-core-5.6.3.pom
...
[WARNING] The POM for info.magnolia:magnolia-core:jar:5.6.3 is missing, no dependency information available
Christoph Meier
Dear Sandrin
As it was written above on this page.
(The message was a bit "hidden" in a "expand box" - I have it moved out of that box now.)
Only the 2 bundle projects
- Community Edition 5.6.3
- Enterprise Edition 5.6.3
plus Multisite 1.3.2
have been released.
All the other modules have the same numbers as released with Magnolia 5.6.3
Hence, info.magnolia:magnolia-core:jar:5.6.3 does not yet exist.
ok?
Pierre Sandrin
Yes, I got it. I had a dependency to magnolia-core with the version 5.6.3 in my module. I removed the version because it's defined in the bundle and now it takes magnolia-core 5.6.2 and works fine.
Thanks a lot Christoph!
By the way: The dependancy was created by the Maven archetype for a module. Remove it, if you use it with this release. Otherwise you will run into this issue.
Ronald Ten Berge
Can you also release the magnolia-external-dependencies artifact with version 5.6.3?
Christoph Meier
Dear Roland
magnolia-external-dependencies:5.6.3
has not been released.Only the 2 bundle projects
- Community Edition 5.6.3
- Enterprise Edition 5.6.3
plus Multisite 1.3.2
have been released with the 5.6.3 release.
All the other artifacts have the same numbers as released with Magnolia 5.6.2
ok?
Michele Cervini
I've experienced a huge slow down of the time needed to startup the tomcat bundle of 5.6.3 CE release, compared to 5.6.1 CE bundle.
After some investigations I've noticed that starting from the 5.6.3 version, the workspace.xml of all the workspaces have the url of the persistence manager with the AUTO_SERVER property set to TRUE.
By disabling this h2 feature the startup process was reduced from 8 minutes (unusable for me in dev phase) to 96 seconds (as usual).
Now comes my question: does turning the AUTO_SERVER feature off has some drawback, given the changes made in 5.6.3 regarding the indexing (separate configuration for every workspace)?
Thank you!
David Caviedes Marquez
Hello,
related to Separateindexingconfigurationfiles:
is it not necessary to also recommend to update indexingConfiguration in jackrabbit-*-search-xml files?
Regards