Migration to the New Content Fragment Editor in AEMaaCS

[#1]

Migration to the New Content Fragment Editor in AEMaaCS 

by @daniel-strmecki

Introduction

Content fragments (CF) in AEM allow authors to design, create, and publish page-independent content without visual design and/or layout. Therefore, authors can use them to prepare content that can be reused in multiple locations and channels, which is ideal for headless delivery or reuse across pages. The CF reference AEM core component enables simple referencing and using the CF data on a page, while GraphQL and/or REST APIs enable headless content delivery. The new CF editor was recently introduced by Adobe to enhance the authoring experience for structured content. It can be accessed from the new CF console and offers a few interesting new features:

• Tree navigation feature with a hierarchical view of the CFs structure to allow authors to easily navigate and edit CFs efficiently
• Improved authoring interface with features such as auto-save and breadcrumbs for navigating back in referenced CF structures
• Supports the same CF model fields as the classic editor, allowing for the creation of structured content with predefined data types
• Preview URL link that (if configured) enables authors to preview how the CF data would look on a page
• Toggle button to enable authors to easily switch between the new CF editor and the classic editor
• Enables, but purposefully limits customizations and extension points available

While it is a natural choice for greenfield AEMaaCS projects, switching to the new CF editor may not be a simple task for older projects with many customizations in place. Therefore, in this article, we'll present the benefits of switching to the new CF editor, warn customers about potential customization limitations, and explain how to get around them.

Key Points

In the article, we explore the following topics:

• New CF Console - navigate through complex CF structures without mixing them with other types of assets
• New CF Editor - more powerful, author-friendly, and optimized for omnichannel content delivery
  
• CF Model Editor - the model editor hasn't changed, but some customizations might not work in the new editor
• Extensions - extension support so developers can enhance the authoring experience with custom plugins deployed to Adobe IO, covering and explaining the limitations, and what is possible to customize
• Custom Fields - an example of how to define a custom field that replaces the OOTB field defined in the model
• Nested multifield - advice for (not) developing it and looking into alternative approaches

Full Article

Read the full article on https://meticulous.digital/blog/f/migration-to-the-new-content-fragment-editor-in-aemaacs to find out more.

Q&A

Please use this thread to ask questions relating to this article

[#2]

Interesting, thanks for sharing.

[#3]

@daniel-strmecki Thanks, Daniel, for sharing this detailed guide on migrating to the new Content Fragment editor! The tree navigation and improved authoring interface look like great enhancements for authors, especially with complex CF structures. I also appreciate the tips around handling customizations and extension limitations.

Question: For teams who have already migrated some projects, which part of the transition to the new CF editor did you find most challenging: handling existing custom fields, nested multifields, or something else? I’d love to hear real-world experiences from the community.

[#4]

Hi @kautuk_sahni,

thanks for asking, it is definitely the nested multifields that are most painful to migrate. We had to update our CF models to remove them and then run content migration scripts to transfer the old content.

It would be very interesting to get Adobe's perspective on nested multifields. Are they considered a relic of the past, or can we expect future official support for nested multifields in the new CF Editor and Universal Editor?