Adding a language to a site involves defining a new locale in the configuration of your site. For further details, see Enabling multilanguage content.
You can use the Backup module to create a backup of content and configuration, which you can then restore on the new instance. See also How to replicate a public instance on the Magnolia Community Wiki.
Let’s say your site name is
my-site-one and you want to access it via your own domain name
my-domain.com. You probably do not want to have the site name in the URL like
To avoid this, disable the
uri-starts-with-sitename rule on the public instance in the definition of your site. For further details, see Managing cross-site access.
You can control access to apps by listing a user role under the
permissions node in the configuration of an app (see App permissions).
To change an existing definition, use the Definitions app to find and highlight the definition. In the action bar, you will see Show in Resources app or Show in Configuration app depending on the definition type. Click the action and edit the definition in the target location.
In the Resource Files app, you can fix the definition in the app or edit it on the file system.
In the Configuration app, you can edit the definition in the JCR.
You can also change an existing definition by decorating it. For more details, see Definition decoration.
If you need to exclude content of a workspace from being cached, register the name of that workspace under the
By default, a workspace cache is flushed whenever some new or modified content is detected in it.
For further details, see Flush policy.
A version handler is a Java class used to update the JCR during a module upgrade. It should be used to change any configuration that may have been bootstrapped during the initial installation or previous upgrade.
The related interface is
info.magnolia.module.ModuleVersionHandler, which contains a series of tasks (deltas) executed during installation or during specific updates.
If your module needs to handle its own installation and updates you should provide an implementation of this interface.
- Implementation examples
It is possible to decorate definitions such as app descriptors, dialogs, field types, media editors, message views, renderers and templates. Any definition bound to the registry can be decorated. You can see registered items in the Definitions app.
Decorated definitions can originate from any source, including the JCR, YAML files or even executable code like Blossom. However, you can only define decorators as well as decorate existing definitions via YAML.
For more details, see Definition decoration.
You can define a number of items in light modules using YAML. See What items can be defined in a light module?
A prototype is an optional templating mechanism that offers a number of benefits. It ensures uniformity across templates, prevents repeating and duplicating configurations and creates similar templates quickly.
If you have a small number of templates that are very different from each other, using a prototype is probably not necessary. Creating a template prototype makes more sense for a very high number of templates that reuse a configuration. With a template prototype, the template configuration is more efficient as you only need to apply a configuration change once in the template prototype.
For more details, see Template prototype.
Variations are an effective alternative to resizing images with CSS. The main benefits of using image variations are:
Image size is reduced, and less data is transferred.
Editors can upload images of any size, which will automatically be resized to fit the template.
Image size is uniform throughout the site.
For more information, see Image variations.