Choose a page for content and layout at a particular address, a theme for a consistent visual style, and an extension for functionality your site does not already provide. A project can use all three, but each should have a clear purpose.
This guide helps site owners and developers agree on what to build before starting. First check the site's existing pages, settings, and installed extensions; the feature you need may already be available.
Start with the change you need
| What you want to change | Start with | Example |
|---|---|---|
| The information or arrangement on one page | A page | A service description, campaign landing page, or event overview |
| The same editable layout across several pages | A shared page template | Service pages with a common structure and different text |
| Colors, typography, and visual defaults across the site | A theme or existing Appearance settings | A consistent brand treatment for pages, posts, and docs |
| A workflow, integration, or reusable feature that is missing | An extension | A specialist tool with its own records, permissions, and admin controls |
| The destinations in your navigation or footer | Navigation and footer settings | Adding a link to a newly published page |
A design that looks like a store does not configure products or payments. Likewise, putting a button on a page does not create the service behind it. Identify both what visitors see and what must happen when they act.
Use a page for content and layout
Start in Site → Pages when the job is to present information at a website address. The Page Builder lets you arrange sections, text, images, links, and available blocks around the visitor's next step.
For example, a repair business can create a service page with an introduction, supported repairs, opening hours, and a booking link. If bookings are already configured, the page can direct visitors to that existing service. It does not need a new extension just to explain the service.
Follow Creating and publishing a website page to choose the address, save a new draft, review it, and publish it. When editing a published page, check the save action carefully: Save in the visual builder publishes its changes.
If several pages need the same structure, consider a shared page template. Keep each page's text and images in its page-specific fields. Publishing a shared template can affect other linked pages, so include those pages in the review.
A page is a good fit when existing blocks and configured services can deliver the required result. If the feature needs new server behavior, protected shared records, or a reusable admin workflow, plan that functionality separately. Never put private service credentials in page content or browser code.
Use a theme for a consistent visual style
A theme defines visual choices such as colors, typography, spacing, and presentation defaults for different page types. It can give your homepage, blog, docs, and authored pages a coherent appearance.
Check Settings → Appearance first. A logo, navigation setting, or existing appearance control may be enough for a small change. For a broader visual change, use Theme → Browse themes to compare available designs. A developer can also supply a compatible Cedros theme JSON file for upload and review.
Use Choosing and applying a theme for the complete workflow. Opening a review or uploading a theme does not apply it. Apply theme, followed by its confirmation, changes the live site's theme selection.
Keep these boundaries clear when briefing a designer or developer:
- The page owns its text, images, links, and section content.
- Navigation settings own the links visitors can follow; the theme controls their visual presentation.
- The theme supplies styling defaults. Page-specific styling and shared layouts can also influence the result.
- A theme does not add a business workflow, configure an integration, or provide an extension's behavior.
Review real content at desktop and mobile sizes, including long headings, tables, forms, and both light and dark appearance where offered. A sample preview does not establish how every page on your site will look.
Keep the original file and version of a custom theme. Switching themes does not undo page edits, and an updated library entry with the same name may no longer contain the earlier design.
Use an extension for new functionality
An extension is an installable package that adds capabilities to Cedros. Depending on its implementation, it can provide admin screens, page blocks, public experiences, integrations, or server-side operations.
Before commissioning one, check the installed extensions and available catalog. Follow Finding and installing an extension when an existing package meets the need.
A custom extension is appropriate when the missing behavior is the product: for example, a specialist customer tool with shared records and an administrator workflow. Define who can use it, what data it owns, which services it needs, and how its behavior should change when disabled or updated.
The developer must deliver a compatible, working Cedros extension package. A collection of page files or a description of desired capabilities is not an installable extension. Use Uploading a private extension when the package is ready.
Plan installation as a site change. Uploading a package can install and enable it; do not use the production uploader as a file preview. Review its source, compatibility, dependencies, and requested access before proceeding. Arrange testing on a separate test site for new functionality.
After installation, verify the feature's actual workflow. An enabled status does not establish that its provider configuration, permissions, or customer actions work. Include updates and data handling in the handoff; see Updating, disabling, or removing an extension.
Combine them when the project needs it
Consider a new customer tool with a public introduction page:
- The page explains the tool, answers common questions, and directs visitors to it.
- The extension implements the tool's behavior and any required records or permissions.
- The theme keeps the presentation consistent with the rest of the site.
You may only need the first two if the existing theme already fits. You may only need a page if an installed extension already supplies the tool.
Keep the responsibilities separate in the project brief. Changing the promotional copy should not require a new extension release, and changing the site's visual style should not require rebuilding the tool's business logic.
Agree on scope and verify the result
Before work starts:
- Write the outcome in visitor terms: what someone should be able to read, submit, find, or complete.
- Identify what already exists and list only the missing content, styling, and behavior.
- Assign each change to a page, shared template, theme, existing setting, or extension. Record any dependencies and the person responsible for maintaining custom work.
- Agree on the review and release steps, including affected pages, permitted users, test data, and a recovery plan.
Verify the result at the same level as the change. For a page, check its published address, content, links, and connected actions. For a theme, check representative live pages and navigation across screen sizes. For an extension, check both a successful workflow and an appropriate failure case, such as missing configuration or a user without permission.
If a proposed feature cannot be delivered through the site's available tools or extension contracts, resolve that requirement with the developer before committing to it. A visual mockup or successful preview alone is not a working integration.