Magnolia 5.7 reached extended end of life on May 31, 2022. Support for this branch is limited, see End-of-life policy. Please note that to cover the extra maintenance effort, this EEoL period is a paid extension in the life of the branch. Customers who opt for the extended maintenance will need a new license key to run future versions of Magnolia 5.7. If you have any questions or to subscribe to the extended maintenance, please get in touch with your local contact at Magnolia.
Action
Action bar
Action popup
Activation
See publishing.
AdminCentral
AdminCentral is the back office interface for interacting with Magnolia and configuring all its functionality.
Alert
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. See: Message types
App
App controller
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.
App descriptor
pages
since a Pages app already exists.App group
App launcher
App framework
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
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.
Banner
Banners are messages that inform the user about system and app events. Banners are displayed prominently at the top or bottom of the Magnolia shell. They capture the user's attention effectively but do not interrupt what the user is currently working on. Banners are the only persistent message type. The user can safely close the banner and read the full message in the Pulse later. See: Message types
Browser subapp
Classpath
/WEB-INF/lib
and any classes and resources in /WEB-INF/classes
.Cockpit
Content
- Editor-created content such as web pages, images, documents, which are stored in the Magnolia JCR repository workspaces such as
website
,dam
,contacts
, and so on. Administrator-created configuration content such as module and server configuration data, users, groups and roles, which are stored in the
config
,users
,usergroups
anduserroles
workspaces.
Content app
Command
Commands are custom actions executed at pre-defined trigger points. Magnolia uses commands to activate 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.
Dashboard
The dashboard is a component in the Pulse that displays messages such as workitems, problems and information. In the dashboard you get a summary of things you may need to act on.
DAM
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.
Detail subapp
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.
Dialog
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.
Environment
The default Magnolia environments in the cloud are:
- Live environment: delivers an approved version of the site to customers.
- UAT (User Acceptance Testing) environment: allows developers to make the next version of the site available to editors and managers for testing and review.
- Integration environment: helps developers to try out ideas and solutions with Magnolia.
Favorites
In the Favorites app you can add shortcuts to apps, often used actions and other locations. The Favorites app runs under a 'what, with, where' mechanism:
- "What" is an action to run.
- "With" is an item serving as template or input to the action.
- "Where" is the location where the action occurs.
An example of a favorites action is creating a page (what), uploading assets (with) into specific folders or editing specific pages (where). Say you have a website that frequently requires product pages; you can create a favorite that creates a page based on a product template. The principle behind the Favorites is "two clicks": the first click opens Favorites and the second opens the shortcut.
Fragment
#
. 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.Fragments make it possible to bookmark favorite locations. For example, you can make a particular page in the site hierarchy a favorite.
Instance
There are two kinds of instance:
Author instance - Author instances are 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 one or more public instances.
Public instance - Public instances receive 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.
Read more about instances.
Magnolia CORE
Magnolia CORE is the foundation for the Magnolia CMS best-of-breed on-premises and cloud-based offerings.
Magnolia cloud
Message bundle
.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.
Node
According to the JCR specification (JSR-170):
A content repository consists of one or more workspaces, each of which contains a tree of items. An item is either a node or a property. Each node may have zero or more child nodes and zero or more child properties. There is a single root node per workspace, which has no parent. All other nodes have one parent. Properties have one parent (a node) and cannot have children; they are the leaves of the tree. All of the actual content in the repository is stored within the values of the properties.
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.
Notification
Notifications are non-intrusive messages that inform the user whether an action was completed or aborted successfully. Typically they confirm something. Notifications look like Post-IT notes. They go away automatically and don't require user action. Use notifications to confirm what the user did and provide them with confidence and assurance. See: Message types
Package
An example of this is a group of environments and their spaces used to build, test and deliver a corporate website.
Persona
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
- Age = 18
- Gender = female
- Location of visit = Japan
Personalization
Public instance
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
Also known as activation in the context of the older Activation and Transactional Activation modules, publishing refers to the process of publishing content from an author instance to public instances. Publishing (activation) can be subject to an approval workflow. For more details, see Publishing and activation.
Receiver
Public instances that receive some content are known as receivers (subscribers in the context of the the older Activation and Transactional Activation modules). The Community Edition supports a single receiver. In the Enterprise Edition, 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 and activation.
Release
Release version
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.REST
Rule
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:
- Birth date is 1956/08/24
- Year of birth is between 1999 and 2010
- Age is over 10 but less or equal to 20
- Interests include sports or international politics
- Interests includes photography and the user has a Flickr account
- Gender is set. (This is an example where the trait does not require a specific value but simply that any value is set.)
All visitors who meet a given rule belong to a segment.
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:
- Chinese moviegoers
- Age >= 18
- Interests include movies
- Location of visit = China
- Returning marketing managers
- Job title is "Marketing Manager" or "CMO"
- Type of visitor = returning
- Shutterbugs
- Interests include photography
- Flickr account = true
Segmentation
A segmentation is your entire audience described in segments.
Examples of segmentations:
- Biz/Tech
- Visitors with business interests (segment)
- Visitors with technology interests (segment)
- Others (fallback segment)
- Geographic (addresses, location, climate, region etc.)
- Demographic/socioeconomic (gender, age, income, occupation, education, household size, and stage in the family life cycle)
- Psychographic (similar attitudes, values, and lifestyles)
- Behavioral (occasions, degree of loyalty)
- Product-related (relationship to a product)
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.
Sender
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 the Enterprise Edition. See also Publishing and activation.
Shell
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.
Snapshot
Space
Examples of spaces are:
- The Live environment is typically split into two spaces:
- Author space: The authoring space is where editors work on content. It contains mainly the cloud-based Magnolia back-end.
- Public space: The live space is where content is being delivered. It contains a larger set of cloud-based Magnolia instances, load balancers, caches, etc.
- The UAT environment often contains two spaces (one public, one author, with one instance each) where new developments are tested and reviewed by managers and editors.
- The Integration environment consists of a single space. In this environment the separation between delivery and authoring is not important so a single space suffices.
Space setup
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:
- Since delivery is separated from authoring in a production environment and they are in different networks requiring different attention, they are defined as one space each.
- The live space setup of a high-traffic content product contains many public instances plus a load-balancer, and possibly advanced caches.
- The authoring space setup of a typical website product consists only of a single instance.
- The setup of a review and testing space may initially only consist of a single author instance, as this is sufficient to test all aspects of a new release. It may eventually contain one or two public instances eventually to test some specifics such as a new version of Public User Registration.
- The space dedicated to development and POCs is probably the least defined, since its setup depends largely on the requirements of the development work done.
Subapp
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.
Subscriber
See receiver.
Tag
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 analyses the information. If the service provides an analytics dashboard you can display it in the Marketing Tags app.
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.
Tools
The Tools group contains a number of core Magnolia 5 apps: JCR,View dependencies, Logging, Backup, Mail and Cache. The Tools group is where any apps developed by the community should reside. The tools groups has been developed especially to accommodate a wide range of apps. For information on developing apps, see the Apps section.
Trait
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:
- Date of visit
- Location of visit
- Language set in browser
- Interests
- Age
- Gender
A trait has implicit allowed values. For example, locations are typically countries, regions or cities.
Variant
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.
Workbench
Workbench an area in the ContentApp user interface that allows the user to work with content. The workbench is displayed on a tab and contains a data grid of content items. It also contains three buttons that allow you to view the data as a tree, list or grid and search box. The Action Bar also belongs to the Workbench. In the Pages app the Workbench displays a list of Web pages, in the Contacts app a list of contact persons and so on. The user can select items from the workbench and perform actions on them, such as open a page for editing.