Known issues

This page contains information about common issues you may encounter during system installation or use. If you are upgrading to the 6.2 branch, see also Upgrading to Magnolia 6.2.

For additional clarification or help, contact Magnolia support.

Systems

Tomcat

Unable to log in with an SSO/OpenID setup

Starting with Magnolia 6.2.10, in your Tomcat configuration, make sure that the CookieProcessor component does not have the sameSiteCookies property set to strict. Instead, set the property to Lax:

<CookieProcessor sameSiteCookies="Lax" />

This supports OpenID top-level redirects while maintaining decent protection against cross-site request forgery (CSRF).

Before Magnolia 6.2.10, Lax was only supported in setups that do not use HTTPS behind a proxy (MAGNOLIA-8112). If that is your case, delete the following line from your Tomcat configuration to make sure that CookieProcessor is not defined:

<CookieProcessor sameSiteCookies="…" />

This approach is less optimal in that there is risk that the effective policy is decided by more recent versions of the browsers themselves, which may lead to unexpected issues.

Server configuration with relaxedQueryChars

Advanced query filters in the Delivery API require extra Tomcat configuration, namely setting relaxedQueryChars="[]|".

Symptom
HTTP Status 400 - Bad Request
Message
Invalid character found in the request target [/.rest/delivery/tours/v1/magnolia-travels/Vietnam--Tradition-and-Today?mgnl:created[in]=2015-12-01~2015-12-31]. The valid characters are defined in RFC 7230 and RFC 3986
Description
The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
Exception

java.lang.IllegalArgumentException

404 error without trailing slash

