Frequently asked questions

In CMS, you often organize content in parent-child structures, creating a conceptual "tree." You create content as a "child" of existing content, letting you traverse and reference these relationships for rendering navigation and other aggregation concepts. CMS supports this parent-child structure, enabling multiple trees and displaying content in various tree locations. The CMS (SaaS) hierarchy lets you enforce type restrictions, allowing you to create objects of a specific type as children of another type.

Content goes beyond structured text—it also includes files like images,
documents, audio, and video. Consider media files such as images and PDF documents as full-content objects. You can model media files with properties
like other content types. They are subject to the same features as other
content, like permissions and workflow.

CMS (SaaS) returns file URLs for uploaded videos in the original format and supports pseudo-streaming.

You might need to visually compose more complex content from multiple content objects. CMS (SaaS) allows you to construct content using a library of reusable elements, arrange these elements on a page surface, and order them serially to create a continuous stretch of narrative content.

The decision to implement "global" Shared blocks, such as a
"Header" or "Footer" block depends on your "head" (front end) implementation.
You can create shared blocks for these elements and render them on each page.
Depending on your front-end framework, you may have concepts like master pages
or layouts that are reused across different pages.
You can create content types for the footer and
header with a base set to block to achieve "global" blocks. Then, create shared block
instances of these types. These instances can be queried from Optimizely
Graph individually, separate from page queries.

A specific property on a specific type might need to be a live reference to
another content object. For example, the Manager property of your Employee
Profile object might need to conceptually point to another object in the
repository. CMS (SaaS) lets you refer to other objects in this way. You can
limit the selection of a target object by type or other criteria.

CMS (SaaS) lets a property's value be a completely self-contained content
object that exists inside the lifecycle of the parent content object rather
than referring to another content object.

See blog post: How to obtain an Optimizely CMS (SaaS) developer instance by Jonas Bowman.

Yes, CMS (SaaS) lets you store custom, unique data, or provide a custom
editorial interface for a specific property.

No, CMS (SaaS) does not support conditional properties for
block properties, such as displaying or hiding
certain properties based on the selection of another property. Instead,
you can limit block types within a content area and restrict child pages
to achieve some level of control over content presentation.

Beyond data types, CMS (SaaS) lets you specify domain-specific rules around
content entry.

• Specify that a property is required.
• Specify an allowed range. For instance, the value must be numeric and between 10 and 100.
• Specify that a date value must be in the future or the past.
• Apply a regular expression pattern matching the value to ensure that it is a valid
  email address or phone number or conforms to some other pattern.
• Apply rules if a value is entered to allow null values universally.

CMS (SaaS) does not support custom validation rules. CMS (SaaS) supports individual property validations such as regex and minimum or maximum required. You can provide custom validation rules in CMS 12 (PaaS).

CMS (SaaS) ensures that labeled data is of a certain type and can specify
that a property should be only numeric or a valid date of an arbitrary
precision (just the date, for example, or the date and time).

Much like referential integrity in a relational database, you should enforce and validate some links. CMS (SaaS) lets you refer to another content
object to ensure that a link remains intact. You can cancel the deletion and
warn the editor that an object is linked to other objects.

Not every editor should have access to every type or property. CMS (SaaS)
lets you bind your create and edit permissions to a content type definition
so that only certain authors can work with specific types. Apply permissions
in individual properties so that only certain authors can edit those
properties. Specify a type as a singleton so that only one object of that
type can exist. Integrate external content with levels of repository
abstraction, where you populate sections of the content repository from
external systems in real-time. You can also mass-upload or intake and update
the API from external sources.

Content administrators sometimes need help understanding the details of the
content model. CMS (SaaS) provides additional editing instructions to help
content administrators understand how to manage the content.

CMS (SaaS) lets you organize properties into tabs or expandable sections,
which is critical when editing a complicated object. You can display certain
fields or sub-interfaces to certain users or groups of users.

CMS (SaaS) uses a rich text editor (TinyMCE) that you can configure for
content administrators. You also can examine and sanitize the HTML before
storing the content.

Consider how each property and its datatype contributes to its editorial UI.
CMS (SaaS) is well-organized and usable for the average editor.

Each unique CMS (SaaS) bundle of properties is a "type" of content.

When you work with CMS (SaaS) content, predictable types of data make it
easier to manipulate and transform it. When you retrieve a content object during templating or an API operation (the local API or a headless or remote API), the system strongly types it. The content can auto-populate a strongly typed
object specific to the underlying programming.

Some systems require you to model from a UI, while others let you specify the
content model in code or configuration files which you can check into source
control, versioned, and moved through a DevOps process. CMS (SaaS) process
fits with your DevOps process. CMS (SaaS) lets your content modeling
specifications and changes move through your different development and
testing environments.

Content models evolve, and when actual content weighs them down, this can be complicated. After you enter hundreds or thousands of content
objects, CMS (SaaS) lets you change the content model or underlying type of
existing content. You can reconcile differing content definitions without
the loss of data.

Currently, CMS (SaaS) does not export application-specific metadata, such as
SiteID, to Optimizely Graph. Store the key for the start page of each application as a configuration within your sites to manage a multi-site configuration. When fetching pages from Optimizely Graph, use the full URL,
including the hostname, rather than just the path. This lets you retrieve
content from different sites within your multi-site environment.

Yes, go to Applications and map your host to a language
and the system indexes the URLs without language segments. For example, to remove
the locale prefix en from the URL so it would be example.com/my-page
instead of example.com/en/my-page. Map the host, example in
example.com to the language 'en'.

CMS (SaaS) does not have image resizing capabilities. You can instead
resize your images from your CDN. See
Image resizing using CDN.

When content administrators need to embed an image in rich text or link to a
downloadable file, they need to locate assets. When you link these assets, CMS (SaaS) retains the reference so you can check and enforce the dependencies.