Site definition

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:

• Site definition
• Template prototype

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.

Templates

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:
• Each template is assigned in it's own content node that matches that of the template definition. The value of the 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.
• It is also possible to restrict template access by 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.

Themes

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.

Variations

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:

• Modify the template prototype.
• Make different templates available to editors.
• Assign a theme that is different to the default pop theme.

The smartphone variation is discussed in detail on the Mobile page.

i18n

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 

1. There is a third prototype, the static HTML prototype, which serves two purposes: handing it out to designers who can do their work without needing a running Magnolia instance and other project stakeholders as a showcase of page types and page components that are available.