Using AEM Modernization Tools

We recently began the process of switching over all of our pages from static to editable templates.This was shaping up to be a long, complicated, and expensive process, so we turned to AEM Modernization Tools for a solution.

AEM Modernization Tools makes customization easy by providing a broad range of pre-set options that we combined to fit our needs. The tool suite is also designed to be extendable which allowed us to specify custom implementations when the framework did not provide us with quite enough flexibility. We also had the option to extend the feature set by registering OSGi services and implementing specific API interfaces.

We will not dive into AEM Modernization tools in detail; instead we will show you how to create a custom implementation to fit your own needs by answering some frequently asked questions about AEM Modernization custom solutions.

Before starting, you should make sure you’ve installed the AEM Modernization Tools package:
https://github.com/adobe/aem-modernize-tools

Why did we need to customize AEM Modernization Tools?

• You might assume that all static pages will be structured correctly, but we discovered that some of our pages were missing several components which were supposed to be parts of the editable template. We also discovered that after conversion some extra components that we didn’t want appeared on the page. We decided to exclude these pages from the conversion process. Still, as a precaution, we checked the accuracy of the structure before converting each page.
• The standard PageStructureConverter implementation will move all the nodes under jcr:content to root. This would not work for us because we had several nodes under jcr:content which are a part of page properties configuration, and we wanted to keep them where they were.

How did we customize AEM Modernization Tools for our site?

• First, we added the new dependency into our pom.xml:

• In order to have our custom converter, we implemented PageStructureRewriteRule:

• We decided to use a simpler configuration than the standard factory by:

1. Keeping staticTemplate, editableTemplate, and slingResourceType fields the same as in PageRewriteRule
2. Skipping the component order configuration and relying on the order in the initial part of an editable template
3. Skipping “components to remove”
4. Introducing a new section called “components mapping” where we can list out mappings in the appropriate format [old_component_rel_path:new_component_rel_path]

• When we implemented PageStructureRewriteRule, we needed these methods:

How exactly did we implement the new solution?

• We returned our staticTemplate field (basically the same as in PageRewriteRule):

• matches() method was also basically the same; we just checked the cq:template property:

• The method applyTo() was responsible for the conversion itself
• Before conversion, we created a version as a precaution
• We changed the cq:template property
• We moved nodes under root
• We reordered nodes to match the template

What does the configuration look like?

• We also needed the corresponding xml config file (we should have a separate config file for every template):

How did we use AEM Modernizing Tools?

• This is the AEM Modernizing tool console:

• We searched for pages under the path we wanted to convert:

• After selecting page(s), the Convert Pages(s) button appears:

• Here’s the list of successfully converted pages:

What is the full class EditableTemplateConverter?

Originally published at https://exadel.com on October 20, 2020.