> For AI agents: the complete documentation index is available at https://nhanbe.id.vn/llms.txt, the full documentation bundle is available at https://nhanbe.id.vn/llms-full.txt. # Templates and Policies **Editable Templates** are AEM's modern template system. They let template authors define page structure, allowed components, and default content visually - without developer intervention. **Policies** attach reusable configuration to components and pages within a template context, controlling everything from allowed heading levels to loaded clientlibs.

defines structure

assigns

creates

configures

Template Type (developer)

Editable Template (template author)

Component / Page Policy

Authored Page

 *** ## Why Editable Templates? Editable Templates replaced the legacy **Static Templates** (`cq:Template`, design mode, `/etc/designs/`). Key advantages: | Feature | Editable Templates | Static Templates (legacy) | | --------------------------- | --------------------------------- | ----------------------------- | | **Who creates templates** | Template authors (non-developers) | Developers only | | **Structure changes** | Visual editor (no code deploy) | Code change + deploy | | **Component configuration** | Policies (per-template) | Design mode (global) | | **Storage** | `/conf/` (content) | `/etc/designs/` (code) | | **Initial content** | Visual authoring | JSP/HTML in code | | **Allowed components** | Per-container, per-template | Global or per-component-group | | **AEMaaCS** | Fully supported | Deprecated | *** ## Architecture ### How templates, types, and pages relate

Content author-managed (/content)

Template author-managed (/conf/.../templates)

Developer-managed (/conf/.../template-types)

Template Type

Structure (locked containers)

Default policies

Editable Template

Structure mode

Initial Content mode

Policy assignments

Page

Authored content

 ### JCR structure ```markdown /conf/mysite/ ├── settings/ │ └── wcm/ │ ├── template-types/ ← Developer-defined │ │ └── content-page/ │ │ ├── jcr:content │ │ │ └── sling:resourceType = "mysite/components/page" │ │ ├── structure/ ← Locked structure │ │ │ └── jcr:content/root/ │ │ │ └── responsivegrid │ │ ├── initial/ ← Default content │ │ └── policies/ ← Default policy mappings │ │ │ ├── templates/ ← Template author-managed │ │ ├── content-page/ │ │ │ ├── jcr:content │ │ │ │ ├── jcr:title = "Content Page" │ │ │ │ ├── status = "enabled" │ │ │ │ └── allowedPaths = ["/content/mysite/.*"] │ │ │ ├── structure/ │ │ │ ├── initial/ │ │ │ └── policies/ │ │ └── landing-page/ │ │ └── ... │ │ │ └── policies/ ← Policy definitions │ └── mysite/ │ ├── components/ │ │ ├── text/ │ │ │ └── default/ ← Policy for text component │ │ │ ├── jcr:title = "Default Text Policy" │ │ │ └── allowedFormats = ["bold", "italic", "links"] │ │ └── image/ │ │ └── default/ │ └── page/ │ └── default/ ← Page policy │ ├── clientlibs = ["mysite.base", "mysite.theme"] │ └── appResourcesPath = "/etc.clientlibs/mysite" ``` *** ## Template Types Template types are the **developer-defined blueprints** that template authors use to create templates. They define the locked structure and default policies. ### Creating a template type ```xml ``` ```xml ``` *** ## Template Editor The Template Editor (**Tools > General > Templates**) provides three modes: ### Structure Mode Defines the **layout skeleton** of the page. Template authors can: - Add layout containers (responsive grids) - Lock or unlock containers (locked = authors cannot move/delete) - Configure allowed components per container - Set the page component (`sling:resourceType`) ### Initial Content Mode Sets **default content** that every new page created from this template starts with. For example: - A hero component with placeholder text - A breadcrumb component - A default footer fragment Authors can modify this initial content when they create a page. ### Policies Mode Assigns **policies** to the page and to individual components. This is where you configure: - Which clientlibs the page loads - Which RTE formats are allowed in text components - Which image sizes are permitted - Style System classes *** ## Page Policies Page policies control **page-level settings** applied to all pages using a template. ### Common page policy properties | Property | Description | | ------------------------ | ----------------------------------------------- | | `clientlibs` | Clientlib categories to load on every page | | `appResourcesPath` | Path prefix for clientlib proxy resolution | | `htmlPageItemsConfig` | Controls `` and `` element ordering | | `responsive/breakpoints` | Responsive grid breakpoint configuration | ### Setting page policy via JCR ```xml ``` ### Reading page policies in Sling Models ```java import com.day.cq.wcm.api.policies.ContentPolicy; import com.day.cq.wcm.api.policies.ContentPolicyManager; import org.apache.sling.api.resource.Resource; import org.apache.sling.models.annotations.Model; import org.apache.sling.models.annotations.injectorspecific.Self; import org.apache.sling.models.annotations.injectorspecific.OSGiService; @Model(adaptables = Resource.class) public class PagePolicyModel { @Self private Resource resource; @OSGiService private ContentPolicyManager policyManager; public String[] getClientlibs() { ContentPolicy policy = policyManager.getPolicy(resource); if (policy != null) { return policy.getProperties().get("clientlibs", String[].class); } return new String[0]; } } ``` *** ## Component Policies Component policies provide **per-template configuration** for components. The same component can behave differently depending on which template it's used in. ### Example: Text component policy A policy that restricts the Rich Text Editor to only bold, italic, and links: ```xml ``` ### Example: Image component policy ```xml ``` ### Reading component policies in Sling Models ```java import com.day.cq.wcm.api.policies.ContentPolicy; import com.day.cq.wcm.api.policies.ContentPolicyManager; @Model(adaptables = SlingHttpServletRequest.class) public class ImageModel { @Self private SlingHttpServletRequest request; @OSGiService private ContentPolicyManager policyManager; public int[] getAllowedWidths() { Resource resource = request.getResource(); ContentPolicy policy = policyManager.getPolicy(resource); if (policy != null) { String[] widths = policy.getProperties() .get("allowedRenditionWidths", String[].class); if (widths != null) { return Arrays.stream(widths) .mapToInt(Integer::parseInt) .toArray(); } } return new int[]{ 320, 640, 1024 }; // defaults } } ``` ### Using currentStyle in HTL `currentStyle` is a global HTL binding of type `com.day.cq.wcm.api.designer.Style` that is available automatically in every component. It exposes the properties from the component's content policy, so no `data-sly-use` is needed: ```html
