Content Management System
Content Management System
Unlike most applications platforms, Enonic XP ships with an embedded hybrid CMS.
Use of the CMS capabilities is fully optional. The full range of CMS capabilities are made available through three individual, but tightly coupled services:
Content API - Included in the XP core, built on top of the NoSQL Storage
Content Studio - Authoring interface available on Enonic Market.
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.
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 cms/schemas.html, 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.
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 re-usable component
Pages, layouts and parts are all fully customizable through custom controllers and corresponding schemas. Get all the details in the components section
Available components depends on the application that have been added to your Sites.
All user defined properties are automatically indexed and available for queries.
In addition, the following standard properties are available for search:
A collection of all fulltext-analyzed fields (textLine, textArea, htmlArea) in a content in one property
Holds the id of the content, typically generated automatically in the form of a UUID.
The order value used when child-content is ordered manually
Holds the name of the content
Reference to parent content path.
The content path
The principals that have read access.
The principals that have create access.
The principals that have delete access.
The principals that have modify access.
The principals that have publish access.
The principals that have access to read the content permissions.
The principals that have access to change the content permissions.
Outgoing references to other content.
Calculated relevance for a hit
Used for keeping state of a content in a branch.
The last change to the content version.
The id of the node version.
If any attachments, contains an array of attachment sizes
If any attachments, contains an array of attachment labels
If any attachments, contains an array of attachment mime-types
If any attachments, contains an array of attachment name
If any attachments, contains an array of attachment file-name
If any attachments, contains the extracted text of e.g pdf-files
The user principal that created the content.
The timestamp when the content was created.
A property-set containing all user defined properties defined in the content-type.
Name used for display purposes.
The locale-property of the content.
Last time the content was modified.
The user principal that owns the content.
The page property contains page-specific properties, like template and regions.
TODO: Update component.text.text This property contains all values in the text-components added to pages
The time when the content was first published. This timestamp will be the set both in draft and master branch.
The content-type name
A property-set containing properties from x-data (this also includes mixins).
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.
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.
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.
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.
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.
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.
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.