Store content

This page explains the options for creating, storing, categorizing, and managing reusable content available in Xperience by Kentico.

Before building your Xperience project, you should carefully consider different ways to store content. The business use cases you’ve identified during content modeling sessions will help you choose the most suitable approach for storing data.

Where to store your content

From a high-level perspective, you can look at creating and managing content in Xperience in two different ways:

Digital content and marketing channels

Marketing channels refer to platforms, tools, and strategies businesses use to communicate with their end consumers, suppliers, partners, and other business entities.

Digital marketing channels include a main site and campaign microsites, social media, emails, organic and paid search, or distributed content. Every channel offers various options to tailor marketing efforts according to specific goals and audience preferences.

In the past, businesses kept their marketing content separate for each channel. When a marketer wants to promote a campaign, they usually copy the campaign assets from the website to other platforms like email or social. Modern digital experience platforms like Xperience help marketers by removing unnecessary work.

Marketers can store all their marketing content within one solution. Using the same familiar interface, they can orchestrate the distribution of their content to their digital channels directly from within Xperience.

Store content in Xperience

In Xperience, all content is based on content types. You already know that a content type is a blueprint that defines data structure, functionality, and behavior for all content items editors create from this type. Based on this definition, reusing content requires storing it in a presentation-independent manner, i.e., in a structured format.

The following diagram shows an overview of the storage options in Xperience.

Use Content hub for reusable content

Xperience comes with the Content hub application for storing reusable content. You can think of the Content hub as a centralized repository where you create and keep all your marketing content – and potentially reuse it across multiple communication channels.

In Content hub, editors create items using content types with fields where they input data. The editing forms create a unified editing experience, and adding content in the content hub feels like filling out an online form.

Because the Content hub is channel agnostic, editors do not see what the content will look like once it’s displayed, for example, on the company website. They can focus on the quality of their content rather than getting distracted by how the content will look.

Aim for semantic content types

Semantic content types offer a structured approach to organizing information, making it easier for both humans and machines to understand and interact with. These types go beyond just presenting a set of images or texts; they provide a clear semantic context, making the content meaningful. When editors adapt this content for different channels, like a website, they can enrich the content with relevant information, such as date, time, or location, and further tailor the experience.

Semantic content types are particularly valuable when integrating XbyK with third-party systems like ERPs. This method creates a clear and consistent structure, allowing for efficient data synchronization. It simplifies maintaining meaningful content and ensures a seamless flow of information between systems.

Reusable content types from the data perspective

Content types in the Content hub store data in a structured format where fields correspond to database columns. Developers define content types in the Content types application.

When developers create content types, they configure:

• Fields that define the data structure of the content type.
• Editing form layout that creates the interface editors use to create and modify the content items.
• Usage of the content type:
  • Reusable content types are building blocks of reusable content meant to be linked together to form further content.
  • Content types for pages are used in website channels to form pages.
  • Content types for email are used in email channels to form emails.

Developers use the Content types application and define the data model of the website. They create content types based on the project’s business requirements using easy-to-use admin UI consisting of form fields or ready-made form components.

The content type is stored in a coupled database table; its fields represent database columns. For example, Kbank’s News content type can have a coupled table named Kbank_News and columns defined as NewsTitle, NewsSummary, or NewsText.

Store core content into reusable field schemas

While creating a content model or defining the data structure for a content type, you’ll often identify that some fields or sets of fields repeat across different content types. For example, all product-related content types will have the same fields to hold title, product description, product image, and core taxonomy. Some product-specific fields can also be similar. Some content types that editors will use for promotion might contain the same structure.

To manage these repetitions efficiently, we recommend using reusable field schemas that help you handle such fields across different content types.

The following image shows the Kbank demo site’s content types for storing products - Account, Card, and Loan.

All three product content types share two groups of schemas – the Core content schema and Financial data schema. While the Financial data schema is relevant only to the products, the Core content schema stores the same content as other content types in the Kbank demo site. For example, we show two more content types that share the same schema: the Featured content and Promotion.

