Page History
...
Code Pro |
---|
magnolia.repositories.jackrabbit.config=WEB-INF/config/repo-conf/jackrabbit-bundle-derby-search.xml n your magnolia.properties file. |
Old Content API removal
With Magnolia 5.6 we have removed the old content API in some of our modules. For more details see the Removal of old Content API subpage.
Vaadin 8 and custom modules
If you are upgrading from a pre-5.6 branch to the 5.6 branch, please follow the steps below to make sure that your custom modules are compatible with the UI in the 5.6 branch. The first Magnolia release in this branch uses Vaadin 8.1.5 (see Vaadin 8.1.5 release notes and API docs).
...
- Get the Migration Tool for Converting Vaadin Framework 7 Projects to Vaadin Framework 8 from https://github.com/vaadin/framework8-migration-tool .
- While on the README at the URL, read how to install and use the tool and run it.
- The tool automatically changes the imports of the affected classes and thus – in the majority of cases – will make your module(s) compatible with Vaadin 8.
...
Change the vaadin-server
dependency from
Code Block | ||
---|---|---|
| ||
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-server</artifactId>
<version>7.7.6</version>
</dependency> |
to
Code Block | ||
---|---|---|
| ||
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-compatibility-server</artifactId>
<version>8.1.5</version>
</dependency> |
The full list of compatibility packages available for Framework 8:
vaadin-compatibility-server
vaadin-compatibility-client
vaadin-compatibility-client-compiled
vaadin-compatibility-shared
vaadin-compatibility-themes
To be able to use the new Vaadin 8 features, add also the following dependency:
Code Block | ||
---|---|---|
| ||
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-server</artifactId>
<version>8.1.5</version>
</dependency> |
Please see also the links in the Further reading section for additional information on upgrading from Vaadin 7 to Vaadin 8.
Vaadin widget sets
Vaadin7WidgetSet
If you have your own widgetset, then you need to inherit the Vaadin7WidgetSet
:
- Either annotate the UI class as such with
@Widgetset("com.vaadin.v7.Vaadin7WidgetSet")
,
Or do it in your GWT configuration file by adding
<inherits name="com.vaadin.v7.Vaadin7WidgetSet" />
.
MagnoliaProWidgetSet vs MagnoliaWidgetSet
Magnolia Enterprise Edition Pro
If you had Enterprise Edition Pro 5.4.x or previous and are installing Enterprise Edition Pro 5.6.x, you have to replace the widget set in the magnolia.properties
file due to component personalization bringing in new features to the page editor. Either replace or add (depending on the update path):
Code Pro |
---|
magnolia.ui.vaadin.widgetset=info.magnolia.widgetset.MagnoliaProWidgetSet |
Enterprise Edition Standard and Community Edition
Both the Enterprise Edition Standard and the Community Edition use the MagnoliaWidgetSet
:
Code Pro |
---|
magnolia.ui.vaadin.widgetset=info.magnolia.widgetset.MagnoliaWidgetSet |
Centralized Dependency Management for third-party modules (BOM)
...
The BOM feature was made available for the first time in Magnolia 5.5.7. For further information on how to use a BOM in your project, please see the BOM for third-party modules page.
...
The Standard Templating Kit (STK) was deprecated on September 15, 2017, reaching the end of life on December 31, 2018.
The
...
MTK is aimed at the increasing number of front-end developers who looked for something leaner and less time-consuming. It is front-end framework agnostic, which means that you can integrate it with any modern framework such as Bootstrap or Foundation.
Since the release of Magnolia 5.6 we no longer produce preconfigured bundles and webapps with the STK based demo. If you still rely on the STK, see how to add STK to your bundle.
Publishing vs Activation and custom commands
The 5.6 branch brings the Publishing module pack (see publishing
on Git) which replaces the Activation module ( /modules/activation
) and the Transactional Activation module ( /modules/exchange-transactional
). Besides giving a more logical ordering to the publishing functions in Magnolia, the new module pack also sets all workspaces as publishable by default. For an overview and comparison please see Publishing and activation.
The publishing and activation modules cannot be used side-by-side in Magnolia.
Upgrading to publishing
If you used activation before the upgrade and wish to use the new publishing module pack, you have to:
- Remove both the activation modules.
- Add all modules from the
magnolia-publishing-parent
to your bundle, either manually as pre-built jars or as dependencies. - Check that after the upgrade the
subscribers
were correctly migrated from/server/activation
to/modules/publishing-core/config/receivers
. - Rewrite your custom activation commands to be compatible with the modules of the new publishing module pack.
For further information about configuring the new publishing-core
module see the Publishing module page.
Continue using activation
Using activation in the 5.6 branch is still possible, but only after replacing the bundled Publishing and Publishing Transactional modules with the Activation module and the Transactional Activation module, respectively. You can do this in two ways:
- Remove all the publishing JARs from the
../WEB-INF/lib
folders of your author and public instances. Add the activation JAR files in their place. - Exclude the publishing dependencies from the POM and add the old activation dependencies.
See also Publishing and activation.
Tags vs marketing tags
The introduction of content tagging in Magnolia 5.6 has had an effect on node type and workspace names:
- Any marketing tag, used by the Marketing Tags app, is a
marketing-tag
node type and is stored in themarketing-tags
workspace. - Any content tag, used by the Tags app, is a
tag
node type and is stored in thetags
workspace.
The magnolia.properties file
Check your magnolia.properties
file for the presence of the following lines which configure a directory for loading file system resources and the file types Magnolia should observe in the classpath and reload on-change:
...
Code Block | ||
---|---|---|
| ||
<SearchIndex> <!-- more params here --> <!-- needed to highlight the searched term --> <param name="supportHighlighting" value="true"/> <!-- custom provider for getting an HTML excerpt in a query result with rep:excerpt() --> <param name="excerptProviderClass" value="info.magnolia.jackrabbit.lucene.SearchHTMLExcerpt"/> </SearchIndex> |
log4j2.xml update
Apache Log4j 2 is an upgrade to Log4j that brings in significant improvements for logging configurations. If you currently have a customized log4j config you must migrate your log4j configuration.
...
- Start with the new
log4j2.xml
that Magnolia provides and customize it to your needs. - Or take you current configuration file and follow the official guide.
...
Update your magnolia.properties (log4j.config) to point to the new file.
Tip |
---|
We recommend the new file be called |
Do a basic library check:
...
...
log4j-slf4j-impl
(the slf4j implementation is now provided by Log4j 2)
Warning |
---|
Make sure you don't have |
...
If in doubt about your config, you may set the level of Log4j's status-logger to debug as follows:
Code Block | ||
---|---|---|
| ||
<Configuration status="DEBUG">
... |
ClientErrorInterceptor not available
...
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.
WebDAV
...
Magnolia WebDAV module is deprecated in the 5.7 branch. Deprecation means that we stop bundling the WebDAV module with the product. You can still get the code from our Nexus repository but we don't recommend using it anymore. The deprecated status lasts for one year. On June 20, 2019 we will remove the module from the product completely and donate it to the community on the Magnolia Forge.
The purpose of the module was to access the Magnolia repository through the WebDAV API, typically allowing users to edit resources and templates on the file system.
Technology used in the module is obsolete:
- The WebDAV module depends on an old HttpClient 3.x library which has reached end of life.
- Jackrabbit 2.16 removed the HttpClient3-based WebDAV API completely on May 16, 2018.
Here are common WebDAV module use cases and more modern ways to do the same thing:
...
To access DAM assets on the file system, for example with Photoshop:
Put assets that you need to edit often such as logos and banners into a light module, commit the light module into Git, and clone it to a local file system.
Put assets that you need to edit only once such as product images into the DAM.
removal
...
To upload multiple documents into the DAM:
...
Use the zip upload.
...
Create a local folder and a custom import command that ingests files from the folder.
...
Anchor | ||||
---|---|---|---|---|
|
Known issues
H2 does not accept more than one connection
Our default configuration does not use server mode. Therefore, if you try to initiate a backup call using CLI or REST, it fails because H2 does not allow more than one connection at a time. This is a new issue in Magnolia (most likely due to H2 or Jackrabbit updates).
A temporary workaround is to make H2 run in server mode and adding AUTO_SERVER=TRUE
in the URL parameters:
<param name="url" value="jdbc:h2:${wsp.home}/db;AUTO_SERVER=TRUE" />
<param name="url" value="jdbc:h2:${rep.home}/version/db;AUTO_SERVER=TRUE" />
Green screen applauncher
If after upgrade or installation you experience a "green-screen" upon login (i.e. all apps are missing from the launcher) then most likely you have a module in your classpath which has not been migrated as part of the Vaadin 8 upgrade. In the log you will see "Definition not found" warnings due to the UI Framework not being able to start normally. This can be an issue when using third-party or add-on modules. Please read Vaadin 8 and custom modules.
Cannot access magnolia.nexus
If you get the following error,
Code Block | ||
---|---|---|
| ||
Cannot access magnolia.nexus (https://nexus.magnolia-cms.com/content/groups/staff) and the artifact info.magnolia.boms:magnolia-external-dependencies:pom:5.6-SNAPSHOT has not been downloaded from it before. -> [Help 1] |
please do the following, which will remove the snapshot artifacts from your local maven directory:
Code Block | ||
---|---|---|
| ||
mvn dependency:purge-local-repository -DmanualInclude="info.magnolia:magnolia-module-content-dependencies,info.magnolia.javascript-models:magnolia-module-javascript-models,info.magnolia:magnolia-module-forum,info.magnolia:magnolia-module-rssaggregator,info.magnolia.definitions:magnolia-definitions-app,info.magnolia.restclient:magnolia-rest-client-parent,info.magnolia.restclient:magnolia-rest-client-app,info.magnolia.restclient:magnolia-rest-client,info.magnolia.restclient:magnolia-resteasy-client,info.magnolia.publishing:magnolia-publishing-parent,info.magnolia.publishing:magnolia-publishing-app,info.magnolia.publishing:magnolia-publishing-core,info.magnolia.publishing:magnolia-publishing-receiver,info.magnolia.publishing:magnolia-publishing-sender" |
Now, you have to fetch the dependencies from Nexus. The easiest way would be to do:
Code Block | ||
---|---|---|
| ||
mvn dependency:resolve |
Allocate more JVM memory
Magnolia 5.6 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 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,
/.magnolia/admincentral#app:definitions-app:;app~site@subApps/browser/actions/addFolder/icon:treeview
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.
XML exports open directly in the browser instead of offering a download
When you click the Export button in a content app or from the JCR Tools app, the XML opens directly in the browser, replacing the AdminCentral instead of showing the usual Download dialog from the browser. This issue only affects the upgrades to Magnolia 5.6.6.
...
Other issues
For other known issues please see the Known issues page.
...