Content, content types and locations #

This page is for developers who model content on the DXP. It names the parts of the content model, the repository service that handles each part in PHP, and the Exponential 6 term for readers who know that kernel. The services listed are the interfaces in Ibexa\Contracts\Core\Repository of the installed core (se7enxweb/exponential-platform-dxp-core).

Contents #

1. The parts of the model
2. Versions and translations
3. The tree
4. Access
5. Working with the repository in PHP
6. Modeling advice

The parts of the model #

The field types available are on The field types it ships.

Versions and translations #

Every change of a content item creates a version. A version is a draft until it is published; the previously published version is archived. exponential:content:cleanup-versions prunes old drafts and archived versions (Console commands).

Each version holds one or more translations. The languages of the repository are managed with LanguageService; which languages a siteaccess shows is its languages setting (Siteaccesses). The admin configuration in an installed project notes that content and content types start in eng-GB.

The tree #

Content items are placed in a tree of locations. A content item can have several locations; one is its main location. Moving, copying, hiding and trashing work on locations (LocationService, TrashService). exponential:copy-subtree <source> <target> copies a subtree from the command line.

Access #

Users and user groups are content items (UserService). Roles are sets of policies (module and function, with limitations), assigned to users or groups, optionally limited to a subtree or a section (RoleService, PermissionResolver). Console commands take a --user option and act with that user's permissions.

Working with the repository in PHP #

Inject the services into your own service in src/, never fetch them from the container by hand:

<?php

namespace App\Service;

use Ibexa\Contracts\Core\Repository\ContentService;
use Ibexa\Contracts\Core\Repository\LocationService;

final class ArticleReader
{
    public function __construct(
        private readonly ContentService $contentService,
        private readonly LocationService $locationService,
    ) {
    }

    public function titleOfLocation(int $locationId): string
    {
        $location = $this->locationService->loadLocation($locationId);
        $content = $this->contentService->loadContent($location->getContentId());

        return (string) $content->getFieldValue('title');
    }
}

The interfaces are upstream API: their full documentation is the upstream line's public API reference, which the DXP keeps compatible because the forks keep the namespaces (The se7enxweb forks).

Modeling advice #

• Model by meaning, not by page: an "Event" type with a date field, not a "Right column box".
• Prefer relations to copying: a relation field to an author content item instead of a text field with a name.
• Keep identifiers stable; templates, GraphQL types and API clients use them. The GraphQL schema is generated from your content types, so regenerate it after every change (GraphQL).
• After a content type change, reindex if search uses the changed fields (Reindexing).

Related pages #

• The field types it ships
• Twig functions you use daily
• Content classes for builders (Exponential 6)
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.