The Content Hierarchy
Pala organizes content in three levels:Understanding the Structure
Let’s break down how everything fits together with three focused diagrams: 1. Content Hierarchy - Your actual content structure: 2. Templates & Structure - How structure is defined: 3. Data Model - How content is stored:Key concepts: Blocks are self-contained full-width components written in Svelte. They define a content schema using fields and are instantiated as sections when added to pages. Page Types define which blocks can be used, fixed sections (header/body/footer), and page-level fields. Fields define data schemas, Entries store the actual values.
Sites
A site is your top-level container. Each site is completely independent with its own:- Site-wide content - Navigation menus, logo, footer content, social links
- Design system - CSS variables for colors, typography, spacing
- Page types - Templates that define page structure
- Site-specific blocks - Blocks available only to this site
- Domain - Each site is tied to a specific hostname
- Pick one of your existing sites as a template
- Choose a starter from the marketplace (blog, portfolio, restaurant, etc.)
- Start with a blank starter to build from scratch
Page Types
Page types are templates that define the structure and capabilities of pages. To create one, you simply give it a name, icon, and color. Then you configure:- Page fields - Content like title, description, publish date, or relational fields (e.g. author, location, etc.)
- Available blocks - Which blocks editors can add to pages
- Fixed sections - Static header/body/footer sections that appear on every page of this type (also called “Static page types” in the UI when body sections are fixed)
Example Page Type Uses
Page types are completely customizable. Here are common examples: Content Types:- Blog Post - For individual blog articles
- Person - For team member profiles
- Event - For event listings
- Case Study - For portfolio pieces
- Location - For store/office locations
- Product - For e-commerce items
- Documentation - For help articles
- Blank - No fixed sections, all blocks available
- Standard - Header/footer with standard blocks
- Editorial - Reading-focused layout with limited blocks
Example: Blog Post Page Type
Example: Blog Post Page Type
A “Blog Post” page type might include:
- Fixed header sections - Site navigation (static content across all blog posts) + page header (pulls title from page field)
- Page fields: Title, Description, Author, Publish Date, Featured Image
- Available blocks: Hero, Text, Image, Code Block, Call-to-Action, Video
- Fixed footer sections - Newsletter signup form (static content across all blog posts) + site footer
About Fixed Sections
Fixed sections (ie sections within the header/footer slots) contain static content that stays the same across all pages of that type. If you want dynamic content in a fixed section (like showing the page title), you should connect it to a page field:Block Availability
Pala doesn’t differentiate between types of blocks - you control which blocks are available per page type. For one-time-use blocks (like a homepage hero), toggle it on, place it on the page, then toggle it off. Toggling it off doesn’t remove it from existing pages, just prevents editors from adding it again. Cross-page type dependencies: When a block references fields from a different page type, Pala shows a broken link icon with “References Page Fields from [Page Type]”. You can still add the block, but those fields won’t have data. To use a block across multiple page types, give each field the same key (e.g., a header block withtitle fields connected to both “Blank” and “Standard” page types, both referenced as {title} in the code).
Pages
Pages are instances of page types. In Pala, everything is a page - whether it’s content (blog post, team member) or layout (homepage, about page).Creating Pages
To create a page:- Open the page list - Click “Pages” in the toolbar
- Choose creation method:
- Click “Create Page” for a top-level page
- Click “Create Subpage” next to a page to create a child page (or click the three-dot menu on a child-less page)
- Configure the page:
- Name - Internal identifier (or external if using
_meta.name) - Slug - URL path segment
- Page Type - Template to use (hidden if only one exists)
- Name - Internal identifier (or external if using
- Add content:
- Fill out page fields
- Add sections from available blocks (or edit existing default sections)
- Fixed sections (if any) are already in place and can’t be removed
- Publish when ready
Blocks
Blocks are self-contained full-width components written in Svelte. They define a content schema using fields and are instantiated as sections when added to pages.Two Types of Blocks
Library Blocks:- Stored in your server library
- Reusable across all your sites
- Build once, use everywhere
- Available only to one site
- Useful for site-specific components
- Don’t clutter your server library
Block Structure
Each block contains:- Component code - Svelte component with HTML, CSS, and JavaScript
- Content fields - Editable data that editors can modify
- Field configuration - Define what content can be edited and how
Sections
Sections are instances of blocks placed on pages. When you add a block to a page, you’re actually creating a section - an instance of that block with its own content. Think of it this way:- Block = template/blueprint (the code and schema)
- Section = instance (the actual content on a page)
Example: Blocks vs Sections
Example: Blocks vs Sections
You have a “Hero” block in your library. When editors add it to the homepage, they create a section. That section has its own content (headline, image, etc.) separate from other Hero sections on different pages.
- The same block to be used multiple times with different content
- Block code updates to apply to all sections using that block
- Each section to maintain its own content independently
The Collaboration Model
This hierarchy enables a powerful collaboration model: Developer Role:- Define page types with available blocks
- Set required blocks and constraints
- Build and style components
- Configure content fields
- Create pages from page types
- Add and arrange sections from blocks
- Edit content within fields
- Publish when ready
Editors cannot modify page types, edit component code, or change design settings (unless pre-configured, like block variations). They work within the guardrails you define, ensuring designs stay intact while content remains flexible.
Putting It Together
Here’s how it all works in practice:- You create a site and choose a starter
- You define page types like “Blog Post” with available blocks and fixed sections
- You build blocks (Hero, Text, Image) and add them to your library
- Editors create pages using the “Blog Post” page type
- Editors add sections (instances of blocks) from the available options
- Editors edit content within each section’s fields
- Editors publish when ready
- Repeat from step 2 as required or desired