arrow-down
    1. Widgets
  1. IAM
    1. Virtual apps
    1. Projects
    2. Layers
        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
      4. Mixins
      5. Localization
    3. Content Types
    4. X-data
    5. Macros
    6. Custom styles
    7. Sites
      1. Regions
      2. Part component
      3. Layout component
      4. Text component
      5. Fragments
      6. Filtering
      7. Component indexing
      8. Visual editor
    8. Page templates
    1. Sandboxes
    2. Code
    3. Building
    4. Configuration
    1. Globals
    2. HTTP
    3. Controllers
    4. Filters
    5. Events
    6. Websocket
    7. Error handler
    8. ID provider
    9. Tasks
    10. Localization
    11. Mappings
    12. Components
    13. Processors
    14. Contributions
    15. Templating
    16. Main controller
    17. Java bridge
      1. Webapp Engine
        1. Image service
        2. Component service
      2. Admin Engine
      3. Asset service
      4. HTTP service
      5. IDprovider service
    1. Task engine
    2. Management Endpoint
    3. Statistics Endpoint
    1. Nodes and repos
    2. Properties
    3. Indexing
    4. Branches
    5. Queries (NoQL)
    6. Queries (DSL)
    7. Filters
    8. Aggregations
    9. Highlighting
    10. Editors
    1. Strategies
    2. Distributions
    3. Docker image
    4. Vhosts
    5. Configuration
    6. Backup & restore
    7. Systemd
    8. Clustering
    1. Admin API
    2. Application API
    3. Auditlog API
    4. Authentication API
    5. Cluster API
    6. Common API
    7. Content API
    8. Context API
    9. Event API
    10. Export API
    11. Grid API
    12. I18N API
    13. IO API
    14. Mail API
    15. Node API
    16. Portal API
    17. Project API
    18. Repo API
    19. Scheduler API
    20. Schema API
    21. Tasks API
    22. Value API
    23. VHost API
    24. Websocket API
  2. Audit Logs
    1. Upgrade Notes
    2. Upgrading Apps

Content layers

Contents

XP XP 7.6.0 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