The Page Structure rewrite tool consists of a single rewrite rule OSGi service factory.
Page Rewrite Rule Service
The Page Rewrite Rule service is a factory service intended for creating one rule per static template to be converted.
Allowed Paths
Use this property to restrict the content paths to which this configuration will apply. This will allow development teams to create configurations that have the same static template and Sling Resource Type, but require a different editable template based on the tenant.
By default, no restrictions are applied.
Static Template
This property is used as means to identify pages for conversion. This, along with the sling.resoruceType configuration property are used for matching. A page which has a matching cq:template property value will be listed in the search results.
Sling Resource Type
This property is used as means to identify pages for conversion. This, along with the static.template configuration property are used for matching. A page which has a matching sling:resourceType property value will be listed in the search results.
Editable Template
This will be the new value of thee cq:template property after the conversion process. This template is assumed to exist, no validation of its presence is performed. If it does not exist, then errors will be thrown during the Job resulting in failures.
Container Resource Type
Since the Foundation Responsive Grid is not recommended be used directly, this property specifies the Container Core Component proxy to use when modifying the page structure.
Node Ordering
This property allows users to define the order of the nodes on the new root container. The ordering supports nested components through the use of a colon (:) to separate parent/child relationships. In this example, the lead node will be moved to the first position of the container node, which is a child of the root layout container.
The names referenced here are those that either already exist in the page content (i.e. static references) or nodes which are renamed through the Rename & Relocation configuration.
Any nodes found, but not listed in here, will be added to the end of the root container; i.e. nodes found as direct descendants of the jcr:content node will be appended to the end of the root container in the order found.
Node Renaming & Relocation
This configuration property allows users to rename a node as it is moved & transformed. The primary use case for this is renaming previous static parsys nodes to their editable template counterparts. In this example the page’s par and rightpar nodes are renamed the values shown. If a node is specified to be renamed to relative child path, then the intermediate nodes will be created based on the structure in the Editable template definition.
It’s important to note that these values are found by reviewing the structure for the editable template created by the template editors. An incorrect definition will lead content not rendering on the transformed pages.
Node Ignoring
This list allows teams to specify nodes which should not be modified or moved from the root of the Page’s content tree. There may some use of maintaining static references to nodes from the template types, and thus the references need to be maintained.
The Structure Conversion Tool ignores nodes named cq:LiveSyncConfig and cq:BlueprintSyncConfig by default, as they have special meaning in AEM and must be maintained at the root of the Page’s content.
Node Removal
This list specifies nodes which are removed if found, typically because they are leftover from previous template refactoring and no longer needed.