How can I add a new language to my site?
Adding a language to a site involves defining a new locale in the configuration of your site. For further details, see Enabling multilanguage content.
How can I export content from one environment to another?
You can use the Backup module to create a backup of content and configuration, which you can then restore on the new instance.
In the context of Magnolia Cloud, you can copy content from one environment to another for testing purposes. See also Backing up and restoring in Magnolia Cloud.
How can I know if some content is served from the cache or not?
As a first step, you can check the Cache Tools app to see how many elements are in the cache. For a more detailed overview of cached objects, you can use the Cache Browser app.
For more details, see Cache Tools app and Cache Browser app.
How can I remove the site name from the URL (DX Core)?
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.
I cannot make a POST request to
delivery endpoints. Why?
delivery endpoints have been designed for tasks that need to obtain JCR data, so these endpoints only allow GET calls.
If you need to manipulate JCR nodes or perform duties within the system, use one of the following endpoints:
I need a group of users to access only some specific apps. How can I do that?
You can control access to apps by listing a user role under the
permissions node in the configuration of an app (see App permissions).
The permission to use an app can also be specified under the
permissions node in the app descriptor when developing the app. This allows you to provision the app to certain users in your organization. For further details, see Permissions and Groups.
I need a user/role/group to edit only a tree of pages. How can I prevent access to other pages?
Use the Access control lists tab of the Security app. In an access control list, you can specify the type of access for any node or subnode in any workspace.
For further details, see Roles and access control lists and Group and role strategies.
I would like to change an existing definition. How can I do that?
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.
For more information, see Resource Files app and Configuration app.
You can also change an existing definition by decorating it. For more details, see Definition decoration.
Is it possible to delete one workspace from the cache?
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.
What are version handlers, and when should I use one?
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
SamplesVersionHandler.java in the Templating Samples module.
AdmincentralModuleVersionHandler.java in the Admincentral module.
Module dependencies can be defined in an XML-based module descriptor as well as in a YAML-based descriptor.
For content bootstrapping strategies, see Bootstrapping strategy.
What can I decorate?
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.
What can I define in light modules?
You can define a number of items in light modules using YAML. See What items can be defined in a light module?
Why should I use a prototype?
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.
Why should I use image variations?
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.
Database sizing and setup
Which database modifications should I consider when publishing massive numbers of publication requests?
It is not recommended to publish enormous amounts of publication requests unless necessary. Nonetheless, if you must publish such amounts, particularly with PostgreSQL, please fine-tune your autovacuum operations as advised below.
Adjust autovacuum operations in line with the example recommended settings below to prevent considerable growth in a PostgreSQL instance in the publication context described above.
autovacuum_vacuum_cost_delay=10ms shared_buffers=4GB autovacuum_work_mem=2GB maintenance_work_mem=8GB autovacuum_max_workers=6 autovacuum_naptime=15s autovacuum_vacuum_threshold=25 autovacuum_vacuum_scale_factor=0.1 autovacuum_analyze_threshold=10 autovacuum_analyze_scale_factor=0.05 autovacuum_vacuum_cost_delay=10ms autovacuum_vacuum_cost_limit=1000
|You should adapt these settings to the resources available in your environment.|
What databases are supported?
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.|
What data volume does your application store?
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.
How many database tables are in the database?
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.
What sort of data does the database store?
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.
Does Magnolia store structured and/or unstructured data?
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.
How many database instances or servers do I need?
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.