Skip to main content

Concepts

Property​

A property represents a project/website. The Discovery CMS allows you to manage multiple properties, which can correspond to as many websites.

The property defines some properties such as:

  • URL of the production, test, development, etc. environments.
  • site languages ​​(e.g. English, Italian)
  • access token to the various environments
  • users authorized to work on the property

Page​

A page represents a page of the website. A page has a URL that can be entered into the browser and displayed.

There are two page categories:

  • complete pages: the classic example are landing pages, about pages, contact pages. These pages are autonomous, they have a unique URL.
  • template pages: these are pages that serve to represent a single piece of content. An example is a product detail page or a page with an article on a news site: these pages always need content (e.g. product code or article slug).

The pages are logically divided into components (components ), to simplify editing.

Components​

The components are the "bricks" with which the page is built. In our model the bricks are macro components: the editor is not provided with individual buttons, labels, and other basic elements to build the page, as this excessive granularity would significantly complicate the construction of the page. Rather, a team of specialists builds the macro components, respecting UI/UX rules, and the editor is given the possibility to:

  • insert/move/remove components
  • modify elements in components without bypassing style rules.

For example, the property "Reply.com" can contain a content "Home Page" which in turn is made up of several components:

  • Headers
  • Call To Action
  • Campaign
  • Testimonials
  • Footer

Each component can have fields, such as headline, call to action text, color of the button, link to which a button points, etc. If the property is multilingual, some of these fields may be multilingual.

The components correspond to as many components in the frontend technology (e.g. ReactJS). A component always belongs to a page and cannot be created outside the context of a page.

Contents​

contents are top level objects, which can be composed of one or more fields. A classic example of content is a news article, a post or a product sheet with related images.

Content can only be viewed within a template page. Content can be seen as data, while the page can be seen as its presentation. In fact, when you think about content, you need to think only about its data, not its presentation. It will be the page's job to present it. Technically it is also possible to represent the same content (e.g. article) with two different pages, for example one optimized for smartphones and one for the web.

The contents can be of two types:

  • user defined
  • provided by Reply (in the project context)

Content provided by Reply may include more advanced customizations than user-defined content.

Type​

Type is used in this context as an abbreviation for Content Type. A type defines the structure, in terms of the fields (fields) that compose it, of a component or a content. A type can be created by the user, for example, to define the structure of his Article-type content. When defining a type, the fields of which it is composed are indicated, and for each field the type and characteristics are indicated. For example, for the Article type I can have as fields:

  • headline: string, multilanguage
  • topic: taxonomy "Topics", single value
  • images: link to DAM image
  • body: richtext with advanced editor
  • tags: taxonomy "Tags", multiple values

A type can be:

  • private: visible only within the property in which it is defined,
  • global: shared among all properties

Typically global types refer to corporate entities that you want to share. A typical example is the Product type: in a company that has a product catalog it is likely that there may be multiple properties that they have need to refer to products, so it makes sense to define the Product type as global.

Other types, however, can be very vertical for a specific property. In this case they must be defined as private, so as not to create too many dependencies between properties.

Publication​

Both contents and pages are published to the Content API, a cloud publishing layer decoupled from the CMS backend and natively exploiting AWS cloud services. The components are never published directly, but always through the publication of the pages to which they belong.

In order to provide a preview service of changes to publishers before end users see them, they are published two versions of the contents and pages:

  • preview: visible only to publishers
  • public: visible to everyone

For this reason, when a property is created, two tokens are generated which, once passed to the API, retrieve the version preview or the public version. Only publishers have access to the preview token, and therefore an external user will never be able to see it the contents and pages before they are finally published.

When the publisher edits a piece of content or a page in the CMS, it is automatically updated when it saves the preview version, and consequently updated the preview of the site or application. When the publisher is sure of the changes, they actually publish, creating or updating the public version, so that end users can see it.

For this reason, within the CMS there is a "Save" button, which updates the preview, and an area where you can manage the publication. For organizations with many users, users who can update preview pages and content may also be separated from the users who actually approve the publication to the end users of the site/application. All this can also be included in a workflow that involves multiple users, such as reviewers who can send pages back to publishers asking for changes.

Once the page is published, the state persists even if there are changes. If so, if any changes are made On the preview version, you need to use the "Republish" button to update the public version, publishing the changes as well outwards.

Conclusions​

These are the fundamental concepts to be clear when working with the Discovery CMS. Summing up:

  • property: represents a project
  • page: represents a web page or a template page (e.g. the page for viewing articles)
  • components: these are the basic bricks that make up a page, generally corresponding to ReactJS, VueJS, etc. components.
  • content: these are structured contents, such as products, articles, etc. These are the data that will then be displayed via the template pages.
  • type: defines the structure of a content (example: title, description, etc.)
  • publication: this is the phase in which the data is published to the API used by the frontend, which consists of a preview version and a public version.