Concepts

A content item is a single piece of content in the repository — an article, an image, a page, a site. Every content item has an identity (path, display name, id), a type, a set of field values, and a small envelope of metadata (security, schedule, workflow state).

A content type is the schema that defines what fields a content item has. Some types ship with XP (see Content types); others are defined in application code.

Editors create and edit content items; developers define content types.

A site is a special kind of content item that sits at the root of a website. Sites can have installed applications attached to them, which contribute the components (parts, layouts, page controllers) used in rendering. Each site automatically gets a Templates folder where page templates live.

A page template is a reusable page definition that renders one or more content types as a page. Page building happens in the Page editor, where components are placed into the regions the template defines.

A project is a top-level container for content — a separate repository root with its own content tree, applications, and settings. See Projects.

A layer is a project that inherits its content from another project. Layers allow localization (translate inherited content into another language) and selective override without duplicating entire trees. See Layers & localization.

Content in Content Studio is always edited in the draft branch. Publishing copies the active draft version of an item into the master branch, from which it becomes available to public consumers of the API.

Workflow state is the signal between editors that a draft is (or isn’t) ready to publish — In progress, Ready for publishing, Publish request, Published, Unpublished. See Workflow for the state machine and Publish for the actual publishing flow.

Every save, publish, unpublish, rename, or permissions change on a content item creates a new version. Versions can be compared and reverted from the Version history widget — see Versions.

Content items reference each other — pages embed images, shortcuts target content, text fields link to other items. Those references are dependencies, tracked in both directions (inbound: who uses this; outbound: what does this use). Publishing, archiving, and unpublishing all check dependencies — see Dependencies.

Each content item has its own security settings: a list of principals (users, groups, roles) and the permission flags they have on that item (Read, Create, Modify, Delete, Publish, Read/Write permissions). Permissions are inherited from parent content by default and can be overridden per-item. See Permissions.

Deleting content is destructive. Archiving is the non-destructive alternative — items are moved to a separate archive storage where they can be browsed, restored, or permanently deleted later. See Archive.

An application is an installable unit of XP code that can contribute content types, page controllers, parts, layouts, translations, and UI widgets. Applications are attached to a site via its Applications field; some (like Juke and Content Studio+) contribute UI across all sites.

A widget is a small UI surface contributed by an application. The main host for widgets is the Context panel on the right of the Navigator and Editor; applications can also contribute preview modes and main-menu entries.

Issues are lightweight work items used to coordinate between editors — either a task (e.g. "spellcheck this article") or a publish request (review-and-publish handoff for users without publish permission, or just for approval flow). See Issues and Publish request.

Content Studio itself is free and open source. A paid Enonic subscription unlocks Content Studio+ — a companion application that adds the AI Assistant, the Archive browser, Content Variants, AI translation for layers, and the Layers widget. Pages that document a Content Studio+ feature carry a Content Studio+ feature admonition at the top.