Note that each content type has its dedicated fields relevant only to that specific content type, such as the Minimal inflow or account type in the Product - Account type field or the External URL field in the Featured content. We have discussed how to approach modeling taxonomies earlier in this content modeling guide.

Reusable field schemas from a data perspective

Unlike traditional fields, reusable field schemas give your team some flexibility. Both support the same data types, but the reusable field schemas are stored in the ContentItemCommonData table, making them available to every content type. Any changes to a schema also immediately propagate across every content type that references it. However, developers need to ensure that these additional fields display content as intended in the code.

Compose semantic content types with reusable field schemas and dedicated fields

Reusable field schemas rarely constitute complete semantic content types independently, though they can be part of one. Rather than forcing them into semantic content types, use them to define the smallest minor reusable data structure you want to share across multiple content types and have editors input data intended for use across different channels. This will allow your team to maintain consistency in their data while avoiding redundant work.

Functional reusable field schemas

Reusable field schemas can store some core content of semantic content types and define functional data structures that will be reused by different content types. We’ve already mentioned the financial data schema, which editors work in any Product content type in the Kbank demo site.

Similarly, you can define and use an SEO schema across every page content type.

To allow editors to add reusable parameters to URLs, developers can define UTM parameters schema and assign it to different call to actions, links, or email content types to store data they want to reuse.

Find out with which types Xperience comes out of the box in the Data type management. You will also learn how you can customize the out-of-the-box set to support different data types.

Semantic data in reusable field schemas

During content audit, you’ll identify data that repeats across different content types. It might a heading, some short summary text, reference to an asset, and tags from specific taxonomy collection. These schema represent the Core content that many of your content types consist of. By using a reusable field schema, you avoid the redundancy of defining similar fields across multiple content types. You can define Core content schema and integrate these schema into other content types. Semantically, they don’t define a specific content type that you can find in the schema.org. At the same time, they gather crucial information of content the company produces, meaning they might be considered semantic.

See the Core content schema shared across the products and articles on the Kbank demo site.

Use the built-in form components

Xperience provides different form components for content types that editors will use to input their data. Other form components may also have additional configuration options.

For example, the Long text data type comes with different text-based form components, such as the Text input, Password, URL, or Text area. For rich text, you can use the Rich text (HTML) data type with the Rich text editor form component.

Form components also come with various configuration options that provide different editing experiences. Developers can, for example, configure the Rich text form component as Structured content, Email content, or Contact notes. Developers can also customize their own configuration. The following image shows Kbank’s Rich text editor configuration options; the last News page editor configuration is custom.

Find out more about available Admin UI form components and the React input type components in the documentation.

Leverage linked content items

Xperience allows editors to compose their content items by combining data stored in several other content items.

Let’s examine the Product content type discussed on the previous page. Highlighted fields store the actual data inputs, while the light violet fields keep references to other content types that hold the values.

You can see that the Product type contains fields like Product features, Product benefits, or Product image. Sure, you can create two more fields and store values of product benefits and their icons within the Product. At the same time, why would you?

In real life, more than one product will offer the same benefits, such as included internet banking, getting a quick decision, or fast access to funds, if we take the Kbank demo site example.

Storing the information about benefits within the individual product content item restricts access to this data only within the context of this one (and only one) product item itself. If another product allows for fast access to funds, editors will need to duplicate the same wording and decorate with the same icon in another product item. Duplicating the same content often leads to content management nightmares.

When defining the content model, discuss which types can be reused and create them accordingly. To ensure reusability, developers will use the Content item data type with the Combined content selector form component.

Developers also specify which content type editors can select when they work with their content. The Combined content selector allows developers to specify, which content types editors select.

When an editor selects content items they want to use, rather than copying the values from the original item to the new item, Xperience creates a reference between these records.

