How To Use Template Path Hints

Templates

Templates are used at various points in AEM:

When creating a folio you need to select a template; this will be used as the base for the new page. The template defines the construction of the resultant page, whatever initial content and the components that tin can be used (design backdrop).
When creating a Content Fragment y'all also need to select a template. This template defines the structure, initial elements and variations.

The following templates are covered in item:

Page Templates - Editable
Page Templates - Static
Content Fragment Templates
Adaptive Template Rendering

Templates - Pages

AEM now offers two basic types of templates for creating pages:

Notation

When using a template to create a new page there is no visible difference (to the page author) and no indication of the type of template being used.

Editable Templates

Editable templates are at present cosidered best practices for developing with AEM.

The advantages of Editable Templates:

Tin be created and edited by your authors.
Have been introduced to allow you to define the following for whatever pages created with the template:
- the structure
- the initial content
- content policies
Later the new page is created a dynamic connexion is maintained between the folio and the template; this means that changes to the template structure will be reflected on whatsoever pages created with that template (changes to the initial content will not be reflected).
Uses content policies (edited from the template editor) to persist the design properties (does non utilize Design style inside the page editor).
Are stored under /conf
See Editable Templates for further information.

Static Templates

Static Templates:

Must be defined and configured by your developers.
This was the original templating arrangement of AEM and has been available for many versions.
A static template is a hierarchy of nodes that has the same structure as the page to exist created, just without any bodily content.
Are copied to create the new page, no dynamic connection exists after this.
Uses Pattern Style to persist design properties.
Are stored under /apps
Meet Static Templates for further data.

NOTE

Every bit of AEM 6.4 the use of Static Templates is not considered a all-time practice. Use Editable Templates instead.

AEM Modernization tools can aid you migrate from static to editable templates.

Template Availability

CAUTION

AEM offers multiple properties to control the templates immune nether Sites. However, combining them can pb to very complex rules that are difficult to runway and manage.

Therefore, Adobe recommends that y'all start simple, by defining:

only the cq:allowedTemplates property
only on the site root

For an example, meet We.Retail: /content/nosotros-retail/jcr:content

The properties allowedPaths, allowedParents, and allowedChildren can also be placed on the templates to define more sophisticated rules. However, when possible, it is much simpler to define further cq:allowedTemplates backdrop on sub-sections of the site if there is a need to further restrict the immune templates.

An additional advantage is that the cq:allowedTemplates properties tin be updated by an author in the Advanced tab of the Page Properties. The other template properties cannot exist updated using the (standard) UI, so would demand a developer to maintain the rules and a code deployment for every change.

When creating a new page in the site admin interface, the list of available templates depends on the location of the new page and the restrictions on placement specified in each template.

The following properties determine whether a template T is allowed to exist used for a new page to be placed as a child of page P. Each of these properties is a multi-value cord holding zero or more Regular Expressions that are used for matching with paths:

The cq:allowedTemplates holding of the jcr:content subnode of P or an ancestor of P.
The allowedPaths belongings of T.
The allowedParents property of T.
The allowedChildren property of the template of P.

The evaluation works equally follows:

The offset non-empty cq:allowedTemplates holding constitute while ascending the folio bureaucracy starting with P is matched against the path of T. If none of the values friction match, T is rejected.
If T has a not-empty allowedPaths property, but none of the values match the path of P, T is rejected.
If both of the above properties are either empty or non-real, T is rejected unless information technology belongs to the same awarding as P. T belongs to the same application as P if and only if the proper noun of the 2d level of the path of T is the same as the proper noun of the second level of the path of P. For case, the template /apps/geometrixx/templates/foo belongs to the same application equally the page /content/geometrixx.
If T has an not-empty allowedParents property, merely none of the values lucifer the path of P, T is rejected.
If the template of P has a non-empty allowedChildren property, but none of the values lucifer the path of T, T is rejected.
In all other cases, T is immune.

The post-obit diagram depicts the template evaluation process:

chlimage_1-176

Limiting templates used in child pages

To limit what templates tin can be used to create child pages under a given folio, use the cq:allowedTemplates property of jcr:content node of the page to specify the list of templates to be allowed equally child pages. Each value in the listing must exist an absolute path to a template for an allowed child page, for instance /apps/geometrixx/templates/contentpage.

You can utilize the cq:allowedTemplates property on the template'southward jcr:content node to have this configuration applied to all newly created pages that use this template.

If you lot desire to add more than constraints, for example regarding the template bureaucracy, you tin employ the allowedParents/allowedChildren properties on the template. You lot tin then explicitly specify that pages created from a template T have to be parents/children of pages created from a template T.