Content projects
Contents
Create independent content repositories for your different teams and projects.
Introduction
Content projects represent the starting point of XP’s CMS. In order to create sites and content, you first need to create a project. Project defines default permissions and other useful settings for your content and editors.
Project settings
Basics
-
Display name - a human readable name
-
Identifier - a unique id within the installation. Cannot be changed when first created
-
Default language - Specifies the default language for content created in the project
Access mode
Project access mode defines default read permissions for it’s content. The available values are:
-
Public (Everyone can read the content)
-
Private (only users with project roles can read the content)
-
Custom (a specific list of principals can be granted access to read the content, i.e. Employees)
To handle private and custom mode, a special "viewer" role is created and given read access to the content items.
Roles
To provide access to a project or manage it, users can be granted special roles. The following roles are available per project:
-
Contributor - Access to project and issues (must be given specific permissions to create or manage any content)
-
Author - Same as contributor, but can additionally create and update content anywhere in the structure
-
Editor - Same as Author, but with full permissions and access to rich-text editor source mode
-
Owner - Same as Editor, but can also manage the project settings
For each project, dedicated principal roles are created. The roles are named as follows: com.enonic.cms.project.<id>.<roletype>
An example might be com.enonic.cms.myproject.author.
Applications
XP 7.12.0
Applications can be assigned directly to a content project. Most functionality, schemas (content types, mixins, x-data) as well as controller mappings be available within the scope of the project, until a site item appears.
Unlike sites, content at project level does not support pages, fragments and page page templates, so content preview and rendring must be done directly via Mappings.
It is also worth noting that configurations of applications assigned to a project will be published instantly - unlike changes to a site.
| Sites override project applications. If a site should use an application already assigned to its project, you must assign the application directly to the site. |
Layered projects inherit application settings from parent layers, just like .
| Sites inside the project are isolated and have no access to project’s or each other’s apps. |
Storage
Another important purpose of projecs is to strictly isolate the content from other projects. As such, each project gets a dedicated repository.
This means, that editors of a particular project will not be able to see, use or link to content within other projects.
Site engine
Site engine provides access to content in a specific branch of a specific project at /site/{projectId}/{branch}, where {projectId} is a unique project identifier. For example, draft items of a project with identifier ´myproject´ can be accessed via internal path /site/myproject/draft.
API
To programmatically manage projects, use the project API
