STK areas

All STK pages are rendered by the main.ftl script that includes the areas using the [@cms.area name] tag. Pages rely on the STKPage Java class as extended by the STKPageModel for functionality.

htmlHeader area

The htmlHeader area controls the elements within the <head> tag of the HTML.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/htmlHeader and is used by all templates, i.e. it is not modified by any of the individual template definitions. The area is enabled by default and is a noComponent area rendered by the htmlHeader.ftl area script accessible in Templates > /templating-kit/pages/global.

The htmlHeader.ftl scripts inserts the <meta> tags into the <head> element of the HTML code.

The meta http-equiv attribute provides an HTTP header for the information/value of the content attribute and defines the character set.
The keywords and description tag content is entered in tabMetaData of the properties dialog accessed by clicking Properties in the top bar. If no description is inserted, the content of the abstract field in the intro dialog is used.
The title tag is a combination of the site and page title separated by a dash ( - ). This content displays in the browser window and tabs unless amended in the properties dialog:

The site title is inserted in the Home page properties dialog.
The page title is the title in AdminCentral or any amendment to it in the title field of the intro dialog.

The robots tag allows the search engines to index and spider the page.

Here are the relevant snippets from the script:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<meta name="keywords" content="${content.keywords!content.title!content.@name}" />
<meta name="description" content="${content.description!content.abstract!}" />
<meta name="author" content="" />
<meta name="robots" content="all" />
…
[#assign pageModel = model.root!]
[#assign pageDef = pageModel.definition!]
[#assign homeName = stkfn.homeName(content)!]
[#assign homeTitle = stkfn.homeTitle(content)!]
[#assign siteTitle = stkfn.siteTitle(content)!homeTitle!homeName!]
[#assign contentPageTitle = content.windowTitle!content.title!content.@name]
<title>${siteTitle} - ${contentPageTitle}</title>

Here's the rendered HTML for an article page.

CSS and JavaScript

The htmlHeader.ftl script ensures that the appropriate JavaScripts and CSS sheets are loaded.

References to CSS sheets and JavaScripts can be defined at a theme, site and page level. In the STK they are defined at a theme level:

Different CSS sheets are used depending on the viewer's screen size and device. For more information see Themes > CSS.
Different JavaScripts can be used for different themes. For example those used by the desktop pop theme are different to those of the pop-mobile theme used by the smartphone variation. For more information see Themes > JavaScript and Mobile > JavaScript.

Here are the relevant code snippets from the script.

…
[/#list]
[#list pageDef.cssFiles as cssFile]
    <link rel="stylesheet" type="text/css" href="${cssFile.link}" media="${cssFile.media}" />
[/#list]
…
[#list stkfn.theme(pageModel.site).jsFiles as jsFile]
    <script src="${jsFile.link}" type="text/javascript"></script>
[/#list]
…

Here's the rendered HTML for an article page using Firefox's iPhone 3.0 user agent on a desktop computer. This activates the smartphone variation that uses the pop-mobile theme. Note that only mobile-specific JavaScript is loaded.

Legacy browser support

Legacy browser support is provided in the htmlHeader.ftl script as follows:

For IE the <meta http-equiv> attribute is set to "X-UA-Compatible" content="IE=Edge,chrome=IE7". This forces IE to use the most recent rendering engine or to use Chrome's frame rendering engine if available.
The viewport tag sets the browser’s layout viewport to the actual device-width, overriding any width set by the vendor. This specifies how the browser should display the page zoom level and dimensions. When omitted, many mobile browsers use a "virtual" page width of about 900 pixels to make it work well with existing desktop sites but the screens may look zoomed out and too wide. By setting the viewport attributes, the width is set to the pixel width of the device screen.
Conditional comments are used for older IE browsers that do not support media queries. This ensures that the media queries degrade gracefully. See CSS media queries for more information. Media queries are used to create the flexible page grid. The conditional comments are defined in Themes > /pop/cssFiles/ie6/conditionalComment and /ieStyles/conditionalComment:

For IE 6 a separate style sheet, ie6.css, is used. You can access this sheet in Resources > /templating-kit/themes/pop/css/ie6.css.
IE 7 and 8 use the main style sheet, styles.css, that includes IE-specific rules. You can access this sheet in Resources > /templating-kit/themes/pop/css/styles.css.

Here are the relevant snippets from the script.

…
<!--[if IE]>
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=IE7" />
<![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
…
    [#if cssFile.conditionalComment?has_content]
    <!--[if ${cssFile.conditionalComment}]>
    [/#if]
    <link rel="stylesheet" type="text/css" href="${cssFile.link}" media="${cssFile.media}" />
    [#if cssFile.conditionalComment?has_content]
    <![endif]-->
    [/#if]
…

Logo image link

The logoImageLink is also rendered by the htmlHeader.ftl script. See logo area below for more.

Here's the relevant extract from the script:

[#if pageModel.logoImageLink?has_content]
    <style type="text/css">
        #logo span {
            background-image: url('${pageModel.logoImageLink}');
        }
    </style>
[/#if]

branding area

The branding area controls the page header elements and includes three child areas: logo, search and metaNavigation.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/branding is used by all templates. The area is enabled by default and is a noComponent area rendered by the branding.ftl area script accessible in Templates > /templating-kit/pages/global.

The branding.ftl script:

Wraps the content in <div id="branding"> and adds the WAI-ARIA aware role="banner" attribute. This is HTML5 compliant.
The skip link allows screenreaders to skip the navigation and move directly to the main content. This complies with WAI-ARIA best practices.
Includes the child areas using the [@cms.area name] tag and wraps them in the nested <div id="branding-box">.

Here's the full script:

<div id="branding" role="banner">
    <div id="branding-box">
        <p class="skip">
           <a href="#main">${i18n['accessibility.header.mainContent']}</a>
        </p>
        [@cms.area name="logo" content=content/]
        [@cms.area name="search" content=content/]
        [@cms.area name="metaNavigation"/]
    </div><!-- end branding-box -->
</div><!-- end branding -->

logo area

The logo area controls the Web and print logo images, and the slogan. The prototype configuration in Site Definitions > /default/templates/prototype/areas/branding/areas/logo is used by all templates. The area is enabled by default and is a noComponent area rendered by the logo.ftl area script accessible in Templates > /templating-kit/pages/global.

For corporate branding, SEO and accessibility purposes the way the logo image is marked up in the HTML is important.

The logo.ftl script:

Wraps the content in <div id="logo">.
Ensures that the logo content is inherited by all pages of the site.
Assigns the homeName, homeTitle, siteTitle, logoImageLink, printLogoImageLink and logoAltText. This content is entered in the stkHomeProperties properties dialog.

Here's the full script:

[#assign pageModel = model.root!]

[#-- Assigns: The content for the logo  --]
[#assign inhContent = cmsfn.inherit(content)!]
[#assign homeName = stkfn.homeName(content)!]
[#assign homeTitle = stkfn.homeTitle(content)!homeName!]
[#assign siteTitle = stkfn.siteTitle(content)!homeTitle!]
[#assign logoImageLink = pageModel.logoImageLink!]
[#assign printLogoImageLink = pageModel.printLogoImageLink!logoImageLink!]
[#assign logoAltText = inhContent.alternativeLogoText!siteTitle!]

<div id="logo">
    <a href="${stkfn.homeLink(content)}" title="${i18n['logo.title']}">
        [#if printLogoImageLink?has_content]<img src="${printLogoImageLink}" alt="${logoAltText}" />[/#if]
        [#if logoAltText?has_content]<strong>${logoAltText}</strong>[/#if]
        [#if inhContent.slogan?has_content]<em>${inhContent.slogan}</em>[/#if]
        <span></span>
    </a>
</div><!-- end logo -->

Here's the rendered HTML for an article page.

search area

The search area consists of the Search box and button that renders in the header of every page. Search results display on a page based on the stkSearchResult template that contains the stkSearchResult feature component in the main/content area. The search page is linked in the stkHomeProperties properties dialog in the searchUUID field. Only one search page per site is required and it is normally hidden in navigation because it only renders meaningful content when a search is executed. For more information see Search.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/branding/areas/search is used by all templates. The area is enabled by default and is a noComponent area rendered by the search.ftl area script accessible in Templates > /templating-kit/pages/global. You can disable the area for any template if you do not want the search box to render.

The search.ftl script:

Wraps the search area in <div id="search-box">.
Complies with accessibility standards.
Includes the HTML5-compliant required, type and other attributes in the <form> tag:.

Here's the full script:

<div id="search-box">
    <h6>${i18n['accessibility.header.search']}</h6>
    <form action="${stkfn.searchPageLink(content)!}" >
    <div>
        <label for="searchbar">${i18n['accessibility.header.searchFor']}</label>
        <input required="required" id="searchbar" name="queryStr" type="text" value="${ctx.queryStr!?html}" />
        <input class="button" type="submit" value="${i18n['button.label.search']}" />
    </div>
    </form>
</div><!-- end search-box -->

The stkSearchResults component that renders the results:

Is rendered by the searchResult.ftl script accessible in Templates > /templating-kit/components/features.
Uses the SearchResultModel that relies on the SearchResultItem Java class.

metaNavigation area

The metaNavigation area is in the top right-hand corner of the header. It is designed for internal and public user registration links, such as login, logout and registration links.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/branding/areas/metaNavigation is used by all templates except stkHome. The area:

Is list area and the stkInternalLink and stkPURLink components are available.
Is rendered by the metaNavigation.ftl area script accessible in Templates > /templating-kit/pages/global. This is a standard list area script that renders the components sequentially.
Prohibits editing of components by default by setting the editable property to false.
Enables inheritance with the components property is set to all, which means that the components cascade automatically on all child pages of the site.

On the stkHome template the setting of the /metaNavigation/editable property is reversed making it possible to only add and edit components on the home page.

sectionHeader area

The sectionHeader area renders on all templates except stkHome, but the area is only used by the stkSection template. The area is located between the horizontal navigation and the breadcrumb areas. The Section Header component has a distinct blue background and contains title and text fields that are typically used to summarize the content of the site section. This component is inherited by all child pages of the section.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/sectionHeader is used by all templates except stkSection. The area:

Is enabled by default.
Is a noComponent area.
References the stkSectionHeader dialog configured at Dialog Definitions > /pages/section/stkSectionHeader.
Note the templateScript reference in the prototype configuration is an error as no such script exists, but this is immaterial as the correct script is referenced in the stkSection template definition (see below).
Uses the SectionHeaderAreaModel modelClass.
Is not editable by default.

In the stkSection template definition:

The prototype setting of the editable property is reversed making the component editable only on section pages.
The templateScript property references the /section/sectionHeader.ftl script accessible in Templates > /templating-kit/pages/section.

In the stkHome template the area is disabled.

The Section Header component is not configured like most STK components and you will not find a corresponding component template definition and script for it. It is rendered by the area script, sectionHeader.ftl, that assigns and renders the content entered in the stkSectionHeader dialog. Here' the rendering part of the script that:

Wraps the area in <div id="section-header>.
Renders the dialog content.

 …
[#-------------- RENDERING PART --------------]
[#-- Rendering: Section Header --]
[#if hasSectionTitle || hasSectionText || cmsfn.editMode ]
    <div id="section-header">
        [#if hasSectionTitle]<h5>${sectionTitle}</h5>[/#if]
        [#if hasSectionText]<p>${sectionText}</p>[/#if]
    </div><!-- end section-header -->
[/#if]

The SectionHeaderAreaModel ensures inheritance using inherit(getRoot().getNode().

 public String getSectionTitle() throws RepositoryException {
  return PropertyUtil.getString(templatingFunctions.inherit(getRoot().getNode()), "sectionTitle");
}
public String getSectionText() throws RepositoryException {
  return PropertyUtil.getString(templatingFunctions.inherit(getRoot().getNode()), "sectionText");

stage area

The stage area only renders on the stkHome template. The area is located between the horizontal navigation and main area.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/stage is used by all templates except stkHome. The area:

Makes two components available to editors: stkStageXL (single internal teaser) and stkStagePaging (numerous paging internal teasers).
Is disabled by default.
Is a single area that means only one component can render
Is rendered by the stage.ftl area script accessible in Templates > /templating-kit/pages/home. This is a standard single area script.
Is an optional area meaning that an editor can choose to delete it.

In the stkHome template definition the prototype setting of the enabled property is reversed ensuring that the area only renders on home pages.

You can enable the stage area on any template. Here's an article page with with the stage area enabled.

platform area

The platform area is not used on any of the templates, but is a nice addition to a page. The area is located above the main content and spans main and extras areas.

The prototype configuration is in Site Definitions > /default/templates/prototype/areas/platform. The area:

Makes the stkTeaserPaging component available to editors, but you can add additional components.
Is disabled by default.
Is a list area which means that sequential components can render in it.
Is rendered by the platformArea.ftl area script accessible in Templates > /templating-kit/pages/global. This is a standard list area script.

Here's the configuration to enable the area on the stkArticle template.

main area

main area is the area that displays the most important content on the page. For example, on a news page the main area contains the news story.

The main area consists of several child areas. You will find a different number of child areas depending on the page template. All templates have an intro and content area. The child areas that are available depend on the purpose of the page template:

Content templates such as stkNews contain content components.
Section templates such as stkSection contain teaser components.
Feature templates such as stkFAQ contain a single auto-generated feature component.

Below is an example of the main area in the stkArticle template. By default, the template renders the breadcrumb, intro, content and comments areas. contentNavigation is an optional area that you can switch on when needed.

Configuring the main area

The main area prototype configuration is in Site Definitions > /default/templates/prototype/areas/main. The default configuration defines default settings for all child areas except opener which is configured in the stkSection template.

The configuration defines the main area as a noComponent area which means editors cannot add components to the area directly, only to its child areas. The main area logic is in the MainArea class and is rendered by the global/mainArea.ftl area script.

The main area does not vary much from one template to the next. The only exceptions defined in the templates are the templateScript and class properties. Three different mainArea.ftl scripts are used across the templates:

/global/mainArea.ftl is the default script.
/section/mainArea.ftl is used by the stkSection and stkHome templates, adding the opener child area. These templates also use a different class (see below).
/content/mainArea.ftl is used by stkArticle and its extensions, stkImageGallery and stkFaq. It adds the contentNavigation and comments child areas.

All three scripts wrap the main area in a <div id="main"> element and add the HTML5 WAI-ARIA aware role="main" attribute. Below is the content/mainArea.ftlscript used for content pages.

<div id="main" role="main">
    [@cms.area name="contentNavigation" content=content/]
    [@cms.area name="breadcrumb" content=content/]
    <div class="text" role="article">
        [@cms.area name="intro" content=content/]
        [@cms.area name="content"/]
    </div><!-- end text -->
    [@cms.area name="comments"/]
</div><!-- end main -->

Floating in the main area

The stkSection and stkHome templates use the SectionMainArea class that extends the default MainArea class to include the opener area and provides floating. When floating is enabled, components in the area reposition or "float" to adapt to the user's viewport. For more information see Flexible grid.

The number of columns the components occupy is configured in the columns property. The BodyClassResolver class reads the value and assigns the appropriate bodyClass . Teaser components further have a teaserCount that ensures positioning and styling. See Teaser ids.

Three template definitions have a floating node the main area:

stkHome enables floating and sets columns to 3.
stkSection disables floating and sets columns 1.
stkSectionFloating enables floating sets columns to 2. This template extends the stkSection template.

Below is the content area of a section page at 1600 px viewport width. The components are allowed to float side-by-side into two columns since there is enough screen real estate.

Here is the same areas at 950 px. The components are now positioned into a single column.

See Enabling floating for a more detailed discussion.

breadcrumb area

The breadcrumb area is located below the sectionHeader area. It contains clickable links that match the page structure and allows the user to navigate to any parent page.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/main/areas/breadcrumb is used by all templates except stkHome. The area definition:

Is enabled by default. The default for the enabled property is true even if the property is not explicitly included in the definition. It is only strictly necessary to include it when you want to optionally enable and disable the area, or disable it by default.
Defines the area as a noComponent area.
Uses the BreadcrumbAreaModel modelClass.
Is rendered by the breadcrumb.ftl area script accessible in Templates > templating-kit/pages/global.

The area is unnecessary on the stkHome template and is disabled in Template Definitions > /stkHome/areas/main/areas/breadcrumb/enabled.

Here's a snippet from BreadcrumbAreaModel:

public Collection<Link> getBreadcrumb() throws RepositoryException {
         List<Node> ancestors = stkFunctions.ancestorsInSite(content, MgnlNodeType.NT_PAGE);
         List<Link> items = new ArrayList<Link>();
         for(Node current : ancestors){
             items.add(Components.newInstance(Link.class, current));
         }
         items.add(Components.newInstance(Link.class, content));
         return items;

The breadcrumb.ftl script:

Wraps the content in <div id="breadcrumb">.
Is i18n aware.
Uses the [#List] directive to render, create links and format the content items.

<div id="breadcrumb">
    <h5>${i18n['nav.selected']}</h5>
    <ol>
      [#list model.breadcrumb as item]
          [#if item_has_next]
              <li><a href="${item.href}">${item.navigationTitle}</a></li>
          [#else]
              <li><strong>${item.navigationTitle}</strong></li>
          [/#if]
      [/#list]
    </ol>
</div><!-- end breadcrumb -->

contentNavigation area

The contentNavigation area is used on the content templates, i.e. stkArticle and its extensions. The area is located between the breadcrumb and intro areas. Navigation within the area starts where the site navigation ends, and allows for navigation deep within the page hierarchy.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/main/areas/contentNavigation:

Is disabled by default.
Defines the area as a noComponent area.
Uses the ContentNavigationAreaModel modelClass.
Is rendered by the contentNavigation.ftl area script accessible in Templates > templating-kit/pages/content.

In the stkArticle template the area is enabled in Template Definitions > /stkArticle/areas/main/areas/contentNavigation/enabled. This configuration in turn enables the area for all content templates.

Here's the relevant snippet from ContentNavigationAreaModel:

public Collection<Link> getContentNavigation() throws RepositoryException {
         STKPageModel<STKPage> pageModel = (STKPageModel<STKPage>) getRoot();
         int maxNavLevel = pageModel.getNavigation().getHorizontalLevel() + pageModel.getNavigation().getVerticalLevel() + getSiteRoot().getDepth();
          Iterable<Node> children = NodeUtil.getNodes(getRoot().getNode(), MgnlNodeType.NT_PAGE);
         Iterator<Node> childrenIterator = children.iterator();
int depth = content.getDepth();
         if(depth >= maxNavLevel &amp;&amp; childrenIterator.hasNext()) {
             List<Link> items = new ArrayList<Link>();
              while(childrenIterator.hasNext()) {
                 Node current = childrenIterator.next();
                 items.add(Components.newInstance(Link.class, current));
             }
             return items;
         }
          return null;

The contentNavigation.ftl script:

Wraps the content in <div id="nav-content">.
Is i18n aware.
Uses the [#List] directive to render, create links and format the content items.

[#if model.contentNavigation?exists]
    <div id="nav-content">
        [#if content.title?has_content]<h3><em>${i18n['contentNavigation.index.title']} </em>${content.title}</h3>[/#if]
        [#list model.contentNavigation as item]
        <ul>
            <li><a href="${item.href}">${item.title}</a></li>
        </ul>
        [/#list]
    </div><!-- end nav-content -->
[/#if]

intro area

The intro area is used by all templates except stkHome. One component, Page Header, renders in the area. intro is an important area that distinguishes and is integral to the page template.

The Page Header component is not configured in the standard way and you will not find a corresponding component definition for it. The component content is rendered by the area script.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/main/areas/intro:

Defines default settings for the infoBlock child area. This area is used by the stkEvent template.
Is enabled by default.
Is a noComponent area.
Uses the MainAreaIntro class.
Is rendered by the mainAreaIntro.ftl area script accessible in Templates > /templating-kit/pages/global.
Sets the default settings for the show properties that determine which content to render in the component. These properties are exposed to the template by the MainAreaIntro class:

showAbstract: The content of the abstract field.
showAuthorDate: The content of the author and date fields
showCategories: Categories selected in tabCategorization of the stkArticleIntro intro dialog. By default, categorization is available on the stkArticle and stkLargeArticle templates. For more on categories see Categorization module.
showImage: The content of the image field
showTOC: A Table of Content (TOC). This option is only used by the stkLargeArticle template.
showTextFeatures: The print and bookmarking options that render in the content templates.

Here's a snippet from the MainAreaIntro class:

private String divID; 
private Boolean showTOC;
private Boolean showAuthorDate;
private Boolean showAbstract;
private Boolean showTextFeatures;
private Boolean showCategories;
private Boolean showImage;

All page templates use the same class and templateScript properties. Each template definition at Template Definition > /pages/<template name>/areas/main/areas/intro:

Selectively changes the default settings of the show properties.
Links to the corresponding intro dialog configured in Dialog Definitions > /pages.
Where necessary, defines the <div-id> for the component for CSS styling.

Each intro dialog definition has fields that allow for the show properties setting in the area template definition. Here's the dialog definition for the stkArticle template configured at Dialog Defintions > /pages.

The stkHome template is the single exception:

The intro area is disabled in Template Defintions > stkHome/areas/main/areas/intro/enabled.
The class property is added and references the same class as the prototype definition.
The title and abstract content is made available in the stkHomeProperties properties dialog.

Where an area definition in the template prototype uses its own class, it is necessary to also include a reference to this class in the template definition. This is because the template merging process instantiates both definitions and their classes at the same time. If no class is found in the template definition the fallback class, ConfiguredAreaDefinition, is used.

The mainAreaIntro.ftl script assigns and renders the properties made available in the definition. Here's the rendering part of the script. Note the following:

The area is wrapped in <div class="text meta"> and the HTML5 WAI-ARIA aware role="contentinfo" attribute is included.
The author, date and location are wrapped in nested <li class> elements. This structure is important for rich snippet parsing. See Microformats for more information.
The [@cms.area name] tag is used to include the infoBlock child area used by the stkEvent template.
The [#include] directive includes the textFeatures.ftl and contentTable.ftl scripts. These scripts render the bookmark dropdown and TOC and are accessible in Templates > /templating-kit/pages/content.
The ImageModel exposed by the STKPageModel is used for image rendering.

[#-------------- RENDERING PART --------------]
[#-- Rendering: Main Area Intro --]
[#if intro.divID??]
    <div id="${intro.divID}">
[/#if]
[#if hasTitle]
    <h1>
        [#if hasKicker]<em>${kicker}</em>[/#if]
        ${title}
    </h1>
[/#if]
[#if (showAuthorDate &amp;&amp; (hasDate || hasAuthor || hasLocation)) || showTextFeatures || (showCategories &amp;&amp; hasCategories)]
    <div class="text-meta" role="contentinfo">
        [#if showAuthorDate]
            [#if hasDate || hasAuthor || hasLocation]
                <ul class="text-data">
                    [#if hasDate]
                        <li class="date">${date?date?string.medium}</li>
                    [/#if]
                    [#if hasAuthor]
                        <li class="author">${author}</li>
                    [/#if]
                    [#if hasLocation]
                        <li class="location">${location}</li>
                    [/#if]
                </ul>
            [/#if]
        [/#if]
        [#if showTextFeatures]
            [#include "/templating-kit/pages/content/textFeatures.ftl"]
        [/#if]
        [#if showCategories &amp;&amp; hasCategories]
            <dl>
                <dt>${i18n['mainAreaIntro.category.label']}</dt>
                [#list categories as item]
                    [#-- Macro: Item Assigns --]
                    [@assignItemValues item=item /]
                    <dd><a href="${itemLink}" >${itemDisplayName}</a></dd>
                [/#list]
            </dl>
        [/#if]
    </div><!-- end text-meta -->
[/#if]
[@cms.area name="infoBlock" content=content/]
[#if showImage &amp;&amp; hasImage]
    <img class="${imageModel.imageClass}" src="${imageModel.image.link}" alt="${imageModel.image.caption!"Image "+content.title!content.@name}" />
[/#if]
[#if showAbstract &amp;&amp; hasAbstract]
    [#if !intro.divID?has_content]
        [#assign abstractClass = 'class="intro"']
    [/#if]
    <p ${abstractClass!}>${abstract}</p>
[/#if]
[#if showTOC]
    [#include "/templating-kit/pages/content/contentTable.ftl" ]
[/#if]
[#if intro.divID??]
    </div>
[/#if]

Here's the rendered HTMl for an article page.

In the JCR, the content of the Page Header component is stored at a page level, and not at an area level, as is the case with most components. You can verify this in Tools > JCR Browser (Website).

infoBlock area

The infoBlock area is a child area of the intro area. It is used on the stkEvent template to add hCalender mifroformat support and special styling on event pages. This area is fully discussed in Microformats > hCalender.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/main/areas/intro/area/infoBlock:

Disables the area.
Defines the area as a noComponent area.

The stkEvent template definition in Template Definitions > /pages/stkEvent/areas/main/areas/intro/areas/infoBlock:

Enables the area.
References the infoBlock.ftl script that renders the area.

opener area

The opener area is unique to the stkSection template. The area contains a large single internal teaser component. The area is located between the intro and content areas.

The area configuration is in Template Definitions > /pages/stkSection/areas/main/opener and is not configured in the prototype like most other areas. The area definition:

Makes the stkTeaserOpener component available in the area.
Enables the area.
Defines the area as a single area meaning that only one component can render but additional components can be made available as alternatives.
Defines the area as optional meaning that an editor may choose to delete it.
Is rendered by the opener.ftl script accessible in Templates > /templating-kit/pages/section . This is a standard single script.

content area

The content area contains the bulk of the page content and is the main distinguishing factor between the templates because different component types are made available in the area. In the:

Content templates, content components, such as stkTextImage and stkQuotedText, are available.

stkHome and stkSection templates, teaser components are available.

Feature templates, a single feature component is available.

The prototype area definition in Site Definitions > /default/templates/prototype/areas/main/areas/content is minimal and:

Enables the area.
Defines the area as a list area meaning a number of components can render sequentially.
References the areas.templates.main.content.title message bundle key in the title property. The corresponding value is "Content" that renders in the area toolbar.

Note! The definition does not reference a templateScript and the standard list area code is used by default.

In the individual template definitions in Template Definitions > /<template name>/areas/main/areas/content:

The content templates make content components available.

In the stkHome and stkSection templates:

Teaser components are available. In stkSection 12 teasers are available, but the selection on stkHome is limited to the stkTeaser, stkTeaserNewsList, stkTeaserEventsList, stkTeaserGroup, stkTeaserHorizontalTabbed and stkTeaserPureLinkList components.
The area is rendered by the /section/contentArea.ftl script accessible in Templates > /templating-kit/pages/section.
References the templates.stkSection.areas.main.content.title message bundle key in the title property. The corresponding value is "Teasers" that renders in the area toolbar.

The /section/contentArea.ftl script is a standard list area script with the addition of the following code to render the nested <div class="teaser"> elements and the teaserCount. For more information see Teaser ids.

<div class="teaser" id="teaser-${stkfn.count('teaser')}" cms:add="box"></div>

The feature templates make a single feature component available. These area template definitions are discussed in Feature components.

comments area

The comments area includes a commenting component that allows users to comment on the content of the page. By default, the area is only used by the content templates because of its inclusion in the /content/mainArea.ftl script that renders main area, but can be added to any of the mainArea scripts.

There are two alternatives in the STK:

Magnolia commenting provided by the Commenting module.
Intense Debate commenting provided as a third party service.

The screenshot below shows the Magnolia stkCommentscomponent on an article page.

The prototype definition in Site Definitions > /default/templates/prototype/areas/main/areas/comments is used by all content templates and no changes are defined in the individual template definitions: The definition:

Makes the comments component available in the area. This is the Magnolia commenting component that is configured in Configuration > /modules/commenting/templates/components/comments. For more information see Magnolia commenting.
Uses the CommentsArea class that makes the intenseDebateId property available to the third party software. For more information see Intense Debate commenting.

extras area

The extras area is a promotional area and a variety of teaser components are available. The area is located between main and promos areas . The area contains three child areas, module, extras1 and extras2, and a number of configuration options are available. By default the area renders in a single column.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/extras is used by all templates and there are no changes in the template definitions. The definition:

Defines the default settings for the child areas: module , extras1 and extras2.
Uses the ExtrasArea class that makes the columns and small properties available to the template.
Defines the area as a noComponent area.
Is rendered by the extrasArea.ftl area script accessible in Templates > /templating-kit/pages/global.
Sets the defaults for the columns and small properties to 1 and true, rendering the area in a small single column.

The extrasArea.ftl script:

Wraps the content in <div id="extras"> and adds the WAI-ARIA aware HTML5 role="complementary" attribute.
Includes the child areas using the [@cms.area name] tag.
Reads the column property exposed by the class.
Renders the extras2 area only if the columns property is set to 2.

<div id="extras" role="complementary">
    [@cms.area name="module"/]
[#if def.columns > 1]
        [#list 1..def.columns as columnIndex]
            <div id="extras-${columnIndex}">
                [@cms.area name="extras${columnIndex}"/]
            </div>
        [/#list]
    [#else]
        [@cms.area name="extras1"/]
    [/#if]
</div>

The possible configurations for the extras area are discussed in Configuration options below

module area

The prototype definition in Site Definitions > /default/templates/prototype/areas/extras/areas/module:

Makes the stkExtrasHorizontalTabbed component available in the area. You can make additional components available.
Defines the area as a single area meaning that one component can render in the area.
Disables the area by default.
Is rendered by the moduleArea.ftl area script accessible in Templates > templating-kit/pages/global. This is a standard single area script that wraps the content in <div id="module">.

The module area spans two columns and renders in the first position in the extras area. When this area is enabled you have two options within the extras area for the content that renders below the module area:

One large extras column, i.e. the extras1 area.
Two small extras columns rendering side by side, i.e. the extras1 and extras2 areas.

See Configuration options below for how to configure these.

extras1 and extras2 areas

The prototype definitions in Site Definitions > /default/templates/prototype/areas/extras/areas/extras1 and extras2 are identical: The definitions:

Make numerous teaser components available.
Enable the areas.
Define the areas as list areas meaning that many components can render sequentially.
Are rendered by the extrasSubArea.ftl area script accessible in Templates > /templating-kit/pages/global. This is a standard list area script.
Enable inheritance in the areas. /inheritance/components is set to filtered making it an editorial decision whether a component cascades on child pages. The corresponding component dialog definitions configured in Dialog Definitions > /components/extras each contain the Show in subpage field that when checked causes the component to render on child pages.

You can use these areas with the module area as shown in the previous section or without it, in which case you have three options:

The default prototype configuration that renders a single small column.
A large single column.
Two small columns.

See Configuration options below for how to configure these.

Configuration options

The various configuration options for the extras area are discussed below. We use the stkArticle template to demonstrate how to vary the prototype configuration in a template definition. Note the following about all the options:

The page layout is determined by the bodyClass that is resolved automatically by the BodyClassResolver Java class. This class determines the number and specifics of the allowedBodyClasses. See Body classes for more information.
A class property referencing the same class as the prototype, i.e. the ExtrasArea class, needs to be added to the area definition of the parent extras area.

Adding a class property in the template definition is only necessary when the prototype area definition uses its own class. This is because the template merging process instantiates both definitions and their classes at the same time. If no class is found in the template definition the fallback class, ConfiguredAreaDefinition, is used.

Vertical navigation disabled

If the vertical navigation is disabled the page bodyClass resolves automatically to the following allowedBodyClasses:

col-subcol-equal when a single large extras column is used, either with or without the module area.
col-subcol-subcol when two extras columns are used, either with or without the module area.

Here's the configuration to render the modulearea with a single large extras column:

The /navigation/vertical/enabled node disables the vertical navigation.
The /areas/extras node:

Sets the class to info.magnolia.module.templatingkit.templates.ExtrasArea.
Sets the small property to false reversing the prototype configuration and resulting in a large single column.
Leaves the prototype columns value unchanged, i.e. it remains set to 1.

The /extras/areas/module/enabled node enables the module area.

Here's the layout of a new article page.

To omit the module area and render only a single large extras column, either change the value of the /module/enabled to false node or delete it, and the prototype configuration will be used.

To render the module area with two extras columns make the following changes to the configuration above:

Set the /areas/extras/small property to true.
Add an /extras/columns property and set the value to 2.

Here's the layout of a new article page.

To omit the module area and render only two single small extras column either change the value of the /module/enabled node to false or delete it, and the prototype configuration will be used.

Vertical navigation enabled

This option requires that you override the automatically generated bodyClass and we recommend that you do this only in a template configured for this specific purpose.

You can render both the vertical navigation and a two column or large column extras area by:

Overriding the automatically generated bodyClass and
Disabling the promos area.

Here's the configuration to render the modulearea with a single large extras column:

The <template name>/bodyClass property is set to col-subcol-equal which is an allowed body class.
The /areas/extras node:

Sets the class to info.magnolia.module.templatingkit.templates.ExtrasArea.
Sets the small property to false reversing the prototype configuration and resulting in a large single column.
Leaves the prototype columns value unchanged, i.e. it remains set to 1.

The /extras/areas/module/enabled node enables the module area.
The /areas/promos/enabled node disables the promos area.

Here's the layout of a new article page.

To omit the module area and render only a single large extras column either change the value of the /module/enabled node to false or delete it, and the prototype configuration will be used.

To render the module area with two extras columns make the following changes to the configuration above:

Set the <template name>/bodyClass property to col-subcol-subcol. This is an allowed body class.
Set the /areas/extras/small property to true.
Add a /extras/columns property and set the value to 2.

Here's the layout of a new article page.

To omit the module area and render only two single small extras column either change the value of the /module/enabled node to false or delete, it and the prototype configuration will be used.

Make components available

You can also make other teasers available in the module area. Because it is a single area only one component can render, but editors can be given a choice of components. Here's the configuration that adds the stkTeaserContact component.

Here's the rendered component.

promos area

The promos area renders to the right of the extras area. It is a promotional area in which a single teaser component is available by default.

The prototype definition in Site Definitions > /default/templates/prototype/areas/promos is used by all templates. The definition:

Makes the stkPromo component available.
Enables the area by default.
Defines the area as a list area meaning that a number of components can render sequentially.
Is rendered by the promosArea.ftl area script accessible in Templates > /templating-kit/pages/global. This is a standard list area script that wraps the content in <div id="promos">.
References the areas.templates.promos.title message bundle key in the title property. The corresponding value is "Promos" that renders in the area toolbar.

base area

The base area spans the width of the page and renders above the footer. It is a promotional area in which teaser components are available by default.

The prototype definition in Site Definitions > /default/templates/prototype/areas/base is used by all templates. The definition:

Makes the stkTeaserCarousel and catCloudWide components available. The category cloud is part of the Categorization module.
Enables the area by default.
Defines the area as a list area meaning that a number of components can render sequentially.
Is rendered by the baseArea.ftl area script accessible in Templates > templating-kit/pages/global. This is a standard list area script.

footer area

The footer area is located at the bottom on the page. Like the header, the content is added on the home page and inherited by all pages of the site.

The prototype configuration in Site Definitions > /default/templates/prototype/areas/footer is used by all templates except stkHome. The definition:

Makes the stkFooterLinkList and stkFooterAbout components available.
Enables inheritance in the area. /inheritance/components is set to all meaning that components cascade automatically.
Defines the area as a list area meaning a number of components can render sequentially.
References the stkFooter dialog configured in Dialog Definitions > /pages/footer. This dialog contains the copyright field that renders at the bottom of the page.
Sets the editable property to false making the components non-editable on all pages except stkHome.
Uses the FooterAreaModel modelClass that adds the Magnolia badge, if required.
Is rendered by the footer.ftl area script accessible in Templates > /templating-kit/pages/global.

In the stkHome template in Template Definition > /stkHome the /areas/footer/editable property is set to true making the components editable only on the home page.

The footer.ftl script:

Wraps the footer content in <div id="site-info">.
Nests the footer component content in <div-id="site-info=box">.
Renders the components in the /availableComponents node using the [#List] directive.
Renders the copyright field content using the content.<field name> notation.

<div id="site-info">
    <div id="site-info-box">
        [#list components as component ]
            [@cms.component content=component /]
        [/#list]
        [#if cmsfn.editMode]
            <div cms:add="box"></div>
        [/#if]
        [#if content.copyright?has_content]
            <p id="copyright">© ${content.copyright}</p>
        [#else]
            <p id="copyright"> </p>
        [/#if]
        ${model.badge}
    </div><!-- end site-info-box -->
</div><!-- end site-info -->

In the JCR, the copyright content is stored at an area level and the components at a component level. You can verify this in Tools > JCR Browser (Website).

Page tree

STK areas

htmlHeader area

CSS and JavaScript

Legacy browser support

Logo image link

branding area

logo area

search area

metaNavigation area

sectionHeader area

stage area

platform area

main area

Configuring the main area

Floating in the main area

breadcrumb area

contentNavigation area

intro area

infoBlock area

opener area

content area

comments area

extras area

module area

extras1 and extras2 areas

Configuration options

Vertical navigation disabled

Vertical navigation enabled

Make components available

promos area

base area

footer area