arrow-down
    1. Overview
    2. Core concepts
    3. Using docs
    4. Intro Videos
    5. Tutorials
    1. Intro
    2. GraphQL API
    3. Media API
    4. Extending the API
    5. Component API
    1. Content Studio
      1. Branches
    2. Layers
      1. Lifecycle
      2. Media
      3. Attachments
      4. X-data
        1. Page templates
        2. Fragments
      5. Variants
      6. Permissions
      7. Versions
    3. Sites
      1. Visual editor
    4. Publishing
    1. Introduction
      1. Controllers
      2. Globals
      3. Events
      4. HTTP Request
      5. HTTP Response
      6. Error handler
      7. Filters
      8. Templating
      9. Localization
      10. Websocket
      11. Tasks
      12. Main controller
      13. Java bridge
      1. Admin Lib
      2. Application Lib
      3. Auditlog Lib
      4. Authentication Lib
      5. Cluster Lib
      6. Common Lib
      7. Content Lib
      8. Context Lib
      9. Event Lib
      10. Export Lib
      11. Grid Lib
      12. I18N Lib
      13. IO Lib
      14. Mail Lib
      15. Node Lib
      16. Portal Lib
      17. Project Lib
      18. Repo Lib
      19. Scheduler Lib
      20. Schema Lib
      21. Tasks Lib
      22. Value Lib
      23. VHost Lib
      24. Websocket Lib
    2. Other Libraries
      1. CLI
      2. Sandboxes
      3. Code
      4. Building
      5. Configuration
      6. TypeScript
    3. Building APIs
      1. Mappings
      2. Components
      3. Processors
      4. Contributions
    4. Building Webapps
      1. ID providers
      2. Admin Apps
      3. Admin Widgets
    1. Architecture
      1. TODO
      1. Navigating
      2. Users
      3. Applications
      4. Data management
      5. System info
      6. Audit Logs
      7. Task management
      1. Portal
      2. IDprovider
      3. Management
      4. Statistics
      1. Nodes and repos
      2. Properties
      3. Indexing
      4. Branches
      5. Editors
      1. DSL Queries
      2. NoQL Queries
      3. Filters
      4. Aggregations
      5. Highlighting
      1. ID providers
      2. System ID provider
      3. Users and groups
      4. Roles
      1. Strategies
      2. Distributions
      3. Docker
      4. Kubernetes
      5. Systemd
      6. Vhosts
      7. Configuration
      8. Backup & restore
      9. Clustering
      10. Observability
      1. Notes
      2. Upgrade
      3. Upgrading Apps
        1. Asset service
        2. HTTP service
        3. Image service
    1. Best practice
        1. AttachmentUploader
        2. Checkbox
        3. Combobox
        4. ContentSelector
        5. ContentTypeFilter
        6. CustomSelector
        7. Date
        8. DateTime
        9. Double
        10. GeoPoint
        11. HtmlArea
        12. ImageSelector
        13. Long
        14. MediaSelector
        15. Radiobutton
        16. Tag
        17. TextArea
        18. TextLine
        19. Time
        1. Field set
        2. Item set
        3. Option set
      1. Mixins
      2. Localization
      3. Styles
    2. Content Types
    3. X-data
    4. Macros
      1. Pages
      2. Regions
      3. Part component
      4. Layout component
      5. Text component
      6. Component Filtering
      7. Component Indexing
    1. Marketplace
    2. Market guidelines

Content layers

Contents

XP 7.6.0

Introduction

Enriching, translating, localising and reusing content across different channels are among the most complex content management practices to solve. Content layers offer a practical and secure solution to this for both editors and developers.

The problem

Multi-site, multi-region, multi-language and more. Supporting management of content across regions, languages and other channels has been the goal of CMS since its conception. The problems are many and complex:

  • How to localise content

  • How to keep content syncronised

  • How to assure timely publishing for each channel

  • Who can manage what content

  • Who can access that content

  • How to effectively re-use content across channels

  • How to avoid copying content

  • How to collaborate across channels

  • Etc..

A layered solution

Layers are essentially content projects with a twist. Like regular projects, each layer has it’s own repository, permissions and default language. Layers introduce the additional setting of parent project. Layers will automatically inherit content from their parent layer. Multiple layers can collectively form a tree structure, where the root layer itself is a regular project.

Tree structure of projects

Inheritance

The core concept of layers is that inherited content maintains the same ID across all layers. Inherited items can be published independently within each layer. In addition to inheriting content, one may also create original content in each layer as required. One may also move items around, and organise content differently per layer.

Localization

Inherited items may be localised (edited) within each layer as needed. By localising, the item will stop inheriting the parts of the item that were localised.

An item may be localised in the following ways independently:

  • by name (the item’s path name)

  • by parent (the placement of the item in the tree structure)

  • by default sorting (default sorting of child items in the structure)

  • by ediorial content (the editorial data of the item)

Once a part of an item is localised, it will stop inheriting that specific part. This for instance means you may move a part around in your structure, and even give it another path name, but keep inheriting the actual content, or visa versa.

Content actions

Working with content in a layer is essentially the same as working with a regular project. You may create, modify, move and publish items as desired. The layering system will automatically ensure the rules of inheritance are controlled. For instance, your actions will automatically set the relevant flags for what to inherit or not.

For instance, by renaming content, the system will automatically disable inheritance for the name of the item, unless the item is originally created in this layer naturally.

In addition to existing content actions, localization may also be reset. For instance, if you at some point localised the content of an item, it can be returned it to the inherited state again. Just like any other editing action, this will effectively create a new version of the item.

Versions

Like a regular project, only versions created within a specific layer will be available. This also means your data will not be polluted by "noise" from the surrounding layers. You will for instance not see versions created in child items etc.

Child layers will inherit all new versions of an item until the item is "marked as ready" in the parent layer. Later, only versions "marked as ready" in the parent layer are propagated to the child layer(s). This effectively reduces "noise" in the child layers, as well as improves performance.

Replication engine

XP features a background event listener that instantly detects changes to content and replicate this across layers. Additionally, a background job continuously runs to verify the consistency of the layers, should any replication fail or be interrupted during it’s initial run.

The replication engine uses the following node layer properties to control the inheritance and localization state of an item:

"inherit": [
    "PARENT",
    "SORT",
    "CONTENT",
    "NAME"
  ],
"originProject": "myproject"

As an example, this is what the the item might look like when inherited across multiple layers:

  • Norwegian layer: localised name

  • German layer: localised content

  • French layer: localised name, and content

Content inherited and localised in layers

API

To programmatically manage layers, use the project API.


Contents

Contents

AI-powered search

Juke AI