Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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).

...

  1. Get the Migration Tool for Converting Vaadin Framework 7 Projects to Vaadin Framework 8 from https://github.com/vaadin/framework8-migration-tool .
  2. While on the README at the URL, read how to install and use the tool and run it.
  3. 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
languagexml
<dependency>
  <groupId>com.vaadin</groupId>
  <artifactId>vaadin-server</artifactId>
  <version>7.7.6</version>
</dependency>

to 

Code Block
languagexml
<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

(lightbulb) To be able to use the new Vaadin 8 features, add also the following dependency:



Code Block
languagexml
<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.

(warning) 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.
  • (warning) 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 the marketing-tags workspace.
  • Any content tag, used by the Tags app, is a tag node type and is stored in the tags 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
languagexml
<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 log4j2.xml to avoid confusion.

Do a basic library check:

...

...

log4j-slf4j-impl (the slf4j implementation is now provided by Log4j 2)

Warning

Make sure you don't have slf4j-log4j12-1.7.7.jar. Having both installed leads to unpredictable behavior.

...

If in doubt about your config, you may set the level of Log4j's status-logger to debug as follows:

Code Block
languagexml
<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
anc-known-issues
anc-known-issues

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
languagebash
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
languagebash
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
languagebash
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. (warning) This issue only affects the upgrades to Magnolia 5.6.6.

...

Other issues

For other known issues please see the Known issues page.

...