Check a change before you publish it

Follow the guided editor demo Plan installation with your developer

Editors work in Filament, Laravel's admin framework, with clear screens for the content they manage.

The frustrating part of editing is rarely the writing. It is finding the right place, guessing what a field controls, waiting for a preview, or asking a developer to fix a small mistake.

Each kind of page has a clear shape, with design decisions kept outside the content form. Editors can move from change to checked result without being handed a blank canvas.

Clear page fields Preview before publish Recoverable page history

Actual Capell Layout Builder showing Main and Sidebar containers, assigned widgets, responsive preview controls, and selected container settings. — CMS capture · Layout Builder **Editors compose approved widgets inside named layout areas.** A real Layout Builder capture showing the visual canvas, its container tree, assigned widgets, responsive preview controls, and selected container settings.

Publishing Studio Workspaces screen with the Approve dialog open and its logged approval notes field. — Publishing Studio: review **Move the draft through review.** Reviewers approve, request changes or reject in the actual CMS interface, and approval notes are logged.

Publishing Studio content scheduler listing the scheduled publish, embargo, unpublish and review reminder for an approved workspace. — Publishing Studio: publish **Publish the approved version.** Approved work publishes now or at a scheduled time, and the scheduler shows what goes live and when.

Make the change you came to make

Find the right page, check the result and correct mistakes without waiting for a rebuild.

Your CMS should help you update a page confidently, not make you understand its implementation. Capell gives editors clear fields in Filament, preview and Page history. The exact fields and publishing permissions depend on the site your team configures; the workflow below shows what to look for.

On this page

Check before publishing
Understand the page and the change before it becomes public.
Correct without hiding history
Use Page history to understand and recover a mistake.
Make the change. Check it. Put it back.
Routine content work gets a clear finish line, while design and code changes still go to the development team.
Edit, preview and recover pages
Follow the standard page workflow, then add team approvals and scheduled releases only when the process needs them.
Answer questions before publish
Check what can change, what can be previewed, what can be restored, and when a team approval step is available.

Editors can compare saved page states before choosing what to recover.

An editor's day is made of small, important changes: correct a product detail, replace an image, prepare a campaign page, check a link, schedule a release, and fix something that slipped through. Those jobs should have a clear beginning and end.

Different kinds of pages get different shapes. An article can ask for article content; a product page can ask for product details; a flexible campaign can be assembled from page components the team has already approved. Editors do not have to work out which design controls are safe each time.

A publishing path you can explain

Find the page and change fields that match the work.
Preview the result in context before it is public.
Publish through the process chosen for the site's risk.
Compare saved page versions and validate a restoration when needed.

Every Capell site includes drafts, preview, Page History, and validated page restore. The licensed Publishing Studio adds assignments, comments, approvals, scheduling, and coordinated releases. Page History applies to pages; design, accessibility, and code changes still belong with the development team.

The public demo is read-only: editors can open an article, understand its fields, preview it, and inspect Page History and restore validation, but cannot save or restore demo content.

Review before publishing

Understand the page and the change before it becomes public.

Start with the page's purpose and public address, then update the fields intended for the task. Preview the result in context: a new headline can affect wrapping, and a replacement image can change the crop. Follow the action if the page asks readers to enquire or register.

Know whether you can publish directly or need review. Publishing Studio adds a formal review process where installed; a draft or preview alone does not mean the change has been approved. Ask for a clear escalation route when a field is missing or behaviour needs development.

Correct without hiding history

Use Page history to understand and recover a mistake.

When an offer or paragraph is wrong, inspect the earlier Page version and compare the difference. Recovery should be a deliberate choice of the intended content, not an attempt to undo everything that happened on the website.

Foundation provides Page history and validated recovery. The site's permissions determine who can use it. Check the public page after correction and ask the maintenance owner to investigate if caching or an integration prevents the intended result reaching visitors.

Make the change. Check it. Put it back.

The admin is designed around recognisable tasks: find, update, preview, publish, compare, and correct. The exact fields and components depend on the site, so editors get useful freedom within agreed design rules.

Open the right page quickly Pages, media, links, and reusable content have named places, so an update does not begin with a search through code or old tickets. See the full editor path Change fields that explain themselves An article, product page, and campaign can each ask for the content that belongs there, without exposing the site's design controls. See the Filament workspace Build with approved page components Flexible pages can use sections the site team has already designed, so campaigns can move without inventing a new layout each time. See page-building choices Check the page before visitors see it Preview lets editors check content in context before publication, using the preview rules configured for the site. Open the publishing path Compare and restore a page version Page History keeps saved versions so an editor can inspect a change, validate a restoration, and move backwards or forwards without deleting the trail. See Page History Add approvals when the team needs them Publishing Studio can add assignments, comments, approvals, scheduling, and coordinated releases. Those controls are optional rather than part of every editing flow. See team publishing

Edit, preview and recover pages

Find the page, change clear fields, preview the result, publish, compare saved versions, and restore when needed. Publishing Studio adds assignments, comments, approvals, scheduling, and coordinated releases for larger teams.

