Content Management System
Contents
The pinnacle of Enonic XP is the Content Management API and related tools
Introduction
Use of XP’s CMS capabilities is fully optional. The full range of CMS capabilities are made available through individual, but tightly coupled APIs, services and applications:
-
Content API - Included in the XP core, built on top of the NoSQL Storage
-
Site Engine - Included in the XP core, built on top of the Javascript Framework og web app Engine.
-
Content Studio - Authoring interface available on Enonic Market.
-
Headless GraphQL API - Available as both application and library.
Content Types
The Enonic CMS is content centric, rather than "page" centric. This means that any content produced will have a specific content type, such as "article", "person" or "product". Things like "shortcut", "file", "folder", "site" and even "landing page" are also perfectly valid content types.
Content types essentially define a specific set of fields that define the content. For person, this might be "firstname", "lastname" and "birthdate", while a landing page might to fine with just a "name" field.
Actually, all content types share a standard field named "Display Name", which can be considered the items title. Additionally, a range of meta data fields are available, such as language, permissions, modifiedBy, createdDate and more.
Content types are defined through the Schema system, which enables creation of rich and complex forms as required.
Schema system
A basic concept used throughout the CMS is called schemas. Schemas enable developers to easily define various types of forms used throughout the CMS.
The schema system provides a 1:1 mapping between schema fields and corresponding document properties. For instance, a text input called "title", is mapped to a property called "title" in the underlying document structure.
The schema system provides a range of standard Input types, such as TextLine and ContentSelector. It also offers advanced form components such as ItemSets and OptionSets for creating nested sets of data and optional sets of data.
Pages
Enonic XP is often used as a traditional Web CMS, where editors compose rich landing pages.
Any content item may be configured with a "presentation" - or more precisely, a page.
Pages are composed form a structure of components
-
Page - The customizable root component of a page
-
Regions - drop zone(s) within a page where other components may be placed
-
Layouts - customizable components with region(s) of their own
-
Parts - customizable component
-
Text - Standard free text component
-
Image - Standard component for images
-
Fragment - Special reusable component
Pages, layouts and parts are all fully customizable through custom controllers and corresponding schemas. Get all the details in the pages section
Component availability depends on the application that have been added to your site.
Content indexing
All user defined properties are automatically indexed and available for queries.
In addition, the following standard properties are available for search:
- _alltext
-
A collection of all fulltext-analyzed fields (textLine, textArea, htmlArea) in a content in one property
- _id
-
Holds the id of the content, typically generated automatically in the form of a UUID.
- _manualordervalue
-
The order value used when child-content is ordered manually
- _name
-
Holds the name of the content
- _parentPath
-
Reference to parent content path.
- _path
-
The content path
- _permissions_read
-
The principals that have read access.
- _permissions_create
-
The principals that have create access.
- _permissions_delete
-
The principals that have delete access.
- _permissions_modify
-
The principals that have modify access.
- _permissions_publish
-
The principals that have publish access.
- _permissions_readpermissions
-
The principals that have access to read the content permissions.
- _permissions_writepermissions
-
The principals that have access to change the content permissions.
- _references
-
Outgoing references to other content.
- _score
-
Calculated relevance for a hit
- _state
-
Used for keeping state of a content in a branch.
- _timestamp
-
The last change to the content version.
- _versionKey
-
The id of the node version.
- attachment.size
-
If any attachments, contains an array of attachment sizes
- attachment.label
-
If any attachments, contains an array of attachment labels
- attachment.mimetype
-
If any attachments, contains an array of attachment mime-types
- attachment.name
-
If any attachments, contains an array of attachment name
- attachment.binary
-
If any attachments, contains an array of attachment file-name
- attachment.text
-
If any attachments, contains the extracted text of e.g pdf-files
- creator
-
The user principal that created the content.
- createdTime
-
The timestamp when the content was created.
- data
-
A property-set containing all user defined properties defined in the content-type.
- displayName
-
Name used for display purposes.
- language
-
The locale-property of the content.
- modifiedTime
-
Last time the content was modified.
- owner
-
The user principal that owns the content.
- page
-
The page property contains page-specific properties, like template and regions.
component.text.text This property contains all values in the text-components added to pages
- publish.from
-
The time when the content was first published. This timestamp will be the set both in draft and master branch.
- type
-
The content-type name
- x
-
A property-set containing properties from x-data (this also includes mixins).
Page templates
For some content types, like "article", you might want to re-use the same "presentation" used over and over again. For this specific purpose, we have the content type Page template. By creating a page template for "article", and setting up its page, this page will automatically be used for presenting all articles within your site.
Fragments
From time to time, you might want to reuse a component you placed on page, for multiple pages. Fragments to the rescue! By converting a component to a fragment, the fragment is made available as a separate content item, using the content type fragment ofcourse. Fragments can then be placed on other pages (including page templates), just like any other component. The fragment may now be edited from a single location, and will instantly be updated in all locations where it is placed.
Fragments also enable creative features like limiting access to view or edit a particular part of the page.
Sites
Site is a system defined standard content type. What makes sites special is the ability to add applications to them. Multiple applications may be added to a single site, where each application contains desired functionality.
Typically, sites will have a main application that controls most content types and page components if any. Additional applications like Google Analytics, and SEO tools are typically installed to extend the functionality without custom development.
X-Data
It is often useful to be able to share a set of fields across different content types. Xtra data, or X-data for short was designed specifically for this purpose.
By defining x-data schemas, developers may dynamically inject these extra fields to all, or a specified list of content types. For instance, the SEO Meta fields application makes use of this, so editors may fine-tune SEO settings across all different content they produce.
In Content Studio, X-data is visualized as a separate step in the publishing form.
Site Engine
The Site engine extends the capabilities of the Javascript Framework. The site engine serves requests from:
//myserver:8080/site/<repo-name>/<branch-name>/<content-path>
Content driven
When compared to the Web engine, the main difference is that sites are content driven, rather than code driven.
This is best understood by looking at the initial URL pattern. The Web engine requires the name of the app that will handle the request, where the site engine specifies a repo, branch and path to content as its entry point.
Site apps
To understand the Site engine, it is crucial to understand the concept of sites. The system defined content type Site has a special purpose in relation to the Site engine. This is due to the fact that "site applications" can be added to, and configured specifically for that site.
As a site may contain multiple applications, As multiple applications may be involved in the processing of a single request, the main purpose of the Site engine is to coordinate when, and how each application is executed.
Image Service
Enonic XP contains an Image Service that can scale, process and deliver rasterized RGB/RGBa image media in real-time.
Headless and Hybrid CMS
API-access to content (Headless CMS) combined with web pages commonly referred to as Hybrid CMS.
The content oriented approach makes XP ideal for serving content via API (so-called Headless CMS). It also enables developers to instantly make use of the powerful search capabilities provided by the underlying NoSQL storage.