Template Editor and Policies

Working in the template editor

The template editor looks like the page editor but edits a different thing. The mode selector in the top-left is the control that matters — everything confusing about templates comes from being in the wrong mode.

• Structure — the permanent skeleton. Components here appear on every page.
• Initial Content — the starting content for new pages.
• Layout — responsive column behaviour per breakpoint.
• Page Design — page-level design settings, including the clientlibs the page pulls in.

Locking and unlocking

In Structure mode, each component has a lock toggle, and it is the most consequential control in the editor:

• Locked — the component is fixed. Authors see it but cannot move, delete or (usually) edit it. Correct for a header, footer or a mandated legal notice.
• Unlocked — the component becomes part of the authorable area, so authors can edit and remove it per page.

Page properties

Every page has a properties dialog — title, description, tags, SEO metadata, publication dates, thumbnail, social settings. These are stored as ordinary properties on the page's jcr:content node, which means reading them is unremarkable:

<!-- In HTL -->
${pageProperties.jcr:description}
${currentPage.title}

// In a Sling Model
@ScriptVariable private Page currentPage;
ValueMap props = currentPage.getProperties();
String subtitle = props.get("subtitle", String.class);

Extending page properties

Adding your own fields is a common requirement — a campaign code, a hero image, a "hide from search" flag. The mechanism is an overlay of the page component's dialog:

1. In your page component (/apps/wknd/components/page), create _cq_dialog/.content.xml.
2. Use sling:resourceType="cq/gui/components/authoring/dialog" and mirror the node structure of the dialog you are extending, adding your tab or fields.
3. Name fields ./mySetting so they write to the page's jcr:content.
4. Use sling:orderBefore to position a new tab sensibly among the existing ones.

Because the page component proxies the Core Components page component, you are extending Adobe's dialog rather than replacing it — the standard tabs keep working and yours appears alongside.

Inheriting page properties down a tree

A frequent need is "set this once on the section root and let child pages inherit it". AEM provides InheritanceValueMap for exactly this:

InheritanceValueMap ivm = new HierarchyNodeInheritanceValueMap(
        currentPage.getContentResource());
String brandColour = ivm.getInherited("brandColour", String.class);

It walks up the page hierarchy until it finds the property. Context-aware configuration (in /conf) is the more structured alternative when the setting is really configuration rather than content.

Design dialogs vs content dialogs

One distinction worth being precise about:

• _cq_dialog — the content dialog. Per-instance values an author sets on this component on this page.
• _cq_design_dialog — the design dialog. Values set once in the template policy and applied to every instance governed by it.

If a setting should be decided by whoever owns the template — allowed heading levels, available style classes — it belongs in the design dialog. If an author sets it per page, it belongs in the content dialog.