${properties.text @ context='html'}
``` *** ## Allowed Components Template authors control which components are available per container: ### In the Template Editor 1. Open the template in Structure mode 2. Click on a layout container 3. Open the **Policy** dialog 4. Under **Allowed Components**, check the component groups or individual components ### Allowed component groups ```xml ``` ### Per-container configuration Different containers on the same template can have different allowed components: ```markdown Template: Landing Page ├── Header container → Only: Navigation, Logo, Search ├── Hero container → Only: Hero, Video Hero ├── Content container → All content components └── Footer container → Only: Footer, Legal Text ``` *** ## Style System The **Style System** lets template authors assign CSS classes to components without developer intervention. It builds on top of component policies: ### Defining styles in a policy ```xml ``` Authors select styles via the component toolbar. The selected classes are added to the component's wrapper element. ### Reading styles in Sling Models ```java import com.adobe.cq.wcm.style.ComponentStyleInfo; @Model(adaptables = SlingHttpServletRequest.class) public class StyledComponent { @Self private SlingHttpServletRequest request; public String getAppliedStyles() { ComponentStyleInfo styleInfo = request.getResource() .adaptTo(ComponentStyleInfo.class); if (styleInfo != null) { return styleInfo.getAppliedCssClasses(); // e.g., "btn-lg btn-primary" } return ""; } } ``` *** ## Policy Mapping Policies are mapped to components within a template via `cq:policy` references: ```markdown /conf/mysite/settings/wcm/templates/content-page/policies/ ├── jcr:content │ ├── cq:policy = "/conf/mysite/settings/wcm/policies/mysite/page/default" │ └── root/ │ └── responsivegrid/ │ ├── cq:policy = "/conf/mysite/settings/wcm/policies/mysite/containers/content" │ └── cq:policyMapping = { ... } ``` The `cq:policy` property points to the policy definition node. The template editor manages these mappings automatically. *** ## Locking and Unlocking Structure Template authors can **lock** containers and components in the structure: | Lock state | Author can... | | --------------------------------- | ------------------------------------------------------------ | | **Locked** | Cannot move, delete, or restructure (can still edit content) | | **Unlocked (editable structure)** | Can add, move, and delete components | | **Initial content only** | Component is in initial content but not locked in structure | Locking is set via the `cq:editable` property on the structure node. *** ## Static Templates (Legacy) For reference, legacy static templates use a different mechanism: ```markdown /apps/mysite/templates/ └── content-page/ ├── jcr:primaryType = "cq:Template" ├── jcr:title = "Content Page" ├── allowedPaths = "/content/mysite/.*" └── jcr:content/ └── sling:resourceType = "mysite/components/page" /etc/designs/mysite/ └── jcr:content/ └── component-config... ← Design mode configuration ``` > Static templates are **deprecated** on AEMaaCS. All new projects should use Editable Templates. Existing static templates continue to work but cannot be managed in the Template Editor. *** ## Multi-Site Template Governance ### Shared templates Store templates in a shared `/conf/` location for use across multiple sites: ```markdown /conf/global/settings/wcm/templates/ ← Available to all sites /conf/brand-a/settings/wcm/templates/ ← Brand A only /conf/brand-b/settings/wcm/templates/ ← Brand B only ``` ### Template allowedPaths Restrict which content paths can use a template: ```markdown allowedPaths = ["/content/brand-a/.*"] ``` ### Inheriting policies Policies defined at a higher `/conf/` level are inherited by child configurations, allowing shared base policies with per-site overrides. *** ## Best Practices ### Let template authors own templates Developers create template types; template authors create and manage templates. This separation enables faster iteration without code deployments. ### Use policies for component configuration Never hardcode component settings. Use policies so template authors can adjust behaviour (allowed formats, image sizes, style options) per template. ### Keep template types minimal A template type should define the bare structural skeleton. Template authors add the detail (initial content, specific policies, allowed components). ### Use the Style System instead of component variants Instead of creating `hero-dark`, `hero-light`, and `hero-centered` as separate components, create one `hero` component with a Style System policy that adds CSS classes. ### Version /conf/ content in code Include your template type definitions and default policy configurations in `ui.content` and deploy them via Cloud Manager. Template author changes live alongside this in the content repository. *** ## Common Pitfalls | Pitfall | Solution | | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Template not showing in "Create Page" | Check `status` is `enabled` and `allowedPaths` matches the current content path | | Component not available in a container | Open the template in Structure mode and check the container's policy for allowed components | | Policy values not picked up | Verify the `cq:policy` reference on the template points to the correct policy node | | Style System classes not applied | Ensure the component's HTL wrapper includes the `data-sly-use.style` binding or uses Core Components (which include it by default) | | Design mode settings ignored | Editable Templates do not use `/etc/designs/`; migrate to policies | | Initial content not appearing | Check the template's Initial Content mode; verify the components have content authored | | Template locked for editing | Only users with `template-authors` group membership can edit templates |