Glossary

Action is an instruction to invoke an event in the user interface. You typically execute an action by clicking it in the action bar or in a dialog. For example, saving a dialog is an action. Most actions take place in the user interface only - they don’t interact with external logic. However, an action can do more complex things such as execute a command.

An action bar makes actions available to users. The action bar is typically displayed on the right-hand side of the browser subapp. The action bar definition organizes actions into sections (green label) and groups (between horizontal lines). Availability rules determine which section is displayed to the user. For example, when the user selects a content item in the browser subapp, availability rules display only actions that are relevant to working with that item. A group contains actions that have something in common, such as actions for adding things.

Action popup is a context menu that is displayed when the user right-clicks an item. You should only display often used actions in the popup so that it remains usable. If your app only has a few actions, you may want to simply extend the action bar. This way the popup displays the same actions as the action bar. Extending also allows you to manage the items in one place rather than two.

See Publishing.

AdminCentral is the back office interface for interacting with Magnolia and configuring all its functionality.

Alerts are modal messages that show up in the context the user is currently working in. You can use alerts to confirm that an action should be executed, inform the user of harmful consequences, or report the progress of a long-running action. Since alerts are modal they block the user interface.

A Magnolia app is a focused tool that lets editors work on one task at a time. An app can perform a task such as editing a page or manage content such as products. Create your own apps to do tasks that are important on your site.

The AppController interface manages the context in which an application runs. Context is an abstraction layer that represents the environment of the current process. It provides access to important components such as the current user.

An app descriptor describes an app. The descriptor assigns the app a name, icon and implementation class. The name of the app content node must be unique as it is used to refer to the app across the system. This means you cannot name your own app pages since a Pages app already exists.

An app group contains apps that have something in common, grouped together in the App launcher. For example, the Edit group contains the Pages, Assets and Contacts apps. Each app in the group covers specific duties in content management.

The App launcher is a key navigation page in Magnolia that you can access using the icon to the left of the Find Bar at the top of every page.

The app framework is a collection of classes that makes it possible to develop apps. The framework also controls app life cycle events such as starting and stopping the app and bringing the app into focus. The app framework also maintains a history of app use and remembers which app was used last.

Author instance is where editors work. This instance typically resides in a secure location behind a corporate firewall, inaccessible from the Internet. The author instance publishes content to a Public instance.

Browser subapp is a specialization of the basic subapp, provided by the content app framework. The browser subapp allows you to view and organize content items in tree, list and thumbnail views. The browser subapp descriptor is similar to the basic subapp descriptor, but the classes are different.

Classpath is a parameter that tells the Java Virtual Machine or the Java compiler where to look for user-defined classes and packages. The classpath of a Magnolia webapp includes any JAR files in /WEB-INF/lib and any classes and resources in /WEB-INF/classes.

The cockpit is the user interface to view and manage Magnolia cloud-based packages and provide actions to update the environments in them.

By content, we refer to both:

A Content app is a specialized app type for managing structured content. The content app user interface consists of a browser subapp and one or more detail subapps. Content apps make it easy to enter items such as products or events. Many native Magnolia apps such as Tours and Contacts are content apps. Because this app style is used often, the framework provides convenience classes to make building a content app faster.

Commands are custom actions executed at pre-defined trigger points. Magnolia uses commands to publish content, send email, flush the cache, take backups, import and export data, and to do many other tasks. Commands can perform duties within the system or connect to external resources.

Digital asset management (DAM) is a common term for Magnolia modules that allow you to store and work with images, videos and documents. Assets stored in the DAM can be used anywhere in the system.

Part of a subapp that typically displays a form for editing items. The detail subapp is always a secondary tab to the browser subapp. You can use multiple detail subapps at the same time, editing different items.

Dialogs are used to edit content and properties. Dialogs typically contain a form. Authors type content into the form fields and the dialog stores the content in the repository.

A cloud-based package is made up of three default environments. An environment consists of one or several spaces.

The default Magnolia environments in the cloud are:

Fragment is the part of the URL that starts with the hash character #. In AdminCentral URLs, the fragment keeps track of an app’s internal state. It identifies the name of the app, the subapp that is open, and optionally a path to the content that is operated on. In public URLs the fragment identifies an anchor.