Reusing content items improves content maintenance. When an editor updates the referenced item, the content changes are automatically promoted to every other item that uses this content, making content management a breeze. From the developer perspective, developers query in their custom code the linked items and return a collection of references to content items which they can further process. For example, they can retrieve URLs of web pages to which editors want to guide their audience.

One of the most typical examples of reusable content types are content item Assets that users store in the Content hub. See further examples mentioned in this guide in the Kbank demo site.

Avoid creating channel-specific content from linked content fragments

Customers who until recently used to display their content (stored in a CMS) only on the website, love using visual builders to create website content. Xperience offers Page Builder, which allows editors to assemble web pages using components like hero banners, text and image blocks, reviews, testimonials, and FAQs. For simplicity, we’ll call these components “content fragments.” These fragments aren’t semantic; they hold specific pieces of data that represent only a part of the overall information needed to convey the complete meaning of the content.

While this approach makes it easy for editors to craft entire web pages quickly in Xperience, it has limitations. The most significant advantage is speed and simplicity when you’re only concerned with presenting content on a single website channel. However, this method ties the content exclusively to the specific web page, meaning the fragments can’t be easily queried or reused across different channels in Xperience. By composing their content type using widgets, editors lock their content only within the context of that specific web page.

To build a more flexible, multi-channel solution, we recommend creating semantically defined reusable content types that are made up (composed or linked) from other reusable components. This approach ensures that the content isn’t just relevant to one specific channel but can be used and adapted across different platforms. It also makes the content queryable, structured, and easier to manage in the long term, giving developers more control over its use. We’ll discuss the Page Builder in detail on a dedicated page in this guide.

Storing reusable content in Content hub vs. custom module classes

Both options offer unique advantages when deciding between storing reusable content in Content hub or custom module classes. From a user perspective, we recommend considering the Content hub first before resorting to choosing custom module classes.

The Content hub provides default Kentico functionality, including editing workflows, multilingual support, usage reports for improving content curation, or a built-in user interface. Additionally, the Content hub allows editors to easily manage and reuse content across various channels, making it highly flexible for developers and editors. Using Content hub often means developers don’t have to create custom UI components, saving time and effort.

A key benefit of the Content hub is its ability to integrate with APIs, enabling content creation from third-party sources. Upcoming features are expected to enhance this functionality further, making it an even more powerful tool. Using the Content hub, developers can focus on supporting content management through out-of-the-box components rather than building custom solutions, leading to quicker deployment and easier maintenance.

Store files in Xperience

Work with managed files

Xperience allows you to store files of various file types in Xperience, such as photos, pictures, sound files, videos, package files, presentations, or document files. We call files stored through the Xperience interface managed files. Xperience comes with tools that allow editors to upload the files into the system or add their uploaded files to the rest of their marketing content. To help developers, Xperience contains prebuilt form components for uploading or selecting files,  procedures for storing the files, and optimized methods that developers can use to retrieve the files to the live site.

Xperience doesn’t restrict you to storing only media. You can also store non-media files such as spreadsheets, documents, or PDF files. Using the Settings application and custom definitions in code, developers ensure that editors can work with different files as specified in the project requirements.

Files stored in Xperience can also be served through a CDN. Xperience natively supports using Azure Blob storage and Amazon S3 file providers. However, developers can customize Xperience to support other file providers.

Xperience comes with two approaches to storing managed files:

• Storing files in Content hub
• Storing files in Media libraries

Store assets in Content hub

As the Content hub application is the centralized location for managing and distributing marketing content, we recommend storing your media files here.

Editors can store any file type. Out-of-the-box, Xperience supports the most common file types. Developers can additionally configure the Content hub application to support different file types or file sizes. Storing files in the Content hub also allows editors to restrict access to a specific asset only for authenticated users.

Asset content type

To store files in the Content hub, developers can create a custom content type and prepare fields based on the project requirements for a custom Media or Asset content type.

