Find the repetition before choosing fields
Start with a set of real pages, circle what repeats, and separate required content from optional sections. That exercise produces a useful page type more reliably than copying the first page’s current layout.
Start with pages people recognise
Turn articles, services and campaigns into clear editing forms instead of a blank canvas.
A useful content model begins with the information a reader needs and the changes an editor makes repeatedly. Capell page types give those repeated pages a shared definition. The examples below help you decide what belongs in fields, what should be reused and what needs to stay specific to one page.
Good content modelling is what separates a site that ages well from one that needs a rebuild. The trick is to notice that most pages are variations on a few shapes, then model those shapes once.
Capell uses page types for exactly this. Articles, landing pages, documentation, and product or service pages each become a reusable type with shared fields and layout.
Why this matters
- The tenth article reuses the first article's structure.
- A redesign improves every page of a type at once.
- A new field is added to the type, not to each page.
- Developers keep the model in code where it can be reviewed.
Start from these examples, adapt them to your content, and the site will keep its shape as it grows.
Give each page a purpose
Choose fields around a reader question and an editorial task.
A service page needs to explain the offer, who it helps and how to enquire. An article needs a clear subject, body and relevant next reading. A campaign adds an offer, time window and action. Keeping those shapes distinct makes the form easier to understand and the public presentation more predictable.
Start with the smallest useful definition and create two genuinely different examples. Do not add optional fields for every imagined future design. When editors consistently need another piece of information, add it to the shared definition and review the pages that use it.
Reuse the right material
Share information that must stay consistent without tying unrelated offers together.
A contact address or reusable testimonial may deserve one maintained home. A campaign headline usually belongs to its own page. Sharing everything makes a small correction unexpectedly affect other pages; copying everything makes site-wide changes expensive.
Write down the ownership of each reusable asset and where changes should appear. Keep page content separate from the layout that presents it. The result should let the team redesign a page family without rebuilding the underlying editorial records.
Model four familiar page families
Each model below is a starting model, not a fixed schema: developers define the blueprint in code, so its fields, groups and validation are reviewed like any other change. An article usually needs predictable editorial fields; a campaign page needs bounded composition; documentation needs durable anchors and hierarchy; a catalogue record needs consistent attributes.
How reuse keeps cost down
Reusable models are where long-term cost is won or lost. When a page type carries the structure, a new field, a redesign, or an SEO change lands once and applies everywhere, instead of being repeated page by page.
Practical journeys
Put maintained guidance beside the work people do
Illustrative project recipes, not delivered integrations or customer case studies.
Your application already knows which order, integration or item a person is looking at. Capell can hold the explanation around it: Pages with maintained URLs, repeated fields, shared presentation and Page history. The application still decides what that person may see or do.
For appointment preparation and arrival guidance, follow the appointment integration on the developer path. That single example connects service and location selection to the existing booking flow; these recipes explore other uses of the same boundary.
Foundation supplies Page editing, page types, shared layouts and Page history. It does not supply the connections to your domain records. Optional packages have separate installation and availability requirements; check the feature catalogue and current extension listings before planning an installation.
Four journeys around the records your application owns
These project recipes use Foundation for Pages and shared presentation. Each needs application-specific associations and rendering work; none is a ready-made connector. Follow a card for the visitor steps, editorial task and remaining development.
Practical journeys
Help with the order in front of you
A customer reads the right instructions while the application decides whether a return is allowed.
Visitor journey
- Open an order through the application’s authenticated account area.
- Read maintained packing and troubleshooting guidance associated with that order’s product or service.
- Use the genuine return action only if the application permits it for this customer, order and deadline.
Editor’s task
Update the packing instructions in a reusable guide Page, preview the change and use Page history to compare or restore its content. An instruction change does not alter the order or extend a return deadline.
What the developer adds
Keep order ownership, eligibility, deadlines, returns and refunds in the existing application. Add scoped guide associations, missing-guide handling and a safe rendering projection prepared before Blade. Keep personal order state out of shared public HTML and decide how instruction changes become visible beside fresh eligibility checks.
Foundation is the CMS baseline for this recipe; no commerce connector or Customer Portal package is implied. A few stable instructions in an existing Filament resource may be sufficient for a simpler brief. Read the public-site implementation guide.
Practical journeys
Show the next useful setup instruction
A disconnected, pending or ready integration can lead to different maintained guidance.
Visitor journey
- Open the application’s integration setup screen.
- Read the guide selected for its actual disconnected, pending or ready state.
- Use the application’s Connect or Retry action, or continue when verification says the integration is ready.
Editor’s task
Maintain provider instructions and screenshots in guide Pages without changing connection rules. Repeated guide fields and shared layouts keep related instructions consistent; Page history covers the guide content.
What the developer adds
Map real integration states to guides, scope each lookup and prepare the safe content before rendering. Handle an absent guide and a state changing during the request. Authentication, entitlements, verification and operational actions stay in the application, with an explicit freshness policy for private responses.
This is a Foundation-led application recipe, not a delivered provider integration. For a short setup screen that rarely changes, ordinary application text may suffice. Read the fit guide.
Practical journeys
Give real items a useful editorial home
Curate a collection without making the CMS the authority for stock, price or availability.
Visitor journey
- Browse a maintained collection of spare parts, properties or other application records.
- Read selection guidance and follow the associated item.
- Check the application’s current compatibility, stock, price or bookability before acting.
Editor’s task
Write the collection introduction, explain the selection and maintain related guide Pages. Developers define the permitted associations and shared presentation; editors work within that shape.
What the developer adds
Project authorised domain records into public-safe render data, resolve selected records in a bounded query and handle removed or inaccessible items. Register the relevant cache dependencies and choose when operational values are refreshed. A Page restore does not restore stock, prices or reservations.
Foundation supplies the Page model and shared presentation. A custom domain-record selector and projection remain application work; this recipe does not require or promise Shop, Blog or an automatic catalogue connector. The Capell application itself prepares selected extension records for its marketing cards before Blade renders them; that establishes an integration pattern, not a performance benchmark. Read the page-building guide.
Practical journeys
A locations page needs a map. An article may not.
Choose resources for the widgets in use, then activate them at the declared trigger.
This is a loading explanation, not a running map or a measured speed comparison. Foundation’s Frontend resource graph and the optional Layout Builder selection bridge let a developer declare resources for a selected widget rather than require every page to include them.
Locations page: map selected
- Prepare: resolve the selected widget and its declared resource group before rendering. The application supplies safe location data and text directions.
- Activate: use the declared visible, idle or interaction trigger. Each target keeps its own trigger; shared canonical resources load on the first valid trigger and are deduplicated within the page.
- Reuse: another selected widget using that same canonical resource reuses the load. Its own activation still follows its declared trigger.
Article: no map selected
When no selected widget or other application contribution requires the map resources, that resource group is not selected for this article. Shared site resources may still load. The mechanism does not establish that every existing package declares optimal loading.
What the current Location Map widget does
It renders configured marker labels, addresses and map links as a text fallback. Its activation button creates an OpenStreetMap embed centred on the first marker, unless the privacy integration explicitly denies that provider. It does not provide clustering or geospatial search. Reading the addresses does not require JavaScript.
Location Map is an optional beta, preview-only package in the source release catalogue; Layout Builder is a separate optional package. The application must integrate resource declarations, publication/build output, privacy choices, provider terms and content security policy. A custom map may use the same resource mechanism, but that integration remains developer work. Continue with public rendering.
Practical journeys
Someone searches for parking. Help them reach the answer.
A worked editorial sequence using optional Search, with no automatic repair.
Illustrative query and answer, not a visitor log or an achieved result. Search is optional and preview-only in the source release catalogue; check its current listing for acquisition terms. It is separate from Foundation.
- Missed answer: a visitor searches for “parking” and receives no results. With search logging enabled, a valid site context and a query meeting the configured minimum length, an eligible request can appear in the zero-result report. With privacy signals honoured, Global Privacy Control, Do Not Track and X-Do-Not-Track requests are excluded. The report is partial, not a record of every visitor.
- Editorial decision: review whether the public “Getting here” Page actually answers the parking question. If it does not, add accurate parking guidance and publish it through the configured publishing path. Do not redirect a visitor to an answer that does not exist.
- Manual curation: when the answer exists but terminology differs, an authorised operator can open Search settings, set “getting here” as the synonym term and add “parking” as an alias. A developer can also persist that mapping through the supported synonym action. The zero-result dashboard widget displays queries and counts; it has no curation buttons. Nothing here adds one or changes a synonym automatically.
- Check the answer: ensure the published Page is included in the configured search source and refresh its index where required. Search again for “parking” in the intended site and language. Query expansion can include “getting here”; verify the returned link opens the published answer. If it does not, check indexing, scope, filters and expansion limits before calling the work complete.
The application owns search-source integration, indexing freshness and authorised curation. This sequence makes no claim about reduced enquiries, search success rates or automatic content creation. Check Search and its dependencies in the extension catalogue.
Practical journeys
A public guide stays public. A protected Page needs approval.
An illustrative Page access sequence, not a live registration or file download.
Compare a public preparation guide with a protected specialist guide. For this example, Access Gate uses Authenticated identity, manual approval, an Active area and no opening or closing window. The protected route is explicitly gated, has no matching public allowlist entry and the visitor has no alternative active grant. The approved grant has no future start or expired end.
- Anonymous: the public guide is readable. The protected Page is denied; an HTML request is redirected to the access request route rather than receiving the protected content.
- Signed in, awaiting approval: the public guide remains readable. Signing in or submitting a request alone does not grant this protected Page, so access remains denied.
- Approved: an authorised operator approves the pending registration and an active grant is created. The matching signed-in visitor can read the protected Page. The public guide remains public.
- Access revoked: the operator revokes that grant. On the next protected request it no longer qualifies, so access is denied again, while the public guide remains readable. Revocation cannot remove information the person has already read or saved.
What the developer configures
Access Gate is an optional paid package, stable in maturity but preview-only in the source release catalogue. The host application supplies authentication, area and registration configuration, authorised approval controls and explicit middleware wiring on every protected delivery route. Keep protected responses out of shared public caches and check fragments or alternate delivery paths as well as the main Page.
Paused or Closed areas, timed windows, guest links, hybrid identity and public allowlists have different semantics; this sequence does not describe them. A login screen alone does not protect every Page. Nor does Page gating protect public media URLs or binary downloads, provide billing or create automatic membership. Check Access Gate’s current listing and prerequisites.
Modelling questions?
Do I define content types in code or the admin?
Can one page mix several content shapes?
What happens when I need a new field later?
How does this hold up over years?
Decide what shares a page type, then define it in code.
If your site is built from repeating shapes, the platform overview and developer path show how Capell page types keep those shapes reusable as the site grows.
Reusable models Define a shape once, then change every page of that type together.