Instances exist in a space. An instance is a Java webapp running in a servlet container.

There are two kinds of instance:

Read more about instances.

Magnolia DX CORE is the foundation for the Magnolia CMS best-of-breed offerings.

Magnolia Cloud is a cloud-based platform-as-a-service offering built on top of Magnolia CORE. Magnolia provides customers with the complete infrastructure in the cloud (e.g. network, load balancer, servlet container, database, etc.). It is set up following best practices and includes a cockpit for managing upgrades, user testing and releases. A cloud-based deployment of Magnolia provides many benefits, including fast time-to-market for your digital experiences, freedom from IT bottlenecks and low capital expenditure. Additional benefits include guaranteed uptime and fast, easy customization using light development methods.

A message bundle (resource bundle in Java) is a collection of .properties files. Each file contains key-value pairs of translated user interface text such as labels and messages. The keys in all files of the same bundle are identical but the values are language-specific translations.

A message bundle must contain at least one .properties file. The files are named after the language (locale): <bundle-name>_<locale>.properties, for example, app-pages-messages_en.properties. Every Magnolia module should provide its own message bundle. If a module installs several apps, each app should have its own message bundle.

According to the JCR specification:

Magnolia provides its own custom node types which represent Web content management items such as pages and components. You can see nodes and properties in many apps. For example, the Configuration app renders nodes to users in the following way:

You can configure the icon for a node type in the workbench of your app. For example, the Pages app displays a page icon for an mgnl:page node. You can check which node type an app displays and the icon associated with in the workbench definition of that app.

Notifications are banner-type messages that inform the user about system and app events. Notifications are displayed prominently at the top of the Magnolia UI. They capture the user’s attention effectively but do not interrupt what the user is currently working on. Notifications are the only persistent message type. The user can safely close the notification banner and read the full message in the Notifications app later.

A package is a group of cloud-based environments which belong together.

An example of this is a group of environments and their spaces used to build, test and deliver a corporate website.

Persona is a hypothetical visitor who represents your target audience. A realistic persona typically belongs into more than one segment.

For example, a persona can be interested in both music and technology. To create a persona, pick one or more traits and assign specific values to them.

Example: Yuu Sato

Personalization refers to adapting content to a particular user according to his or her personal preferences, needs and capabilities. In order to do so, you first select a set of traits of a visitor or a visit, then compose rules using these traits to define what content is presented to which visitors and when.

Pop-ups are non-intrusive messages that inform the user whether an action was completed or aborted successfully. Typically they confirm something. Pop-ups look like Post-IT notes. They go away automatically and don’t require user action. Use pop-ups to confirm what the user did and provide them with confidence and assurance.

A profile is a folder under /WEB-INF/config/ containing Magnolia property files. From Magnolia 6.2.2, you can use MAGNOLIA_PROFILE to configure a profile as an environment variable or system property.

See Configuration management: Properties and Creating and deploying custom cloud bundles for more information.

Public instance receives content from an author instance and serves it to visitors on the Web. No authoring occurs here. This instance resides in a publicly reachable location. You can have more than one public instance serving the same or different content. In a typical deployment you have at least two public instances.

Publishing refers to the process of publishing content from an author instance to public instances. Publishing can be subject to an approval workflow. For more details, see Publishing overview.

Public instances that receive some content are known as receivers. The Community Edition supports a single receiver. In DX Core, theoretically any number of receivers can receive content from a single author instance (sender), but because of performance, it is recommended to have fewer than 10 public instances for parallel publishing. For more details, see Publishing overview.

A release is created based on the latest snapshot. When you Creating a release, you give the release a name and a description. You Promoting a release to UAT in the Integration environment and then in the UAT and Live environments.

The Magnolia cockpit system automatically assigns a version to every release created. The version has the pattern v<index>, where the index is a number starting with 1. The index is incremented with every new version resulting in v1, v2, v3, and so on.

Magnolia’s REST Web service allows you to manipulate content through a Web API. You can create, read, update and delete nodes in the JCR. The nodes can be pages, components, contacts or anything else that is stored in a named workspace. You can also execute commands to publish, export and import content.

