Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.
Pages consist of areas which can consist of further areas or components. Areas have two purposes: they structure the page and control what components editors can place inside the area. This makes area the most powerful template type. It ensures consistency across the site. Areas also provide repeatability. An area template typically loops through the components inside it, rendering the components one by one.
Most areas are rendered with containing div elements in the generated HTML so that you can control their layout on the page with CSS. An area has a toolbar which displays the name of the area. Areas also have an end marker, a narrow green bar at the bottom. The toolbar and the end marker indicate the dimensions of the area. Inside the area are its components or, if no components have been added yet, a gray placeholder.
This diagram shows where some of the areas defined in the areas in the STK.are on the page. Learn more about
An area definition enables the area, defines what template script is used to render it, and what components are allowed inside it. Area definitions are very similar to page definitions. You could say that area = template + component availability + inheritance.
You can define areas in the following places:
Areas have the following common properties. In addition, each area can provide its own custom properties. The area model class can process the custom properties to change how the area behaves or how it is rendered. For example, the
intro area has several custom properties such as
showAuthorDate which define whether these metadata fields should be rendered inside the area.
Type of the area. Defines whether editors can add components inside the area and how many.
Optional. Path to an area script. The script is used to render the area. Areas render any components inside them automatically, without a script. You only need a script if you want to render something in addition to the components.
Optional, need only if
Optional. Dialog used to edit area properties and content.
A map of components that are allowed in the area. This node controls what editors can place inside the area.
Makes the area editable when set to
Enables and disables the area. Defines whether the area is available on the site.
Area configuration class. The class instantiates the area object through the Content2Bean mechanism.
Fully qualified class name.
|Maximum number of components an editor can add to the area.||Number.|
Area model class which contains business logic.
Fully qualified class name.
Name of the area. Identifies the area so the page can call it to be rendered. If you don't provide this property, the area node's name is used as a fallback.
A title displayed in the edit bar.
A literal string or a key in a message bundle. The default is the name of the area's content node with the first letter capitalized.
Makes the area optional. Adds a delete button in the area toolbar that editors can use to remove the area from the page.
Allows components to shift to the right into a two-column layout.
Creates content inside the area automatically without editor involvement. Anything defined inside the child node
In the skeleton below, mandatory properties are red and optional properties are black.
4.5.10+ By default, empty areas are rendered in the page HTML. For example, a link list area that doesn't have any link components inside it is still rendered as an empty
<div> element. Typically empty areas are not visible to the user although they are present in the HTML.
This rendering behavior is configurable. You can disable the rendering of empty areas if it causes issues for layout or design. For example, you may have an area that is visible even when empty. Having an empty box on the page may not be what you want.
renderEmptyAreas property to the Configuration >
/server/rendering/engine node and set the value to
false to turn off the rendering of empty areas. Default value is