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. [1]
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.
Both editions have full i18n support. The addition of the i18n
node in the EE configuration relates to multisite i18n support.
The /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 > /pages
are made available to the default site:id
property 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 default
site definition the templates are automatically available to all other sites, for example demo-project
, because they extend the default
definition.role
. Add a role
content 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.getName()
with template.getId()
. Since Magnolia 4.5.9, the id
property is exposed to
TemplateConfig
. Prior to 4.5.9 the name of the template node was exposed instead.
Template availability, in the sense that not all templates are available at all page levels, is also controlled by the category assigned to the individual templates in the concrete template definitions. For more information on the site hierarchy see Categories and subcategories.
The /theme
node assigns the default pop
theme to the site definition using the name
property. A theme defines a site's look and feel, as well as its JavaScript functionality. Themes are configured in Templating Kit > Themes. A variation can use its own theme. 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.
The /variations
node contains the configurations for all variations of the site. For each variation you can:
pop
theme.The 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 > /server/i18n
.
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:
/defaultLocale
sets the language rendered by default./fallbackLocale
sets the language used in the absence of translated content./class
is set to DefaultI18nContentSupport, the same Java class used by the CE./locales
contains 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.
For more information see i18n and l10n and Multilanguage structure.
Footnotes