FAQ

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.

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.

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.

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 my-domain.com/my-site-one.

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.

The 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: nodes, properties or commands.

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.

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.

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.

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.

If you need to exclude content of a workspace from being cached, register the name of that workspace under the /modules/cache/config/contentCaching/defaultPageCache/flushPolicy/policies/flushAll/excludedWorkspaces node. 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.

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:

For more information, see Image variations.

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.

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.

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:

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:

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.

Magnolia itself is decoupled from the database via Jackrabbit. At a minimum, the database user needs to be able to run a script located in the Jackrabbit core module (info.magnolia.jackrabbit).

Jackrabbit needs to be able to create tables, alter them, and perform the usual operations on the data they contain. So, permissions to execute the datawriter and datareader operations are needed, as well as ddladmin (for table creation), accessadmin, and securityadmin (for schemas creation).