From Xperience’s perspective, an Asset content type should contain the binary file and additional related information. Xperience comes out of the box with the Asset selector form control that you can use when defining the content type.

For example, Kbank’s Asset type consists of the File field that uses the Asset uploader form control and references the binary itself, and additional fields, such as AltText or Description, which marketers can use to categorize or decorate their data.

When editors add an image to their content item, they use the Combined content selector form component that is scoped against the Asset content type. To display the assets correctly, developers need to retrieve the linked assets. At the same time, the built-in Rich text editor natively supports selecting assets from the Content hub into the text field and automatically retrieves them from the hub.

When to store files in Media libraries

Media libraries application offers a second way of storing files in Xperience. Despite its name, editors can add files of any type, as in the Content hub, and reuse them in different content types across the website channels. Developers can use the out-of-the-box Media file selector form component when they define content types that usually contain some media element, such as articles, banners, or videos.

Editors can create a hierarchy of folders within a media library to store their files. They can also adjust some basic properties of the file, such as its title or description.

When an editor selects the file they want to display on the live site, they create a reference to the file stored in the media library. Developers can access media library files without querying the database, reducing overhead. The media libraries must be deployed in Azure Blob storage when deploying to the SaaS environment.

Compared to storing assets in the Content hub, where developers define custom fields for asset properties, they will need to extend the existing UI of media libraries if you need additional options. Out-of-the-box media libraries also don’t allow editors to categorize their assets with taxonomies, making them a less optimal choice for asset management. Media libraries also don’t store language variants of assets editors can create when storing assets in the Content hub. Unlike files in media libraries, editors can determine the life-cycle of assets in the Content hub through publishing workflows.

Using files stored in media libraries isn’t limited to the website channel’s content types. Developers can prepare mechanisms that allow editors to:

• Share files from the website channel to other marketing channels, and share the file’s URL with external users if necessary.
• Media libraries are used to manage large amounts of files of any type that the business controls.

Recommendations – Media libraries

Before you decide using media libraries, consider storing files and other assets in the Content hub. There are only a few situations in which you might want to consider using media libraries, for example:

• Storing sizeable files (for example, long videos).
• Reusing stored files on other marketing channels outside Xperience.
• Planning to move your asset management into a 3rd party Digital Asset Management solution soon into the project.

Based on the size of the editing team and the way the team works, we recommend creating a more granular system of media libraries rather than a massive media library with a complex subfolder structure.

Note on unmanaged files

You can also use unmanaged files in your Xperience application. Unmanaged files refer to all files that content creators do not edit from the Xperience administration or via the platform’s API. Examples include:

• Static files used for website channel design, such as images, favicons, fonts, JavaScript, and CSS files, stored in the wwwroot folder.

• Files stored in the website project outside of media libraries. Such as files required by custom functionality or integration unrelated to Xperience content management.

  • Use subfolders under ~/assets/<project_name> to store such files (outside the media folder containing media library subfolders). When deploying to the SaaS environment, these files must be deployed in Azure Blob storage.

Create channel-specific content

From a marketing perspective, not all content will be distributed across multiple marketing channels. Content like personalized call to action button labels or page headings will likely be specific to only the website channel, and it doesn’t have to exist in the Content hub. Your team will create these items directly inside the channel and keep them there. For this reason, it’s not possible to create channel-specific content like a page with a URL directly in the Content hub.

Make designing content generic

Though you might want to store design-specific information, like exact color codes or sizes, inside the channel-specific content types, we do not recommend this. From a content longevity perspective, you want to have your design information as agnostic to the visual design as possible. When you decide to, for example, redesign your brand, it’s easier to remap the generic class name to new colors than change the specific #F05A22 brand color code in hundreds of different places. The following screenshot shows styling options in the Kbank demo site.

What’s next?

You have learned about the options for storing data in Xperience. In the Design content section, you’ll learn about different approaches to designing and presenting this data in your application.