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.
You are free to choose any database officially supported by the Apache Jackrabbit and any operating system supported by those databases. All major databases are supported at the moment. We recommend the PostgreSQL open source database.
|See also the list of databases we certify.|
The volume of data required to run Magnolia is negligible, typically below 10 MB. The main driver of the total data volume is the customer who decides what content to store in Magnolia and in how many versions to store the content.
A reasonable operational size should be:
Double the amount of the data the customer has if the content is versioned.
Less than that if the content is not versioned.
More than that if there is a lot of content which is versioned frequently.
There are four tables and three indexes created for every JCR workspace. The total number of workspaces depends on the modules the customer decides to use and the number of content types created. One content type means one workspace. The default Magnolia bundle comes with approximately 20 workspaces, hence there are around 80 database tables in total.
This is configurable. By default, the database will only store text-based data up to the size of one kilobyte. However, this limit can be increased.
The datastore (the binaries) can be configured to be stored in the database as well. While this increases the load on the database, it will greatly simplify backup and restore strategies and, therefore, this is the recommended setup. With all the data in the database, there will be an additional table per workspace, hence not four but five tables per content type.
The data stored is structured. However, it is not directly open for manipulation at the database level. The data is optimized for storage through a hierarchical-to-relational data mapping to make it perform the best at:
Runtime, as hierarchical data.
Storage time, in a relational database storage.
You can run all of your instances against a single database instance and just use different table spaces or prefixes for tables used by different workspaces.
However, to improve disaster tolerance, we recommend running fully redundant configurations, where each Magnolia instance is backed by an independent database instance.
All of the above is configurable. Hybrid setups can also be created and used. In a hybrid setup, some Magnolia instances are sharing a single database while others are backed by their own database instances.