Updated: August 28, 2026

Page Templates and Content Types


Page Templates

Administrators can create reusable page templates using the visual editor. Editors then use these templates as a blueprint to launch new pages quickly and consistently.

Building a template is identical to building a page: simply drag and drop components onto the canvas. While pages are public, templates reside in a central registry. Once published, any page derived from a template automatically inherits its predefined content blocks.

Templates also define the default metadata structure. Administrators can add custom fields to a template, ensuring all resulting pages capture the necessary SEO or organizational data from the start.

To maintain consistency or structure, administrators can "lock" specific blocks (like headers or footers) within a template. Locked blocks cannot be modified by editors without permission, while "unlocked" blocks remain fully editable for page-specific content.

Creating a page template

Content Lifecycle and Versioning

The P1 Collaborative Content Repository (CCR) balances creative freedom for editors with structural control for administrators through the following mechanisms:

Editors can customize pages by adding new components or rearranging existing unlocked blocks. This allows for page-level flexibility without breaking the underlying template structure.

If a template and its derived pages diverge—known as "template drift"—P1 maintains their relationship. The visual editor includes a reconciliation tool, allowing administrators to push template updates out to existing pages manually or in batch.

For example, updating a footer in a template allows you to propagate that change across all associated pages. To prevent accidental overrides, this process requires manual review and confirmation.

Listing of pages from a page template

To create "list/detail" views (such as a blog index or directory), editors can use the built-in List component to aggregate pages created from a specific template.

The List component (found in the "Data" category) sources content from either the site’s internal page templates or a configured external data source (to be declared by developers in the site codebase).

Editors can choose from default layouts like Grid, Table, or List views. While developers can create custom views, editors manage the logic by mapping content fields to specific elements of the chosen component.

They can define sorting, group items by attributes, define a limited number of items to be displayed or even create filters.

Content Types and Structured Content Management

P1 enables structured content management without sacrificing the intuitive feel of a visual editor. It moves away from rigid, form-based interfaces, allowing for a more fluid editing experience. Page Templates can be used to define Content Types with specific layout and structure driven by the template document. P1 repository can be queried from API, MCP or the List component to build automated navigation for the structured content built with page templates.

By using Page Templates as the foundation for content types, you ensure data integrity while giving editors a visual workspace. P1 supports complex structured requirements without the steep learning curve of traditional headless systems.

Pro tip: You can also manage structured content from remote sources using these same features. This is ideal for organizations that maintain a separate database or API for their primary content assets, or for organizations who, by design, have a clear separation between users managing websites and users creating content.

Listing and showing structured content from a remote API