When you define permitted values for one or more traits you get a personalization rule. For example, Age >= 18. When a visitor is 20 years old, the rule is met and personalized content is delivered.

Examples of rules:

All visitors who meet a given rule belong to a segment.

A segment is all the visitors who meet a given rule. Create a segment when you know your audience and you want to routinely target content to them.

Examples of segments and their rules:

A segmentation is your entire audience described in segments.

Examples of segmentations:

Visitors who are not in your intended target audience belong to a fallback segment, typically named Others. Segments in a single segmentation should not overlap.

A counterpart of receiver, sender is a component responsible for publishing content to the public instance(s). It is usually asociated with the author instance of Magnolia, which can publish content to a single public instance in the Community Edition, or to several public instances in DX Core. See also Publishing overview.

The Magnolia Shell is the visual layer of Magnolia and encompasses all of the user interface that you see when you log into the system: the green background, the Magnolia logo and the app icons. The Shell is the UI administration interface. All apps reside in and are launched from the Shell. An app will continue to run in the Shell even when you have exited the app. From a functional viewpoint the Shell is a container that provides basic services for apps. It allows you to launch apps and display dialogs.

In addition, the Shell is what enables the smooth transition from using one app to another and is responsible for visual effects when you switch between apps. For example, when you go back to the Apps screen to launch another app, the app were just running fades into the background. This transparency is called the app stack and provides a visual indicator that the app is still running.

The Shell is responsible for sending messages to the Pulse. A developer does not need to know which exact Shell method to invoke in order to send such a message; in the app code is is sufficient to create a reference to an AppContext object instead. This object provides shortcuts for sending messages, displaying confirmation dialogs and many other everyday things. It is more straightforward to interact with the AppContext object than with the Shell itself.

A snapshot is created based on development changes pushed to the cloud-based Magnolia Git repository. You create a snapshot to transfer and apply these changes to the Integration environment. You can then wrap one or more snapshots into a release.

A space exists in an environment and groups together related functionality needed to build or deliver a site. Which systems a space actually contains and how they are connected is defined by the space’s setup. A space is a container for one or more instances of Magnolia.

Examples of spaces are:

A space setup defines how a space is technically set up with Magnolia.

It contains one or several Magnolia instances of the same or different type, in addition to other systems required to fulfil the purpose of the space.

Examples of space setups are:

Apps are divided into subapps. Each subapp specializes to do one task. For example, in the Pages app a browser subapp displays the hierarchy and a detail subapp allows you to edit a single page.

Older term for receiver.

Marketing tags are snippets of code that you insert on Web pages. Tags typically collect analytics information such as how many visitors view the page and how long they stay. Tags can also integrate third-party content such as social media on your site or insert ad campaigns. You can use tags to learn more about visitors or provide content.

A tag is typically a piece of JavaScript code. When a page loads, the JavaScript code runs and collects usage information about the page and the visitor. The tag then reports this information to the service that provided the tag. The service stores and analyzes the information.

Since many of these tags require cookies to work, you can also link tags to cookies defined in the Cookies app. By linking tags to cookies, you can make sure the tags used on your website comply with data privacy rules.

A trait is an attribute or property of a visitor or visit, such as age or gender, that you can use to personalize content.

Examples of traits:

A trait has implicit allowed values. For example, locations are typically countries, regions or cities.

$type is a configuration property which allows developers to use easy-to-remember shortcuts for definition classes in YAML definitions instead of fully classified Java class names. See Type aliases for more details.

A variant is an alternative content element that replaces the original element in personalized content delivery. Magnolia serves the variant instead of the original element when personalization rules match. A variant is a copy of the original element, edited to best suit the intended audience.

A webhook is a user-defined callback, triggered by some event (content change or a code push to a repository), which makes a REST call to an external API, usually a build pipeline. The build system then creates a new build that incorporates the changed content.

For more information about webhooks in Magnolia, see the Webhooks feature page.

Workbench is a view that displays content items in a workspace. It’s part of the content app framework, typically defined in the browser subapp.

The workbench contains a list of content views. Common view types are tree, list, and thumbnail. By default, JCR content apps use the tree view type.

The workbench also provides a default search box.