Known Issues in the CoreMedia Experience Cloud

Solution

The bug has been fixed in versions 2406.0.2, 2404.5, 2401.7 and 2310.7 (CMS-25255).

CMCC Self-Managed Customers

In case you are using the blob sharing capability together with URL blobs, you should update to a fixed CMCC version and reset your RLSs.

CMCC Service Customers

In case you are using URL blobs, for example, via the Content Hub, you should update to a fixed CMCC version and reach out to CoreMedia support for handling a potential RLS inconsistency.

Workaround

No workaround is known. Please update to a fixed version.

Solution

The bug is fixed in version 2406.0.2

Workaround

Make sure to directly install the version 2406.0.2. Skip versions 2406.0.0 and 2406.0.1.

For more details, check out the Release Notes - Link: https://documentation.coremedia.com/cmcc-12/artifacts/2406.0/release-notes-webhelp/content/Preface.html

Solution

The Micrometer dependencies will be downgraded to the latest 1.12.x patch version in the next AMP releases 2404.3, 2401.5 (CMCC-12) and 2310.5 (CMCC-11).

Workaround

The Micrometer version can be downgraded to a version prior to 1.13.0 by importing the Micrometer BOM for the required version to the beginning of the dependencyManagement section in the apps/*/blueprint-parent/pom.xml files of the Blueprint workspace:

<project>
  ...
  <properties>
    <micrometer.version>1.12.6</micrometer.version>
  </properties>
  ...
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-bom</artifactId>
        <version>${micrometer.version}</version>
        <scope>import</scope>
        <type>pom</type>
      </dependency>
      ...
    <dependencies>
  <dependencyManagement>
  ...
</project>

There is also an interim solution for customers who cannot upgrade all blueprint-parent POMs: the io.micrometer:micrometer-registry-prometheus dependency can be replaced with io.micrometer:micrometer-registry-prometheus-simpleclient in the shared/common/spring-boot/blueprint-spring-boot-autoconfigure/pom.xmlfile. But please be aware that this dependency will probably be removed in newer versions of Micrometer.

For further information, see the Micrometer 1.13 Migration Guide.

Solution

This issue is fixed in the next releases 2310.4, 2401.4, 2404.2.

Workaround

Please cherry-pick this commit from the coremedia-blueprints-workspace:

https://github.com/coremedia-contributions/coremedia-blueprints-workspace/commit/8aecb1a6cf1203daba283b2d2cea223993287d7a

Solution

As of version CMCC 2404.1 Sencha Cmd will not be required anymore.

Workaround

As there is no official support for Java 17 from Sencha and it only works with workarounds, we suggest running Sencha CMD with Java 11.

Please either use a Sencha Cmd installation with an included JRE (currently only offered for Windows and macOS) or make sure to set the environment variable INSTALL4J_JAVA_HOME_OVERRIDE to the root folder path of a JRE 11 installation.

This information has also been included in CoreMedia Blueprint Developer Manual and Studio Developer Manual.

While this does not affect the Docker based studio-client build as it downloads a suitable JRE 11 anyway, you might need to adjust the installation of Sencha Cmd when building the studio-client locally.

Solution

We will turn off this component with the first follow-up release.

Workaround

For now, please set the path to a writeable folder so the applications can create the directories during their initialization. Because all applications should have a writeable /tmp directory, please set the environment variable COM_COREMEDIA_TRANSFORM_BLOBCACHE_BASEPATH to "/tmp" for the following applications:

• cae-feeder-preview
• cae-feeder-live
• elastic-worker
• content-feeder

Solution

The certificate file will be fixed in the next release.

Workaround

You can replace the existing certificate with your own or simply add the missing "-" sign before building the workspace:

If you have already built the workspace with the incorrect certificate, you need to correct the file and recreate the Traefik image.

Headline Level Mismatch

When writing text with the rich text editor, headlines are stored and rendered with a different level than the selected one. For example, if you choose Headline 1 it will be shown as a Headline 2 in the preview.

HTML Fragment Not Editable

Newly created content of type HTML Fragment in CoreMedia Studio is not editable. Existing HTML Fragment can be edited though.

Solution

Both issues will be fixed with the upcoming CMCC v11.2210.2 in January 2023.

Workaround

Headline Configuration

The Blueprint uses the default configuration of CKEditor 5 for headlines. This means that when choosing for example Headline 1 as the paragraph style, it is persisted as <h2> internally. This is the default configuration of the plugin from CKEditor 5 that is optimized for the way the Search Engines like the Google Search read texts.

In CMCC however, the headline levels are managed by the Content Application Engine and the Headless Server. They rely on Headline 1 being <h1> so that they can map the headline levels from Rich Text to the HTML equivalent for example.

In order to fix this issue, update the configuration of the headline plugin of the CKEditor 5 in the file apps/studio-client/shared/js/ckeditor5/src/ckeditor/ckeditorDefault.ts as follows:

localization.add({
"de": {
"Left-aligned": "Linksbündig",
"Right-aligned": "Rechtsbündig",
"Within Text": "Im Text",
"Page default": "Standardeinstellung",
"Type your text here...": "Text hier eingeben...",
"Paragraph": "Absatz",
 "Heading 1": "Überschrift 1",
 "Heading 2": "Überschrift 2",
 "Heading 3": "Überschrift 3",
}
})
...
heading: {
 options: [
 { model: 'paragraph', title: localize('Paragraph', language), class: 'ck-heading_paragraph' },
 { model: 'heading1', view: 'h1', title: localize('Heading 1', language), class: 'ck-heading_heading1' },
 { model: 'heading2', view: 'h2', title: localize('Heading 2', language), class: 'ck-heading_heading2' },
 { model: 'heading3', view: 'h3', title: localize('Heading 3', language), class: 'ck-heading_heading3' },
 ],
},
...

Configuration Of The HTML Fragment Editor

In order to show a placeholder text when the rich text editor is empty, the CKEditor 5 requires the placeholder plugin. Since this plugin is currently missing, the empty editor does not work as expected.

Add the plugin to the configuration of the slim version of the Rich Text Editor by adapting the CKEditor 5 configuration in the file apps/studio-client/shared/js/ckeditor5/src/ckeditor/ckeditorSlim.ts as follows:

...
import AutoSave from "@ckeditor/ckeditor5-autosave/src/autosave";
import Paragraph from '@ckeditor/ckeditor5-paragraph/src/paragraph';
...
plugins: [
AutoSave,
//@ts-ignore
CoreMediaStudioEssentials,
//@ts-ignore
CoreMediaFontMapper,
//@ts-ignore
Differencing,
Essentials,
Paragraph,
],
...

Solution

The problem is that the Windows 260-character limit for paths applies here, even if it is actually supposed to be switched off by the corresponding group policy or registry entry.

We have already reported this bug to Typescript and it will be fixed in upcoming releases.

Workaround

The simplest workaround is to start the CoreMedia workspace under Windows in a very short path, e.g. C:\dev.

Solution

Replace the dockerfile-maven-plugin with the io.fabric8::docker-maven-plugin.`

<plugin>
  <groupId>io.fabric8</groupId>
  <artifactId>docker-maven-plugin</artifactId>
  <version>0.39.1</version>
  <executions>
    <execution>
      <id>build</id>
      <phase>install</phase>
      <goals>
        <goal>build</goal>
      </goals>
      <configuration>
        <images>
          <image>
            <name>${docker.repository.prefix}/${docker.repository.suffix}</name>
            <build>
              <buildOptions>
                <platform>linux/amd64</platform>
              </buildOptions>
              <args>
                <JAVA_APPLICATION_BASE_IMAGE_REPO>${docker.java-application-base-image.repo}</JAVA_APPLICATION_BASE_IMAGE_REPO>
                <JAVA_APPLICATION_BASE_IMAGE_TAG>${docker.java-application-base-image.tag}</JAVA_APPLICATION_BASE_IMAGE_TAG>
              </args>
              <tags>
                <tag>${docker.image.tag}</tag>
              </tags>
            </build>
          </image>
        </images>
      </configuration>
    </execution>
  </executions>
</plugin>

Args configuration for some specific POMs:

Solr

<args>
  <SOLR_BASE_IMAGE_TAG>${docker.solr-base-image.tag}</SOLR_BASE_IMAGE_TAG>
  <SOLR_BASE_IMAGE_REPO>${docker.solr-base-image.repo}</SOLR_BASE_IMAGE_REPO>
  <PROMETHEUS_AGENT_VERSION>${prometheus-agent.version}</PROMETHEUS_AGENT_VERSION>
</args>

Sitemanager

<args>
  <WEBSWING_BASE_IMAGE_TAG>${docker.webswing-base-image.tag}</WEBSWING_BASE_IMAGE_TAG>
  <WEBSWING_BASE_IMAGE_REPO>${docker.webswing-base-image.repo}</WEBSWING_BASE_IMAGE_REPO>
</args>

Studio-Client

<args>
  <ALPINE_BASE_IMAGE_TAG>${docker.alpine-base-image.tag}</ALPINE_BASE_IMAGE_TAG>
  <ALPINE_BASE_IMAGE_REPO>${docker.alpine-base-image.repo}</ALPINE_BASE_IMAGE_REPO>
  <NGINX_BASE_IMAGE_TAG>${docker.nginx-base-image.tag}</NGINX_BASE_IMAGE_TAG>
  <NGINX_BASE_IMAGE_REPO>${docker.nginx-base-image.repo}</NGINX_BASE_IMAGE_REPO>
</args>

Management-Tools

<args>
  <TOOLS_BASE_IMAGE_REPO>${docker.tools-base-image.repo}</TOOLS_BASE_IMAGE_REPO>
  <TOOLS_BASE_IMAGE_TAG>${docker.tools-base-image.tag}</TOOLS_BASE_IMAGE_TAG>
</args>

Describe how the customer can work around the problem until it is fixed.

Image studio-client cannot be built

Issue

When trying to build "studio-client" according to section "Building with Docker" (as described in Blueprints Workspace file apps/studio-client/README.adoc) an error occurs.

Solution

We can only recommend running the pnpm build directly on a shell and only having the image built, as described here in our documentation (STUDIO_CLIENT_TOOLING_IMAGE needs to be "unset" for this).

Some containers may run very unstable

Issue

Some containers (especially Solr) don't always start up correctly, may go into an unhealthy state, use 100% CPU, etc.

Solution

Unfortunately, there isn't a known solution to us currently, other than trying to restart the container until it runs properly. Take a look at the container's log and try to detect whether it got stuck during startup:

docker logs -f solr

When not proceeding in its startup, you can, e.g., restart container Solr with the command:

docker-compose restart solr

Scripts in container "management-tools" don't work

Issue

When trying to execute scripts in the management-tools docker container, errors may occur and the scripts don't get executed.

Solution

Currently there is also not a known solution for this. A workaround is to import the data manually:

Here is a compilation of the commands that are required for the manual import of all data. It is assumed that the blobs were previously unpacked in the Blueprints Workspace. Then the following commands must be issued in the Blueprints Workspace root directory (after building all components according to the manual and starting with Docker Compose):

# import themes
apps/studio-server/modules/cmd-tools/theme-importer-application/target/theme-importer/bin/cm import-themes -u admin -p admin ../../../../../../../frontend/target/frontend.zip
# import users
for i in content/test-data/target/users/*.xml; do apps/content-server/modules/cmd-tools/cms-tools-application/target/cms-tools/bin/cm restoreusers -u admin -p admin -f $i; done
# import content
apps/content-server/modules/cmd-tools/cms-tools-application/target/cms-tools/bin/cm serverimport -u admin -p admin --no-validate-xml -r content/test-data/target/content
# import default workflows
for i in studio-simple-publication.xml I am running a few minutes late; my previous meeting is running over.
immediate-publication.xml \
studio-two-step-publication.xml \
three-step-publication.xml \
global-search-replace.xml \
/com/coremedia/translate/workflow/derive-site.xml \
/com/coremedia/translate/workflow/synchronization.xml; do apps/workflow-server/modules/cmd-tools/wfs-tools-application/target/wfs-tools/bin/cm upload -u admin -p admin -n $i; done
# import custom workflows
apps/workflow-server/modules/cmd-tools/wfs-tools-application/target/wfs-tools/bin/cm upload -u admin -p admin -f properties/corem/workflows/translation.xml
# publish all
apps/content-server/modules/cmd-tools/cms-tools-application/target/cms-tools/bin/cm bulkpublish -u admin -p admin -a -b -c

Frontend Workspace cannot be build

Issue

When trying to install the frontend workspace, you get the error message: "You are using an unsupported architecture. Please use x64." This is caused by the dependency "node-sass", which uses precompiled binaries. Apple Silicon CPUs are not supported.

Solution

Use the terminal via Rosetta or explicitly set the system architecture via $arch -x86_64 zsh.

Check your current architecture via node -p process.arch

It should return x64. If it still returns arm64 please check also the following guide https://www.jurnalanas.com/node-js-mac-m1/

Studio-Client Workspace cannot be build

Issue

The chromium binary is not available for arm64 when running pnpm install

Solution

Add an environment variable before running "pnpm install".

PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true

To execute joounit test (assuming Chromium is installed locally) set the following variable before running the test(s):

PUPPETEER_EXECUTABLE_PATH=`which chromium`

Tests Failures on Project lc-studio

Issue

The build is not complete because a test on project lc-studio fails.

Solution

Install chromedriver locally and run it locally once. After that, you should run the mvn command with some additional parameters, for example:

mvn clean install -Dwebdriver.chrome.driver=/opt/homebrew/bin/chromedriver -DjooUnitWebDriverBrowser=chrome -DjooUnitWebDriverBrowserArguments=--no-sandbox,--disable-dev-shm-usage

Solution

This issue is fixed in the next version CMCC v10 2107.4 (internal ticket CMS-20517)

Workaround

There is no real workaround besides resetting all crops or reverting all changes to the document

Symptoms

Upgraded Indexes may get inconsistent, resulting in queries returning multiple Solr documents with the same ID, or even Solr documents that should have been deleted. Furthermore, the Content Feeder may run into exceptions from Solr like the following:

2021-06-14 15:11:08 -  [WARN] com.coremedia.amaro.feeder.FeederImpl [] - Sending failed: Batch[id=1, size=500, bytes=56619, sendFailures=1]: Indexing failed. Will retry after 30 seconds. (Feeder-Sender)
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://localhost:40080/solr: Error processing document with ID 908: Attempted an atomic/partial update to a child doc without indicating the _root_ somehow.

Solution

The next 2104.3 AMP will disable Solr Nested Documents support and the content issue search by default. That way, customers will not be forced to reindex an existing Solr index. Instead, they will be able to opt-in and decide when they want to upgrade to enable the new Studio search functionality.

This behavior will change with the upcoming major release of CMCC 11, which will enable this new feature by default.

Workaround

Content Feeder Index

You can either perform a complete reindexing, or remove the mentioned Solr schema fields and disable the new feature, which enables filtering of content items by issues in Studio library.

For a complete reindexing, it's required forcing a full reindex from scratch by deleting the existing index first and letting the Content Feeder create a new one. It's not sufficient to trigger reindexing of all content items using JMX or an actuator endpoint of the Content Feeder.

To disable the new feature, you can avoid reindexing by following these steps:

1. Remove the field definitions for _root_ and _nest_path_ from file apps/solr/modules/search/solr-config/src/main/app/configsets/content/schema.xml
2. Configure the Content Feeder to not index content issues with property feeder.content.issues.index=false

If you have already started the Content Feeder of version 2104.1 or 2104.2 to feed an existing index, then the index may have been corrupted already. You will have to restore it from a backup before the upgrade, or reindex from scratch.

CAE Feeder Index

Remove the field definitions for _root_ and _nest_path_ from file apps/solr/modules/search/solr-config/src/main/app/configsets/cae/schema.xml.

If you have already started the CAE Feeder of version 2104.1 or 2104.2 to feed an existing index, then the index may have been corrupted already. You will have to restore it from a backup before the upgrade, or reindex from scratch.