When accessing the webapp without the trailing slash (http://localhost:8080/magnoliaAuthor), the user may be presented after login with a 404 page rather than Admincentral. This behavior is configurable via the mapperContextRootRedirectEnabled and mapperDirectoryRedirectEnabled attributes, which can be used to restore the previous behavior.

404 error when reloading page

When you open a page for editing and reload it in the browser, an extra semicolon is added to the URL fragment and the server returns a 404 error (MGNLUI-2426). Every subsequent reload adds another semicolon.

This issue occurs with earlier versions of the Tomcat application server. To resolve this, upgrade to Tomcat 7.0.47+.

Tomcat 8 using BCEL may throw class format exception

On Tomcat 8.5 or earlier, you may encounter a class format exception.

SEVERE [localhost-startStop-1] org.apache.catalina.startup.ContextConfig.processAnnotationsJar Unable to process Jar entry [module-info.class] from Jar [file:/home/magnolia/dev/magnolia-5.6.6/apache-tomcat-8.5.5/webapps/magnoliaPublic/WEB-INF/lib/javax.json-api-1.1.jar] for annotations
 org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 19

Reason:

Apache Commons BCEL is used by Tomcat to scan for annotations. Some Java EE 8 APIs were produced from JDK9 as multi-release JARs. This means they are compatible with Java 8, but may also contain some Java 9 classes including module-info.class. Older Commons BCEL versions do not know how to read such classes.

Tomcat 8.5.12+ updated Commons BCEL to support this. See the extract below from the Tomcat changelog.

60688: Update the internal fork of Apache Commons BCEL to r1782855 to add early access Java 9 support to the annotation scanning code.

Solution:

Use Tomcat 8.5.12 or later.

JBoss

JBoss EAP 7 java.lang.ClassCastException (Java 11.0.16+)

With JBoss EAP 7 and Java 11.0.16+, you may experience an issue filed as EAP 7 hits java.lang.ClassCastException for class org.jboss.vfs.VirtualJarInputStream after upgrading java to 11.0.16+.

In Magnolia, the error is related to the org.reflections.Reflection libraries, which we use to extract the Magnolia license. Magnolia keeps asking for the license on startup and when you introduce it, it displays "License is empty".

If you experience this issue, you can eliminate it by downgrading Java 11 to a version below 11.0.16.

JBoss 7.2 with JDK 11

If you are using JBoss 7.2 with JDK 11 to deploy Magnolia, you may get an error during installation. To resolve the issue, add the following lines to WEB-INF/jboss-deployment-structure.xml:

<deployment>
 <dependencies>
  <module name="jdk.unsupported"/>
 </dependencies>
</deployment>

MySQL JDBC 8.0.x

If you are using the MySQL JDBC driver 8.0.x to install a new Magnolia instance, you may encounter the following error:

2020-02-14 14:35:07,538 ERROR org.apache.jackrabbit.core.RepositoryImpl: failed to start Repository: org.apache.jackrabbit.core.state.ItemStateException: failed to read bundle (stacktrace on DEBUG log level): deadbeef-face-babe-cafe-babecafebabe: java.sql.SQLSyntaxErrorException: Table '<DATABASE_NAME>.<TABLE_NAME>' doesn't exist

This happens only when you install a new instance from scratch or create database tables during installation.

Solutions

  • Magnolia 6.2.14 and earlier: As a workaround, add nullDatabaseMeansCurrent=true to the DataSource url attribute or create the tables manually in your database.

  • Since Magnolia 6.2.15 and later: For MySQL Connector/J 8.x and later, use a new configuration called jackrabbit-bundle-mysql8-search.xml available in /WEB-INF/config/repo-conf/.

Oracle WebLogic

Magnolia 6.2 is not compatible with Oracle WebLogic.

OS X / macOS

Magnolia starts up very slowly

You may encounter this issue after upgrading your macOS to Sierra 10.12 or later.

Workaround:

  1. Open a terminal and figure out the hostname of your Mac. To get the hostname, use the command hostname.

    hostname
joesLittleMacBookPro.local

    The command returns the hostname of your Mac. In the given example, the hostname is joesLittleMacBookPro.local.

  2. Open the file /etc/hosts with an editor of your choice. You will edit the file in the next step.

    The file belongs to the system user root. Your user must belong to the group admin; otherwise, you cannot save the changes to the file. You will be asked for your password either when opening the file or when trying to save it.

  3. Add these two lines to /etc/hosts:

    127.0.0.1 <hostname>
::1 <hostname>

    In place of <hostname>, use your real hostname.

    Most probably, your host file already contains entries starting with 127.0.0.1 and ::1. Just add the real hostname at the end of these lines. Make sure to add a space character before the hostname.

    With the given hostname, the two lines would look like this:

    127.0.0.1 localhost joesLittleMacBookPro.local
::1 localhost joesLittleMacBookPro.local

  4. Save the file. The system may ask you for your password.

For more information, see:

Windows

Cannot publish content with path-based locking

After upgrading to Magnolia 6.2.9, it is not possible to publish content locally. The following errors can be found in the logs:

Log of the Author instance
ERROR info.magnolia.publishing.command.PublicationCommand 08.06.2021 09:42:18 – Receiver: magnoliaPublic8080, error: Unable to contact receiver, HTTP response code: 500.
Log of the Public instance
ERROR info.magnolia.publishing.receiver.operation.jcr.AbstractJcrReceiveOperation 08.06.2021 09:41:52 – UNC path is missing sharename: /\website\/
java.nio.file.InvalidPathException: UNC path is missing sharename: /\website\/

As a temporary workaround, switch the locking mode to compatibility (JCR-based) locking in the configuration of the publishing-core module:

/modules/publishing-core/config@lockManagerMode=compatibility

JVM issues

32-bit JVM does not work on Windows

When starting Tomcat with the Magnolia CLI mgnl start command, you get a flickering window, the server hangs and nothing is written into the logs. To see the actual error, do not use Magnolia CLI to start Magnolia. Instead, start Tomcat directly using <your-magnolia-install-folder>\apache tomcat\bin\catalina.bat run. This should start Magnolia in the same window and allow you to see the error message:

Error occurred during initialization of VM
Could not reserve enough space for 2097152KB object heap

The most likely cause is that you are trying to allocate too much heap space in the 32-bit JVM.

Solution:

Replace the JVM with a 64-bit version.

See also Why can’t I get a larger heap with the 32-bit JVM?
Neither JAVA_HOME nor JRE_HOME is defined

You may get the following error message after a fresh Java installation:

Neither the JAVA_HOME nor the JRE_HOME environment variable is defined
At least one of these environment variables is needed to run this program

Solution:

Set the variables through the Edit the system environment variables dialog.

JRE_HOME is undefined

If you get the following error:

The JRE_HOME environment variable is not defined correctly
The environment variable is needed to run this program

You are most probably attempting to run Tomcat with a set JAVA_HOME variable but without a defined JRE_HOME variable.

Solution:

Set the JRE_HOME variable.

Firewall is blocking Java

Allow an exception in Windows Firewall for Java.

  1. Go to Control Panel > Windows Firewall.

  2. Go to the Exceptions tab.

  3. Click Add Program and browse to the java.exe file in the Java installation directory (for example, C:\Sun\SDK\jdk\bin\java.exe).

  4. Click OK.

If you get a security alert during startup, select the Private networks checkbox and click Allow access.

Windows firewall

CATALINA_HOME environment variable is not defined

The CATALINA_HOME environment variable identifies the Tomcat home directory (for example, C:\Program Files\magnolia\apache-tomcat). Usually, Magnolia finds this directory automatically. When you type magnolia_control.bat start in the bin directory to start the system, a second script named startup.bat tries to find Tomcat home. It assumes that Tomcat home is one level above the bin directory where you issued the command and sets the value of CATALINA_HOME to that directory.

C:\Program Files
    magnolia
        apache-tomcat <-- Tomcat home directory
            bin <-- magnolia_control.bat is here

However, if you added the bin directory to your PATH environment variable, you can execute magnolia_control.bat from anywhere. This means startup.bat will not find the Tomcat home directory by simply moving up one level from where you are and will display the following error:

CATALINA_Home not defined

To solve this, define CATALINA_HOME in environment variables. Follow the instructions at Neither JAVA_HOME nor JRE_HOME is defined.

JAR file does not start

When installing DX Core on Windows, you can start the installer by double-clicking the JAR file. If this does not work, there is a chance that some application on your system has registered the .jar extension.

You can try to fix it yourself by restoring the association of the .jar extension with the javaw.exe file. Right-click the JAR file and select Open with (typically, javaw.exe is in C:\Program Files (x86)\java\jre6\bin). Alternatively, start the installer from a command prompt using java -jar magnolia-dx-core-installer-x.y.z.jar. Make sure the file extension is .jar (Internet Explorer has a tendency to append or change it to .zip).

Other issues

Concurrency issues in JS Models 2

When using version 2.x of the JavaScript Models module, you may observe that the render cycle unreliably fails but still results in 200 responses.

This issue comes from the fact that when the GraalVM Context is accessed concurrently, it will sometimes try to access that context from a different thread, which is an illegal access.

The issue should disappear after you upgrade the GraalVM dependencies to version 23.0.2 (or higher).

Depending on the JDK you use, you may also need to modify your JDK profile by adding --add-exports=jdk.internal.vm.compiler/org.graalvm.compiler.options=ALL-UNNAMED to the value of the <argLine> element.

Security issue in tiffcrop

tiffcrop, a program distributed by the libtiff package, contains a security flaw that has been registered as CVE-2023-1916.

Depending on the underlying OS type and version, Magnolia ships a library that might or might not leverage tiffcrop.

Until a fix is released by the provider of the underlying OS, we recommend that you remove the plugin that might call the vulnerable library. If you decide to remove the plugin, Magnolia’s functionality will only be impacted in the way it processes TIFF images.

If you wish to have the TIFF processing unimpacted, you should contact the OS vendor for a fix of the issue or implementations of other mitigating measures, such as making sure that any TIFF image that is to be uploaded to the system does not contain any code exploiting the vulnerability.

Select vendor pages dealing with the issue:

Vaadin configuration changes for Magnolia 6.2.20 or later

Due to a Vaadin update in Magnolia 6.2.20, custom setups require a change in the web.xml configuration file (in a custom webapp’s WAR under the WEB-INF/ directory). In particular, you should add the following parameters.

<context-param>
  <description>Vaadin production mode</description>
  <param-name>productionMode</param-name> (1)
  <param-value>true</param-value> (2)
</context-param>
<context-param>
  <param-name>heartbeatInterval</param-name>
  <param-value>90</param-value>
</context-param>
1 Ensure the Vaadin productionMode parameter is present.
2 The value should be true.
If you do not set productionMode to true, you’ll receive errors when starting your custom webapp showing that it’s unable to validate your Vaadin subscription.

Too many entries in JCR at the same level

In JCR (Java Content Repository) and the Jackrabbit implementation of JCR, there is no hard limit on the number of items that can exist at one level. However, the performance of the repository may degrade as the number of child items at a particular level increases.

The optimal number of child nodes per level depends on many factors, including the specific use case and the performance characteristics of the underlying storage system.

In general, to ensure smooth performance, it is recommended to limit the number of child nodes to a few hundred or less at each level.

Script to split flat structures into folders

folderSize = 100
workspace = "tours"
nodeType = "mgnl:content"
rootPath = "/magnolia-travels/"
query = "select * from [" + nodeType + "] WHERE ISDESCENDANTNODE('" + rootPath + "')"
session = MgnlContext.getJCRSession(workspace);
manager = session.getWorkspace().getQueryManager();
nodes = manager.createQuery(query, "JCR-SQL2").execute().nodes;
folderName = 0
nodesInFolder = 0
while (nodes.hasNext()) {
    folderPath = rootPath + folderName
    NodeUtil.createPath(session.rootNode, folderPath, "mgnl:folder");
    node = nodes.next()
    newPath = rootPath + folderName + "/" + node.name;
    if (node.path != newPath) { //repeatable script
        session.move(node.path, newPath);
    }
    if (nodesInFolder++ > folderSize) {
        nodesInFolder = 0
        folderName++
    }
}
session.save()
You can still retrieve the tree structure as a list through, for example, search templating functions.
Using a balanced tree structure, you can mitigate performance issues when publishing hundreds of items at once. See the itemsPerRequest property of the publish command.
See also Q. I have too many child nodes and performance goes down (Apache Jackrabbit Wiki).

H2 database

We do not recommend using the H2 database for production environments.

Corrupted repository after restart

When using H2 version 2.1.x on Java 17, the repository can get corrupted upon shutdown.

Sample error
18-Dec-2023 12:02:08.198 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [169049] milliseconds
2023-12-18 12:21:46,165 ERROR info.magnolia.cms.security.JCRSessionOp: Error caught while loading the system user anonymous: javax.jcr.PathNotFoundException: /system/anonymous
javax.jcr.PathNotFoundException: /system/anonymous
	at org.apache.jackrabbit.core.ItemManager.getNode(ItemManager.java:576) ~[jackrabbit-core-2.20.13.jar:2.20.13]

A workaround for this issue is to update the version of H2:

  1. Override the managed version in your BOM file.

  2. Run the H2 migration script, as explained in Running the migration script.

H2 upgrades may require you to recreate the database

If you cannot start the instance after upgrading from version 1.4.x to 2.x, you must carry out the following procedure.

Running the migration script

Jackrabbit creates one H2 database per workspace, plus one for content versions in the version folder. They all need to be backed up and recreated from H2 SQL scripts, as per the H2 Upgrade tutorial, without specifying the -user parameter.

Example JDBC URLs are listed below:

  • jdbc:h2:~/<magnolia.home>/repositories/magnolia/workspaces/website/db

  • jdbc:h2:~/<magnolia.home>/repositories/magnolia/workspaces/dam/db

  • jdbc:h2:~/<magnolia.home>/repositories/magnolia/version/db

  • 1.4.x to 2.1.x

  • 2.1.x to 2.3.x

For each of these databases:

  1. Export your database into an SQL script using version 1.4.200 (or the earlier version you were using).

  2. Create a new database using version 2.1.214.

  3. Run the SQL script to restore the database, using the file created with version 1.4.200 (or the earlier version that applies in your case).

h2-db-migration.sh
#!/bin/bash
# h2-1.4.200.jar and h2-2.1.214.jar files must be present in the current working directory.
# They can be found respectively in 6.2.26 and 6.2.27 Magnolia webapps

path=/path/to/webapps/magnoliaAuthor/repositories/magnolia #repeat on public

for filepath in $(find $path -name '*.mv.db'); do
    parentdir="$(dirname "$filepath")"

    # Export data from old db file to backup.zip
    echo "Exporting database $parentdir/db..."
    java -cp h2-1.4.200.jar org.h2.tools.Script -url jdbc:h2:$parentdir/db -script $parentdir/backup.zip -options compression zip
    rm -f $parentdir/db.mv.db

# Import data from the backup.zip to the new db file
    echo "Importing data..."
    java -cp h2-2.1.214.jar org.h2.tools.RunScript -url jdbc:h2:$parentdir/db -script $parentdir/backup.zip -options compression zip variable_binary
    rm -f $parentdir/backup.zip
    echo "$parentdir/db migrated succesfully"
done

For each of these databases:

  1. Export your database into an SQL script using version 2.1.214 (or the earlier version you were using).

  2. Create a new database using version 2.3.232.

  3. Run the SQL script to restore the database, using the file created with version 2.1.214 (or the earlier version that applies in your case).

h2-db-migration.sh
#!/bin/bash
# h2-2.1.214.jar and h2-2.3.232.jar files must be present in the current working directory.
# They can be found respectively in 6.2.27 and 6.3 Magnolia webapps

path=/path/to/webapps/magnoliaAuthor/repositories/magnolia #repeat on public

for filepath in $(find $path -name '*.mv.db'); do
    parentdir="$(dirname "$filepath")"

    # Export data from old db file to backup.zip
    echo "Exporting database $parentdir/db..."
    java -cp h2-2.1.214.jar org.h2.tools.Script -url jdbc:h2:$parentdir/db -script $parentdir/backup.zip -options compression zip
    rm -f $parentdir/db.mv.db

# Import data from the backup.zip to the new db file
    echo "Importing data..."
    java -cp h2-2.3.232.jar org.h2.tools.RunScript -url jdbc:h2:$parentdir/db -script $parentdir/backup.zip -options compression zip variable_binary
    rm -f $parentdir/backup.zip
    echo "$parentdir/db migrated succesfully"
done

If you are experiencing index-related errors while upgrading H2 databases, try running the script below to remove indexes before using the migration script.

if [ -d "$parentdir/index" ]
then
rm -r $parentdir/index
echo "Directory $parentdir/index removed"
else
echo "Error: Directory $parentdir/index does not exists."  #NO index directory in magnolia/version folder. This is not a problem just adding this echo
fi

See also:

  • H2 Tutorial: Database Upgrade

    The recommended way to upgrade from one version of the database engine to the next version is to create a backup of the database (in the form of a SQL script) using the old engine, and then execute the SQL script using the new engine.

  • MAGNOLIA-8638 Getting h2 error while upgrading 6.2.10 to latest version

H2 does not accept more than one connection

Our default configuration uses the server mode for H2. If you migrate from Magnolia 5.5.8 or earlier in the 5.5 branch or 5.6.1 or earlier in the 5.6 branch and try to initiate a backup call using CLI or REST, it will fail because H2 does not allow more than one connection at a time. Configure H2 to run in server mode by adding AUTO_SERVER=TRUE to 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" />

See MGNLCE-114.

Resource exhaustion vulnerability in FasterXML jackson-databind

The UNWRAP_SINGLE_VALUE_ARRAYS feature is disabled by default. However, it is possible (though unlikely) that Magnolia could be susceptible to CVE-2022-42003 if this feature is enabled at the project level.

See Private BUILD-920 for more details.

Check your code

If you think that you may have enabled the feature at the project level, check your code to be sure.

Example usage
ObjectMapper mapper = new ObjectMapper();
mapper.enable(DeserializationFeature.UNWRAP_SINGLE_VALUE_ARRAYS); (1)
1 This is an example of the UNWRAP_SINGLE_VALUE_ARRAYS feature being enabled.

Embedded application server libraries may cause Admincentral to freeze

The Atmosphere Framework bundles several push (Comet) driver implementations. It typically picks the one appropriate for the currently used application server, but if your webapp for some reason brings in other application server libraries (such as Jetty or Grizzly), Atmosphere may pick a wrong driver. This can cause Admincentral to become unresponsive while waiting for push connections.

To mitigate these problems, try to avoid bundling such libraries. See MGNLUI-6899 for more details.

Open Source Web Crawler for Java (crawler4j) dependency issues in the Solr module

In Magnolia 6.2.23, the Tika libraries were updated (BUILD-684). However, the magnolia-content-indexer was still using the old Tika version, which created a conflict.

To eliminate this issue, the older tika-parsers artifact has been excluded from the magnolia-content-indexer in version 6.1.1 of the Solr module, followed by a crawler4j dependency update (4.4.0-magnolia > 4.4.1-magnolia) in version 6.1.2.

Therefore, version 6.1.2 of the Solr module is recommended for all users of Magnolia 6.2.23 or higher. For more details, see MGNLEESOLR-172 Exclude dependency on tika-parsers `1.x`.

Old magnolia-content-indexer artifactId

The info.magnolia.solr groupId libraries keep bringing the old magnolia-content-indexer artifactId. This happens when the DX-core’s parent POM is used to manage Magnolia Solr module dependencies. The 6.2.26 parent POM manages Solr module in version 6.1.1, which is affected by the crawler4j dependency issue described above.

Until this old magnolia-content-indexer issue is fixed in the next Magnolia release, you can use the following workaround.

Workaround

When adding the magnolia-solr-search-provider artifactId dependency, exclude the magnolia-content-indexer.

The exclusion must be done for every library whose groupId is info.magnolia.solr (magnolia-solr-search-provider, magnolia-solr-templating, magnolia-solr-workbench, magnolia-solr-ui).
pom.xml
<dependency>
  <groupId>info.magnolia.solr</groupId>
  <artifactId>magnolia-solr-search-provider</artifactId>
  <version>6.1.2</version>
  <exclusions>
    <exclusion>
      <groupId>org.apache.tika</groupId>
      <artifactId>tika-parsers</artifactId>
    </exclusion>
    <exclusion>
      <groupId>info.magnolia.solr</groupId>
      <artifactId>magnolia-content-indexer</artifactId>
    </exclusion>
  </exclusions>
</dependency>

Possible runtime issues using jackson (6.2.25 only)

For Magnolia 6.2.25 only, we have upgraded to jackson-databind 2.13.4 so we are not vulnerable to CVE-2022-42004. However, Magnolia 6.2.25 still uses jackson-core 2.12.x and jackson-databind 2.13.4 calls some classes in jackson-core that are only available from 2.13.x. Though the upgrade improves security for Magnolia, you may encounter some runtime issues using jackson.

Workaround

If you are experiencing issues after this update, try rolling back jackson-databind to version 2.12.7.1, which has been released in the meantime and as of October 25 (2022) has not been reported as vulnerable to any CVEs.

See Private BUILD-921 for more details.

Command execution issues for users with limited access rights

Magnolia 6.2.24 brought a number of improvements that tighten up the security of the release. Some of these improvements, however, may affect the ability to execute commands for users with limited access rights.

For example, an error such as null: User not allowed to Read path [website/] will be thrown if a user with limited access rights is trying to publish some content in the website workspace.

This may happen because the instance always checks whether the user has access permissions to the root folder of a particular node in the workspace.

With Magnolia 6.2.25, this behavior changes: The instance checks the permissions granted for a specific node by node UUID, not by path if no path is provided. For more details about this issue, see MAGNOLIA-8570.

Possible runtime issues using tika-parsers-1.28.x (Magnolia 6.2.23+ only)

When upgrading to Magnolia 6.2.23 or higher, remove the older tika-parsers-1.28.4.jar artifact. This should eliminate runtime conflicts.

Wider context

Tika artifacts are inherited through Apache Jackrabbit. Magnolia 6.2.23 updated Jackrabbit to a new minor version (2.20.6), where Tika was bumped from version 1.28.4 to 2.4.1.

In practice, the tika-parsers-1.28.x.jar artifact has been replaced by several individual parsers which in Maven go under the tika-parsers-standard-package.

In regard to Maven dependency hierarchies, Magnolia BOM 6.2.23+ manages the correct version and artifact id, so there should not be any problem.

See BUILD-684 for more details.

Context menu does not open under cursor

In Magnolia 6.2.22, if you right-click on a content item to open the context menu, the menu opens over the top of the action bar instead of where you right-clicked.

Context menu does not open under cursor

Switchable field with i18n=true ignores other locales

The issue occurs only with the currentItemProvider. If you use the jcrChildNodeProvider, the field behaves correctly with i18n set in the parent field only.

Workaround

When setting i18n to true for a Switchable field, the i18n property in the switcher field must also be set to true. For more details, see MGNLUI-7415.

Tasks App to remain at 6.2.18

In Magnolia 6.2.20, the Tasks App 6.2.19 (though unbundled) was released, but unfortunately contains changes that are incompatible with Magnolia 6.2.x.

Action

Please do not update your Tasks App to 6.2.19, but keep it at 6.2.18.

The Tasks App will be upgraded to 6.2.20 in Magnolia 6.2.22 and will resolve the issue.

Wrong validation error in rich text field

In Magnolia 6.2.20, the rich text field may produce a validation error (Malicious HTML code found) even for a safe HTML markup.

The issue will be fixed in Magnolia 6.2.21.

For more on this topic, please see global SafeHtmlValidatorDefinition configuration on our dedicated Field Validators page.

Default timezone overwritten

In Magnolia 6.2.19, when editing a user profile that doesn’t have an explicitly configured timezone (the timezone defaults to the server’s timezone in this case), the timezone is overwritten with the GMT timezone after saving the edit dialog.

For more details and a workaround, see ADMINCTR-70.

Error when adding a component

An error occurs after selecting a component on a page and clicking the Add component action in the Pages app for Magnolia 6.2.19.

The issue can be fixed by editing the createNewComponentWithSelectedComponent.yaml file in the Resource Files app. To implement the fix, remove the $type declaration from the file and replace it with the class row shown in the fixed YAML file below.

!include:/pages-app/dialogs/newComponent.yaml
actions:
  commit:
    class: info.magnolia.pages.app.detail.action.CreateNewComponentWithSelectedComponentAction

For more details, see PAGES-630.

Preview as visitor works only with en as default JVM language

In Magnolia 6.2.11, preview as visitor does not work when English as the default JVM language specifies a variant (for example, en_US as opposed to just en).

For languages other than English, the issue occurs regardless of whether any variants are defined (for example, with both es and es_ES).

For more details and a workaround, see MGNLPN-564.

To fix the issue permanently on your instances, update the Personalization module to version 2.0.10 or later.

Failing POST requests to GraphQL endpoint

When you send a POST request in magnolia-dx-core-demo-webapp 6.2.10 to a GraphQL endpoint, you may get the following 403 Forbidden error:

CSRF token mismatch possibly caused by expired session. Please re-open the page and submit the form again.

For the upcoming fix, see MGNLGQL-101.

In the meantime, you can include the GraphQL module in a webapp based on a 6.2.10 bundle if you add the following configuration to bypass the CSRF security filter:

BypassGraphQL:
class: info.magnolia.voting.voters.URIStartsWithVoter
pattern: /.graphql

Webhook does not make a request

In the REST Client module, versions 2.0.0 - 2.0.3, the RedirectFilter does not process correctly the redirections because it does not add the schema, host and port values to the Location header if the request URL is relative. If the URL is absolute, the REST client processes the redirect correctly.

This issue has been fixed in module version 2.0.4.

REST endpoint not behaving as expected with Java 11

In the Magnolia 6.2.8 webapps (except magnolia-empty-webapp), we have identified an issue filed as BUILD-462.

Generally, the REST endpoints that are affected are those installed or monitored by the magnolia-rest-services and magnolia-rest-integration submodules of the Magnolia REST module. These include:

and any custom endpoint configured as /config/<module-name>/restEndpoints. Whether these endpoints are affected in a specific Magnolia setup depends on how the endpoints are implemented.

The cause of the issue was the update of Tika to 1.26, which pulled in JAXB Runtime 3.0.0.

This issue is resolved in Magnolia 6.2.9 as well as magnolia-dx-core-cloud-webapp-6.2.8-sp1, which is available in the Magnolia Cloud Cockpit.

pom.xml content editor version mismatch

High priority

Due to a malformed POM in dx-core 6.2.27, Magnolia refuses to start due to a mismatch with the content editor versions when upgrading any project overlaying dx-core.

This will be remedied in 6.2.28. For now, you can use the workaround found below.

Workaround instructions

In your project pom.xml file:

  1. Add the following to the <properties> section.

    <content.editor.version>1.3.11</content.editor.version>

  2. Make sure then your project depends on that particular version in the <dependencies> section.

        <!-- Workaround for dx-core parent pom in 6.2.27 managing both 1.3.x and 2.1.x content-editor versions (webapp ends up with artifacts from both versions -->
    <dependency>
      <groupId>info.magnolia</groupId>
      <artifactId>magnolia-link-unfurl</artifactId>
      <version>${content.editor.version}</version>
    </dependency>
    <dependency>
      <groupId>info.magnolia.block</groupId>
      <artifactId>magnolia-block-api</artifactId>
      <version>${content.editor.version}</version>
    </dependency>
    <dependency>
      <groupId>info.magnolia.block</groupId>
      <artifactId>magnolia-block-templating</artifactId>
      <version>${content.editor.version}</version>
    </dependency>
    <dependency>
      <groupId>info.magnolia.editor</groupId>
      <artifactId>magnolia-content-editor</artifactId>
      <version>${content.editor.version}</version>
    </dependency>
    <dependency>
      <groupId>info.magnolia.editor</groupId>
      <artifactId>stories-app</artifactId>
      <version>${content.editor.version}</version>
    </dependency>
    <dependency>
      <groupId>info.magnolia.editor</groupId>
      <artifactId>magnolia-content-editor-widgetset</artifactId>
      <version>${content.editor.version}</version>
    </dependency>

analyticsView type malfunctioning

In Magnolia 6.2.27, the $type: analyticsView isn’t being recognized and is causing affected apps to fail on startup. You can see this by inspecting the logs.

Workaround

While we work on fixing this for you, you can replace $type with class as shown below to ensure affected apps function as expected.

class: info.magnolia.analytics.ui.app.view.extension.AnalyticsViewDefinition (1)
1 Where $type:analyticsView is, copy and paste this class: in its place.
This issue only impacts Magnolia 6.2.27.

Using the thresholdMs setting can result in invalid queries

The new feature magnolia.jcr.query.logging.thresholdMs in Configuration management has a known issue (MAGNOLIA-8726) and may result in invalid queries. We recommend waiting until the issue is fixed before using it.

Index rule warnings when upgrading from 5.4.x directly to 6.2.x

Jackrabbit 2.16 introduced existence checks for node types when refreshing indexing configurations. Previously, it would accept arbitrary node-type names as strings. If your project is not using Magnolia’s SearchIndex implementation, you may find the following warnings in your logs:

2018-07-25 17:48:33,691 WARN rabbit.core.query.lucene.IndexingConfigurationImpl: Unable to refresh index rules
javax.jcr.nodetype.NoSuchNodeTypeException: {https://www.magnolia-cms.com/jcr/mgnl}page
    at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.getNodeTypeDef(NodeTypeRegistry.java:552) ~[jackrabbit-core-2.16.1.jar:2.16.1]
2018-03-16 11:30:57,892 WARN rg.apache.jackrabbit.core.query.lucene.SearchIndex: Exception initializing indexing configuration from: /info/magnolia/jackrabbit/indexing_configuration_website.xml
javax.jcr.nodetype.NoSuchNodeTypeException: {https://www.magnolia-cms.com/jcr/mgnl}page
    at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.getNodeTypeDef(NodeTypeRegistry.java:552) ~[jackrabbit-core-2.16.1.jar:2.16.1]

To mitigate this problem, in your Jackrabbit search configuration files, replace

<SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">

with

<SearchIndex class="info.magnolia.jackrabbit.lucene.SearchIndex">

The warnings should not appear in the logs if you follow our recommendation to upgrade first to the latest release in both your current branch and every intermediate Magnolia branch still maintained before upgrading to the latest release in the Magnolia 6.2 branch. For more details, see How to upgrade.

Too many open files

The embedded Derby database, which can be used instead of the H2 database, opens several file handles and may run over the maximum limit set by the system. This issue can occur on some Linux and OS X systems such as Macbook Air.

The solution is to increase the system-wide limit on the number of open files. The exact procedure, however, varies from one OS to another.

Ubuntu Linux

  1. Find the current maximum number of open files per user in a single session:

    ulimit -n

    The number is 1024 by default, which is too small.

    A value higher than 1048576 (from Ubuntu LTS 24.01) is recommended.

  2. Edit the limits.conf file:

    sudo gedit /etc/security/limits.conf

  3. Add the following lines to the file:

    * soft nofile 10000
* hard nofile 50000

    This sets for all users a soft limit of 10000 open files and a hard limit of 50000. These are just examples. Set the limit according to your needs.

    The wildcard option applies only to regular users, not to superuser. If you run Magnolia as superuser, replace the asterisk with root.

  4. Save the file.

  5. Edit the configuration file for session-related modules:

    sudo gedit /etc/pam.d/common-session

  6. Add the following line to the file:

    session required pam_limits.so

    You may need to add the following line to /etc/systemd/system.conf and /etc/systemd/user.conf:

    DefaultLimitNOFILE=65535

  7. Save the file.

  8. Restart Ubuntu.

  9. Verify the new maximum number of open files:

    ulimit -n

    The command should now return 10000.

See Cannot Increase open file limit past 4096 (Ubuntu).

OS X 14.x

  1. Find the current maximum number of open files per user in a single session:

    ulimit -n

    The number is 256 by default, which is too small.

    To check the current limits on your Mac OS X system, run the following:

    launchctl limit maxfiles

    The last two columns are the soft and hard limits, respectively.

  2. Add ulimit -n 65536 to your ~/.profile file. This increases the limit for the shell.

  3. Create a /etc/sysctl.conf file if it does not exist.

  4. Add the following lines to /etc/sysctl.conf:

    kern.maxfiles=65536
kern.maxfilesperproc=65536

    This increases the limit for the kernel.

  5. Open a terminal and type:

    sudo sysctl -w kern.maxfiles=65536
sudo sysctl -w kern.maxfilesperproc=65536
sudo ulimit -n 65536

    Or restart your system to read the settings from the files you edited.

  6. Type ulimit -n. The response should be 65536 (if not, restart your system).

  7. Install Magnolia

See Shell session limit and this thread for information on previous Mac OS versions.

The instructions above apply to Bash shell, not Zsh.

Session de-serialization

When installing or upgrading Magnolia, you may see this error message:

2009-11-24 13:02:14,970 ERROR org.apache.catalina.session.ManagerBase: IOException while loading persisted sessions

This can be due to changes in the signatures of classes that are stored in user sessions, such as permissions and users. The error happens when Tomcat attempts to de-serialize serialized sessions as the container starts. The de-serialization causes the loss of persisted sessions, and users will have to log in again. Otherwise, it is a harmless error and can be ignored.

Port 8080 is already in use

Port 8080 is the default port for Tomcat. You can see it at the end of the default address http://localhost:8080. If another application on the computer is already using the same port, you may need to change it.

  1. Open <CATALINA_HOME>/conf/server.xml in a text editor. This file is under your Magnolia installation directory.

  2. Find the following section and set the value of port to something other than 8080 (for example, 8090):

    <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<Connector port="8090" maxHttpHeaderSize="8192"
           maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
           enableLookups="false" redirectPort="8443" acceptCount="100"
           connectionTimeout="20000" disableUploadTimeout="true" />

Change the defaultBaseUrl property, which is used to create absolute links in emails or other external systems. To do this, you need to now access Magnolia at the new 8090 port.

  1. Log into the author instance at http://localhost:8090/magnoliaAuthor/.magnolia.

  2. Go to Configuration.

  3. Set the /server/defaultBaseUrl property to http://localhost:8090/magnolia/.

  4. Log into the public instance at http://localhost:8090/magnoliaPublic/.magnolia.

  5. Go to Configuration.

  6. Set the /server/defaultBaseUrl property to http://localhost:8090/magnolia/.

Now the Welcome page at http://localhost:8090 has the correct URLs too.

The port also needs to be updated in publishing configuration. Otherwise, publishing changes from the author to the public instance would fail.

  1. On the author instance, go to Configuration > modules > publishing-core > config > receivers.

  2. Under the magnoliaPublic8080 receiver, set the URL property to http://localhost:8090 magnoliaPublic.

  3. Rename the receiver to magnoliaPublic8090. Publish the modified receiver including its subnodes.

If you want to run two different Tomcats simultaneously, you need to change other ports too. This is useful if you want to run different versions of Magnolia at the same time. In <CATALINA_HOME>/conf/server.xml, change the port numbers for the shutdown and AJP sections and any custom sections you have enabled.

Java out of memory

If the JVM does not have enough memory, java.lang.OutOfMemoryError may appear in the startup log and Magnolia may fail to start.

Exception in thread "Timer-1" java.lang.OutOfMemoryError: Java heap space
at org.apache.jackrabbit.core.query.lucene.IndexingQueue.getFinishedDocuments
Solution = Increase Java heap size to allocate more memory to the JVM

  1. Stop the server.
    ./magnolia_control.sh stop

  2. Open the /apache-tomcat/bin/setenv.sh file (/apache-tomcat/bin/setenv.bat on Windows) in a text editor.

  3. Edit the Xmx parameter to set a new maximum heap size. The default size for Magnolia is 2048M. Try a higher number (for example, 4096M).

  4. Save the file and start the server.
    ./magnolia_control.sh start && tail -f ../logs/catalina.out

High memory usage when bootstrapping content on first startup

When importing content on first startup or installation, you may experience high memory usage or even an OutOfMemoryError (OOME) exception.

The reason is that Jackrabbit keeps all changes in a transient space (and hence in memory) until the session is saved.

If the Unable to complete bootstrapping: out of memory. message is displayed, try to increase the maximum Java heap size with the -Xmx parameter in the server startup script.

You can also alleviate the issue by disabling the Jackrabbit search index for the import (commenting out the Magnolia index configuration in the workspace.xml configuration file(s)).

Publishing errors

For issues related to publishing keys and the handshaking process, see the Publishing errors page.

Node locking

We have temporarily added a five-minute timeout for the locking mechanism to mitigate an issue with nodes being locked even after publishing.

For more details about this issue, see EEPUBLISH-28.

New security filter

MAGNOLIA-6865 introduced a new security filter that checks each POST request. As this may affect the functionality of your existing forms, please contact us and we will provide you with more information about this issue.

For security reasons, however, we cannot disclose further details here.

Content stored in CE apps not displayed

In the Community Edition, if you edit content created in an app and the instance has no default i18n support, the content will not be displayed in the detail subapp of the app (MGNLUI-5770).

Single-page applications (SPA)

Rendering single-page applications (SPA)

Currently, the following functionalities are not supported in SPA rendering:

External SPA and browser compatibility

If you are running SPA editors (React, Angular or Vue) on Magnolia using either Safari or the Brave Browser, you can run into an issue where you see a blank white screen. This issue can be fixed as follows:

Safari

Configure your local SPA development server to use an SSL certificate for the localhost, for example, with the mkcert tool:

  • In your home SPA folder, execute the following command:

    mkcert localhost

  • Configure your local development server to use SSL and the newly created certificate. (Concrete instructions will depend on the framework you are using for your SPA).

  • Change your environment or the light module files to use HTTPS (not just HTTP) to access the local development server. For example, use https://localhost:3000 instead of http://localhost:3000.

  • Restart your local development server.

Brave Browser

Disable the Shields temporarily.

HTTP range requests do not work in certain cases

Facebook, LinkedIn, Twitter, and some other platforms use HTTP range requests to read Open Graph tags. This may cause the associated crawler to not work for Magnolia websites. A workaround for this issue is to use a voter that bypasses the gzip filter if the incoming request is within the specified range type and is coming from the configured platform (Facebook, Twitter, and so on).

  • Facebook

  • LinkedIn

  • Twitter

config.server.filters.gzip.bypasses.facebook.yaml
gzip:
  class: info.magnolia.module.cache.filter.GZipFilter
  jcr:primaryType: mgnl:content
  bypasses:
    jcr:primaryType: mgnl:content
    vaadinPush:
      class: info.magnolia.voting.voters.URIRegexVoter
      enabled: true
      pattern: ^.*\/.magnolia\/admincentral(-m5)*\/PUSH(\?.+)*$
    facebook:
      class: info.magnolia.voting.voters.BoolVoterSet
      op: AND
      voters:
        userAgent:
          class: info.magnolia.voting.voters.RequestHeaderPatternRegexVoter
          headerName: User-Agent
          pattern: .*facebookexternalhit.*
        rangeRequest:
          class: info.magnolia.voting.voters.RequestHeaderPatternRegexVoter
          headerName: Range
          pattern: .*
config.server.filters.gzip.bypasses.linkedIn.yaml
gzip:
  class: info.magnolia.module.cache.filter.GZipFilter
  jcr:primaryType: mgnl:content
  bypasses:
    jcr:primaryType: mgnl:content
    vaadinPush:
      class: info.magnolia.voting.voters.URIRegexVoter
      enabled: true
      pattern: ^.*\/.magnolia\/admincentral(-m5)*\/PUSH(\?.+)*$
    linkedIn:
      class: info.magnolia.voting.voters.BoolVoterSet
      op: AND
      voters:
        userAgent:
          class: info.magnolia.voting.voters.RequestHeaderPatternRegexVoter
          headerName: User-Agent
          pattern: .*LinkedInBot.*
        rangeRequest:
          class: info.magnolia.voting.voters.RequestHeaderPatternRegexVoter
          headerName: Range
          pattern: .*
config.server.filters.gzip.bypasses.twitter.yaml
gzip:
  class: info.magnolia.module.cache.filter.GZipFilter
  jcr:primaryType: mgnl:content
  bypasses:
    jcr:primaryType: mgnl:content
    vaadinPush:
      class: info.magnolia.voting.voters.URIRegexVoter
      enabled: true
      pattern: ^.*\/.magnolia\/admincentral(-m5)*\/PUSH(\?.+)*$
    twitter:
      class: info.magnolia.voting.voters.BoolVoterSet
      op: AND
      voters:
        userAgent:
          class: info.magnolia.voting.voters.RequestHeaderPatternRegexVoter
          headerName: User-Agent
          pattern: .*Twitterbot.*
        rangeRequest:
          class: info.magnolia.voting.voters.RequestHeaderPatternRegexVoter
          headerName: Range
          pattern: .*

Virtual URI mappings not working if too many are configured

To mitigate an issue caused by having more than 500 configured virtual URI mappings in light modules, a WARN-level message is now logged when a DirectoryWatcher overflow occurs (MAGNOLIA-7762). We recommend to keep the number of files in a single folder below 100 and to use folder hierarchies whenever possible. For the upcoming fix, see MAGNOLIA-7798.

i18n breaks virtual URI mapping for paths starting with a language tag

You have a virtual URI mapping configuration similar to what is shipped with the tours module of the Magnolia Travel Demo:

/tours/virtualUriMappings/travelToursMapping.yaml
class: info.magnolia.virtualuri.mapping.RegexpVirtualUriMapping
fromUri: ^/(.*/)?tours(.*).html
toUri: forward:/$1travel/tour?tour=$2

Provided en is the default language, you may see that requests for pages without the language tag in the path work correctly,

/tours/magnolia-travels/Kyoto.html

while those where the tag is part of the path fail:

/de/tours/magnolia-travels/Kyoto.html

Add a bypass of the i18n filter

This is a solution adopted in the Magnolia 6.2.12 Demo webapp. The demo adds a bypass of the i18n filter:

/server/filters/
...
  i18n:
    class: info.magnolia.cms.i18n.I18nContentSupportFilter
    enabled: true
    bypasses:
      BypassWhenForward:
        class: info.magnolia.voting.voters.ForwardVoter
  cache:
    class: info.magnolia.module.cache.filter.CacheFilter
    defaultContentCachingConfigurationName: defaultPageCache
  virtualURI:
    class: info.magnolia.virtualuri.VirtualUriFilter
    enabled: true
...

This approach can only be used:

Additionally, set /modules/cache/config/contentCaching/<your-configuration>/cachePolicy@includePersonalizedDescendants to true. This makes sure that personalized components are part of page cache key. Otherwise, you would always get the first page version.

Change the filter order

In this solution, present in the Magnolia 6.2.13 Demo webapp, the bypass of the i18n filter is removed but the order of filters has changed:

/server/filters/
...
  virtualURI:
    class: info.magnolia.virtualuri.VirtualUriFilter
    enabled: true
  i18n:
    class: info.magnolia.cms.i18n.I18nContentSupportFilter
    enabled: true
  cache:
    class: info.magnolia.module.cache.filter.CacheFilter
    defaultContentCachingConfigurationName: defaultPageCache
...
Redirects are not cached.

You are probably not affected

If a tours-like mapping is not used in your project or you do not use language variants, keep the following order of filters:

/server/filters/
...
  i18n:
    class: info.magnolia.cms.i18n.I18nContentSupportFilter
    enabled: true
  cache:
    class: info.magnolia.module.cache.filter.CacheFilter
    defaultContentCachingConfigurationName: defaultPageCache
  virtualURI:
    class: info.magnolia.virtualuri.VirtualUriFilter
    enabled: true
...
This is implemented in the Magnolia 6.2.12 webapps that don’t ship with the Travel Demo.

Natural order not respected in content search results

If you search for content using searchfn.searchPage() or searchfn.searchContent() or by executing search queries directly from a template, the search results will not respect the natural order. This issue is caused by a bug in Apache Jackrabbit reported as JCR-3932.

Until the JCR bug is fixed, do not use searchfn. To get the correct order, execute JCR XPath queries directly.

DL4J/ND4J issues

There are limitations on the deep-learning and search features of the Find Bar, which are provided by the Periscope module.

Off-heap memory starvation

You should configure DL4J memory limits to avoid off-heap memory starvation. This is particularly the case with the -Dorg.bytedeco.javacpp.maxbytes JVM argument. For more details, see MGNLPER-121.

Public webapp cannot be deployed as ROOT along with author instance

When you experience this issue, the following message appears in the logs:

java.lang.NoClassDefFoundError: Could not initialize class org.nd4j.linalg.factory

The issue may occur on more than just one Tomcat instance running on the same VM and the same JDK.

no jnijavacpp in java.library.path error message

Some environments may throw the following warnings with DL4J 1.0.0-beta7:

Mo jnijavacpp in java.library.path

For more details, see the reported JavaCV issue.

AVX/AVX2 CPU Support

Advanced Vector Extensions (AVX) are a set of instructions extending the instruction set of the x86 family of microprocessors. AVX was first released in March 2008 for Intel and AMD, and AVX2 was released in 2013. If your hardware uses a processor that does not support AVX2, you will get the following message:

libnd4j binary was built with AVX/AVX2 support, but current CPU doesn't have this instruction set. Exiting now...

By default, Magnolia is shipped with the AVX2 libraries installed:

  • nd4j-native-1.0.0-beta6-macosx-x86_64-avx2.jar

  • nd4j-native-1.0.0-beta6-windows-x86_64-avx2.jar

  • nd4j-native-1.0.0-beta6-linux-x86_64-avx2.jar

<dependency>
  <groupId>org.nd4j</groupId>
  <artifactId>nd4j-native</artifactId>
  <classifier>linux-x86_64-avx2</classifier>
</dependency>
<dependency>
  <groupId>org.nd4j</groupId>
  <artifactId>nd4j-native</artifactId>
  <classifier>macosx-x86_64-avx2</classifier>
</dependency>
<dependency>
  <groupId>org.nd4j</groupId>
  <artifactId>nd4j-native</artifactId>
  <classifier>windows-x86_64-avx2</classifier>
</dependency>

If your CPU only supports AVX, use the AVX libraries instead:

  • nd4j-native-1.0.0-beta6-macosx-x86_64.jar

  • nd4j-native-1.0.0-beta6-windows-x86_64.jar

  • nd4j-native-1.0.0-beta6-linux-x86_64.jar

 
<dependency>
  <groupId>org.nd4j</groupId>
  <artifactId>nd4j-native</artifactId>
  <classifier>linux-x86_64</classifier>
</dependency>
<dependency>
  <groupId>org.nd4j</groupId>
  <artifactId>nd4j-native</artifactId>
  <classifier>macosx-x86_64</classifier>
</dependency>
<dependency>
  <groupId>org.nd4j</groupId>
  <artifactId>nd4j-native</artifactId>
  <classifier>windows-x86_64</classifier>
</dependency>

Resizing a GIF image results in an HTTP 500 error

Specific JVMs do not support GIF image compression. In particular, when using version 11 of OpenJDK and its derivatives to process a GIF image via standard image variations, the variations are not rendered and the browser console displays an error:

Failed to load resource: the server responded with a status of 500 () <link>
More details about the error are shown if you open the image link directly: 
java.lang.IllegalArgumentException: Unknown compression type!
	java.desktop/javax.imageio.ImageWriteParam.setCompressionType(ImageWriteParam.java:1040)
	info.magnolia.imaging.OutputFormat.applyTo(OutputFormat.java:80)
	info.magnolia.imaging.DefaultImageStreamer.write(DefaultImageStreamer.java:83)

Workarounds

  • Add a new property called compressionType to the configuration of the output format of your GIF image generator (/modules/imaging/config/generators/<generator-name>/outputFormat) and set its value to LZW.

    Due to a change between Java 8 and Java 11 you have to specifically use upper case LZW.

  • Use a JVM that provides support for processing GIF images (Oracle).

  • Avoid processing GIFs via image variations; use direct links to render the images.

Renditions of animated GIF images

In renditions of animated GIF images, only the first frame is resized and kept, turning the originally animated GIF image into a static GIF.

For the development status of this feature, see MGNLIMG-389 Allow GIFs to be used with Renditions.

Performance issues

See the Performance issues page.

Feedback

DX Core

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules