Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.
Everything in the STK starts with a prototype. Individual sites configurations in the Enterprise Edition and concrete page templates in both editions rely on and are modifications of a prototype. There are two prototype configurations:
The prototype configurations are possibly the most important in the STK. They are the hub of many other configurations; the glue that holds everything together and makes it fall into the right place. 
The logic behind the use of prototypes is efficiency. Other configurations extend the prototypes. This means they inherit configuration from the prototype and define only exceptions. Without prototypes it would be necessary to configure the same thing over and over again.
As a general rule, prototype configurations include settings that are likely to be used. This reduces the size and complexity of configurations that extend the prototypes. Most prototype configurations can be changed by reversing the default configuration.
The site definition includes the default templates, theme and varitations. The only difference between the enterprise and community editions is the multisite feature which is available only to enterprise edition users.
Community Edition supports one site. You can find the configuration in Templating Kit > Site Configuration.
Enterprise Edition supports many sites. You can find the
default site definition in Templating Kit > Site Definitions.
/templates node contains two configurations:
/prototype: The template prototype configuration discussed in the next section.
/availability. This content node determines what templates authors can use on content pages. The concrete page templates configured in Template Definitions >
/pagesare made available to the default site:
idproperty has a
<module>:<path to definition>structure. This makes it possible to include templates configured in any module, not only the STK. In the EE, because this configuration is in the
defaultsite definition the templates are automatically available to all other sites, for example
demo-project, because they extend the
role. Add a
rolecontent node under the
<template name>node with a single property with the same name and value as the role set up in Security > Roles. For more information see Roles.
4.5.9+ If you have a custom template availability class, replace occurences of
template.getId(). Since Magnolia 4.5.9, the
id property is exposed to
. Prior to 4.5.9 the name of the template node was exposed instead.
/theme node assigns the default
pop theme to the site definition using the
pop is the default theme used by all sites unless another is assigned in an EE site definition or in in a variation.
As the name suggests, a
variation is a varied form of the prototype. In the demo sites it is used to reformat content suitable for output on a smartphone, but is not limited to this. You can for example configure variations for tablet, web-TV, PDF formats, or specific output for groups of logged in users. See Channels for more information.
/variations node contains the configurations for all variations of the site. For each variation you can:
smartphone variation is discussed in detail on the Mobile page.
Magnolia offers internationalization support on three levels: content, system and authoring. You can view the
i18n configurations in Configuration >
In the EE the
content server configuration relies on the ETKI18nContentSupport Java class that provides additional i18n support for multiple sites. This class delegates to the i18n support configured in a site definition.
In Templating Kit > Site Definitions the
/default/i18n node defines the fall-back internationalization settings for the default site definition. Other site definitions can modify these settings allowing specific sites to have different settings. Within the
/i18n node the following are set:
/defaultLocalesets the language rendered by default.
/fallbackLocalesets the language used in the absence of translated content.
/classis set to DefaultI18nContentSupport, the same Java class used by the CE.
/localescontains the configurations of as many individual languages as necessary.
Throughout the system languages are indicated by a two letter identifier,
en (English) and
de (German) in the example here.
In the CE, content authoring is configured in Configuration >
/server/i18n/content. This configuration sets the
/fallbackLocale and individual language
locales in the same way as the EE. DefaultI18nContentSupport is the same Java class used by the EE in the site configuration. The
defaultLocale property is unnecessary as multiple sites are not possible. By default the
enabled property is set to
false and should be changed to
true to enable multilingual content entry in the editing interface.
Other than those indicated above, i18n server configurations are the same in both editions.
In the editing interface editors can select the relevant language for content editing in a dropdown in the top bar. Language indicators are also included in all dialogs next to the field label.