Content Repository configuration¶
You can define several Repositories within a single application. However, you can only use one per site.
Using default values¶
To use the default Repository connection, you do not need to specify its details:
1 2 3 4 5 6 7
Legacy storage engine
Legacy storage engine is the default storage engine for the Repository.
If no Repository is specified for a SiteAccess or SiteAccess group,
the first Repository defined under
ezplatform.repositories will be used:
1 2 3 4 5 6 7 8
Defining custom connection¶
You can also explicitly define a custom Repository connection:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
1 2 3
Field groups configuration¶
Field groups, used in content and Content Type editing, can be configured under the
Values entered there are Field group identifiers:
1 2 3 4 5
These identifiers can be given human-readable values and can be translated. Those values are used when editing Content Types.
The translation domain is
This example in
translations/ezplatform_fields_groups.en.yaml defines English names for Field groups:
1 2 3
Limit of archived Content item versions¶
default_version_archive_limit controls the number of archived versions per Content item that are stored in the Repository.
By default it is set to 5. This setting is configured in the following way (typically in
1 2 3 4 5
This limit is enforced on publishing a new version and only covers archived versions, not drafts.
default_version_archive_limit too high.
In Legacy storage engine you will see performance degradation if you store too many versions.
The default value of 5 is the recommended value, but the less content you have overall,
the more you can increase this to, for instance, 25 or even 50.
Removing old versions¶
You can use the
ibexa:content:cleanup-versions command to remove old content versions.
The command takes the following optional parameters:
t- status of versions to remove:
k- number of versions to keep
u- the User that the command will be performed as. The User must have the
content/versionreadPolicies. By default the
administratoruser is applied.
excluded-content-types- exclude versions of one or multiple Content Types from the cleanup procedure; separate multiple Content Types identifiers with the comma.
ibexa:content:cleanup-versions --status <status name> --keep <number of versions> --user <user name> --excluded-content-types article,blog_post
For example, the following command removes archived versions as user
admin, but leaves the 5 most recent versions:
ibexa:content:cleanup-versions --status archived --keep 5 --user administrator
ezplatform_default_settings.yaml contains two settings that indicate which Content Types are treated like users and user groups:
1 2 3 4 5
You can override these settings if you have other Content Types that should be treated as users/user groups in the Back Office. When viewing such Content in the Back Office you will be able to see e.g. the assigned Policies.
You can change the default path for top-level Locations such as Content or Media in the Back Office, e.g.:
1 2 3 4 5 6