The Copied Template With an Empty Style Tab
An AEM 6.5 Sites project has four brand sites using editable templates. A shared Hero component is implemented once as acme/components/content/hero and used by all brands. Brand A's template shows the Hero with a Style tab containing three policy-driven options: height, overlay opacity, and CTA style. Brand B was created quickly by copying Brand A's template node in CRX/DE to /conf/acme-b/settings/wcm/templates/. On Brand B pages, the Hero renders correctly, but its Style tab is empty, and authors cannot drop a Hero into some Layout Containers. Brand B has its own /conf/acme-b/settings/wcm/policies tree, but no policy entries for the Hero. Brand A has 12 policies under /conf/acme-a/settings/wcm/policies. The copied Brand B template still contains policy mappings that point at Brand A's policy paths.
1. Why does the Hero render but its Style tab is empty and it is sometimes not allowed in a Layout Container? Distinguish rendering from authoring behavior.
Read the worked answer
Rendering and authoring are resolved differently. The Hero renders because its sling:resourceType still resolves to acme/components/content/hero; the component code and HTL are available. The Style tab and the Layout Container's allowed-components list are policy-driven authoring behavior, not rendering behavior.
When Brand A's template was copied at the node level, the copy retained policy mappings that reference /conf/acme-a/.... Brand B either has no valid policy mapping or inherits a mapping to Brand A's policy tree. A Layout Container policy controls which components can be dropped into that container. If Brand B's container resolves to a policy that does not include the Hero, the component is rejected. The Hero's Style tab is generated from its policy; if the resolved policy has no Hero entry or is not editable in Brand B's context, the tab has no fields.
I would inspect the copied template's structure nodes for policy references, compare them with Brand A's, and check /conf/acme-b/settings/wcm/policies for a Hero policy. The key judgement is that copying a template node does not create or relink the brand-specific policy configuration.
2. What fix would you apply for Brand B without changing Brand A's authoring experience?
Read the worked answer
Create Brand B's own policy for the Hero under /conf/acme-b/settings/wcm/policies, then map the copied template's Layout Container and Hero structure nodes to that policy. Do not edit Brand A's policy, because Brand A authors depend on it and changes there would affect all Brand A pages.
The fix should be done through the editable-template and policy UI where possible, or via a controlled package if the UI cannot express the mapping. After the policy exists, verify that:
- The Hero appears in the Layout Container's allowed-components list for Brand B.
- The Style tab exposes the three expected options for Brand B.
- Brand A's Style tab and allowed-components list are unchanged.
I would also correct the process that created Brand B: copying a template node in CRX/DE is not equivalent to creating a site template with its own policies. The template type/page component can be shared, but policy ownership should be explicit per brand.
3. How would you structure shared components versus brand policies to prevent this class of problem on the next brand launch?
Read the worked answer
Keep the component implementation shared because the HTL and dialog are common code. Put policy decisions under the brand's /conf/<brand>/settings/wcm/policies tree, and map each brand's templates to its own policies. Shared defaults can exist for development, but production brands should not point at another brand's policy paths.
A repeatable launch checklist would include:
- Create the brand's
/confstructure and template type. - Create or import the required policy set for allowed components and style options.
- Create templates through the template console and map policies explicitly.
- Render one page per template and open every component dialog to verify authoring, not just front-end rendering.
- Compare the new brand's policy references against the source brand to catch copied paths.
The judgement call is to treat policies as brand-owned configuration, not as part of the shared component artifact. That prevents a Brand B change from leaking into Brand A and makes missing policy mappings visible during launch testing.