Capability	Outcome	Source	Maturity
Reusable page structure	Edit pages in one consistent admin, without changing how the site looks.	Foundation	Released
Page history and recovery	Compare revisions, roll back, and roll forward from standard Page History.	Foundation	Released
Team publishing workflow	Move drafts through assignments, comments, approvals, scheduling, and release.	Optional package	Released
Referral reporting	See which external sources bring visits to your Capell site using aggregate referral counts.	Optional package	Beta
AI and agent delivery	Track reviewed assistance that keeps editorial decisions explicit.	Roadmap	Labs
Automation and integrations	Track auditable automation that connects content operations to the wider application.	Roadmap	Labs
Experimentation and growth	Track approved campaign and experiment workflows around reusable content.	Roadmap	Labs
Trust, compliance, and operations	Track operational trust and governance capability for long-lived applications.	Roadmap	Labs
Customer self-service	Track managed knowledge and service content alongside the customer experience.	Roadmap	Labs

Reusable page structure

Outcome: Edit pages in one consistent admin, without changing how the site looks.
Source: Foundation
Maturity: Released

View evidence

Page history and recovery

Outcome: Compare revisions, roll back, and roll forward from standard Page History.
Source: Foundation
Maturity: Released

View evidence

Team publishing workflow

Outcome: Move drafts through assignments, comments, approvals, scheduling, and release.
Source: Optional package
Maturity: Released

View evidence

Referral reporting

Outcome: See which external sources bring visits to your Capell site using aggregate referral counts.
Source: Optional package
Maturity: Beta

View evidence

AI and agent delivery

Outcome: Track reviewed assistance that keeps editorial decisions explicit.
Source: Roadmap
Maturity: Labs

View evidence

Automation and integrations

Outcome: Track auditable automation that connects content operations to the wider application.
Source: Roadmap
Maturity: Labs

View evidence

Experimentation and growth

Outcome: Track approved campaign and experiment workflows around reusable content.
Source: Roadmap
Maturity: Labs

View evidence

Trust, compliance, and operations

Outcome: Track operational trust and governance capability for long-lived applications.
Source: Roadmap
Maturity: Labs

View evidence

Customer self-service

Outcome: Track managed knowledge and service content alongside the customer experience.
Source: Roadmap
Maturity: Labs

View evidence

Role scenarios

What to inspect in editorial workflows

Prompts for testing everyday editing, preview, recovery, approval, and escalation.

Role-based checks drawn from product capabilities and fit boundaries.

Actual Capell page editing form for the editorial workflow described.

Test editing and anonymous output

Change a field on the live page while authenticated, then request the page anonymously. The edit should persist through the normal content model while the public response contains ordinary HTML and no authoring controls.

Editors can inspect a change in a real preview before it ships, and the readiness check must hold a publish with a broken link or missing alt text. Deliberately trigger both failures and confirm that neither reaches the public site.

Decision note: Some design and structure decisions still sit with developers, on purpose. If teams expect to freely redesign every page themselves, this shared structure will feel like a fence, not a floor.

Run this yourself in the demo

Laravel developer representing this editorial scenario.

Test Role Editors with a Laravel technical lead

Expose approved fields and widgets to editors, then attempt a valid content change and an invalid structural one. The first should publish as clean HTML; the second should stop at the developer-owned boundary.

Expected evidence: Authenticated editors can change approved fields on the live page, while visitors and caches receive plain HTML with no editing markup. Attempt a structural edit outside the signed contract and confirm that the developer-owned frontend boundary holds.

Choose a lighter option when: Full no-code freedom suits a team with no developer-owned design to protect. If there is no structure worth defending, the boundary this gives is effort spent guarding nothing.

Run this yourself in the demo

Agency team member representing this editorial scenario.

Role Editors: an agency director acceptance check

Hand a client a page with preview and readiness controls, then have them change copy and attempt publication with a broken link. The valid edit should stay self-service while the unsafe publish is held.

Verify in the product: Previews and a publish-readiness gate let them work with confidence, and a publish can be held when alt text is missing or a link is broken before it ever goes live. Agency teams hand over a capable client, not a support burden eating the job's margin.

Trade-off to assess: Clients who would rather never touch the CMS are better on a retainer where agency teams make the changes. This pays off when they want to self-serve, not when they want agency teams to do everything anyway.

Run this yourself in the demo

Questions

Prepare answers before publishing

Do I need to install anything before I start?

No. If your developer or administrator has installed the site, you need a login and its address. Installation, assets, queues and hosting stay with them; ask them for access if Pages does not appear. Choose the editor start

How do I know what each field changes?

Each page type can present only the fields that belong to that kind of page, with labels and validation set by the site team. See the editing workspace

Can I see the page before I publish?

Yes. Preview lets you check the result in context before making the change public; the site team configures which route, language, and surrounding page state it uses. Walk through preview

What can I restore after a mistake?

Page History lets you compare, preview, and restore saved page versions. It covers pages; other records may have different recovery rules. The Recovery Center is not the way to undo a page change: it covers Migration Assistant imports and needs that optional package. If the page is saved but visitors still see old content, that is a publishing or cache question for your administrator. See Page History

Can several people approve one release?

Publishing Studio adds assignments, comments, approvals, scheduling, and coordinated releases when the team needs more than the standard page workflow. See team approvals

Check a change before you publish it

Make the change you came to make

A publishing path you can explain

Review before publishing

Correct without hiding history

Make the change. Check it. Put it back.

Edit, preview and recover pages

What to inspect in editorial workflows

Prepare answers before publishing

Navigation

How it works

Why Capell

Extensions

View all 82 extensions

Our 6 most popular extensions

Extension suites