Editorial Workflow

Pages use four workflow statuses:

• draft
• in_review
• published
• archived

New pages start as draft.

• working content
• not public
• editors can edit content in this state

• ready for review
• not public
• editors cannot keep editing page content until the page is moved back to draft

• public
• routable on the public site
• page visibility still works together with block-level visibility rules inside the page

• retired from live use
• not public
• can be moved back to draft or published again by an allowed role

Allowed actions:

• draft -> in_review
• in_review -> draft
• published -> draft
• archived -> draft

Not allowed:

• publishing
• archiving

Allowed actions for assigned sites:

• draft -> in_review
• draft -> published
• in_review -> draft
• in_review -> published
• in_review -> archived
• published -> draft
• published -> archived
• archived -> draft
• archived -> published

super_admin follows the same workflow abilities as site_admin, but across the whole install.

Only pages with status published are public.

• draft pages return 404
• in_review pages return 404
• archived pages return 404

This applies across normal public routes, multisite routing, and localized routes.

Page workflow status and block status are separate. The normal Edit Page -> Overview Publish action publishes the page record only. It does not silently publish draft or in-review blocks inside the page. If a page has unpublished page-owned blocks, the publish action opens a modal with an unchecked Also publish all unpublished page-owned blocks option. Leaving it unchecked preserves the page-only behavior; checking it publishes eligible page-owned blocks in the same workflow action.

The Overview tab also shows an Unpublished page content helper when page-owned blocks are still draft or in review. Publish page-owned blocks publishes only those page-owned blocks and does not change the page workflow status.

Shared Slot content is excluded from these page-owned block publishing workflows. Shared Slot-backed header, footer, or other slots must be reviewed and published separately; WebBlocks CMS does not cascade page publishing into Shared Slot block trees.

Workflow state also affects who can keep editing page content.

• editors can edit page content only while the page is in draft
• once a page leaves draft, content editing requires a site_admin or super_admin, or a workflow move back to draft
• site_admin and super_admin users can continue working across workflow states they are allowed to manage

1. editor creates a page in draft
2. editor finishes content and submits it for review
3. site admin or super admin reviews the page
4. site admin or super admin publishes the page
5. later updates can move the page back to draft, then through review again

Internal operator workflows can prepare updates for a published page without moving the source page back to draft. The staged update workflow creates a separate draft staging page linked to the published source page. The published source page stays public at its existing path while the staged page can be previewed through /webadmin/pages/{page}/preview.

Promotion is explicit. When a staged update is promoted, WebBlocks CMS copies approved page-owned slot content back to the published source page, writes promoted page-owned blocks as published, preserves the source page path and status, and leaves Shared Slot-backed slots out of scope. After recording the source page's pre/post-promote safety versions, it deletes the technical staged page in the same transaction. An abandoned active staged draft can be discarded through its dedicated Internal Content API action without granting broad page-delete authority.

On an existing draft or staged page, choose Open preview panel in page settings or a supported page-owned block form, then Refresh preview. The panel uses the normal page renderer with the open form’s supported unsaved values and the rest of the saved draft. Other open forms are not included. Refresh does not save content, create a version or promote a staged update; recovery checkpoints still work independently. For a published page, prepare a staged update first.

Choose an enabled content language and Desktop (1024 px) or Phone (390 px). Changing the language requires another refresh. The form’s editing language stays unchanged: unsaved Turkish text, for example, does not become English text merely because the preview selector changes. A missing page translation produces an explicit error; existing block translation fallbacks remain unchanged.

Changes pending means the displayed result may be out of date. The last successful render time stays visible after an error. Validation, unavailable sources, lost connections and expired access keep your form values. Correct the problem and refresh again; do not reload an unfinished form just to retry. Dynamic Content uses the configured mappings, filters, sorting and pagination, including empty/error behavior. Typing and opening the panel do not query sources.

The private panel isolates rendered content from the editor. Links, authored scripts, embedded frames and form submissions are disabled; native collection pagination remains available. Gallery and inline child-builder forms, plugins, Embedded Applications, new blocks, file uploads and changes to block type, slot, parent, order or status require saving first. Unsupported operations are explained in the form. Saved preview in new tab remains available, including on narrow screens, and shows only saved values. Keep explicit Save and publication as separate actions.

On existing draft and staged pages, page settings and page-owned block forms protect unfinished values in recovery checkpoints. This includes localized Rich Text formatting and selected media references. Wait for Recovery checkpoint confirmed before relying on recovery. Pending or failed confirmation means the latest typing may not be protected; keep the tab open or save normally.

After a reload or interrupted session, return to the editor in the same tab and sign in as the same user if necessary. Choose Restore form values, Discard checkpoint, or Continue with saved content. Restore fills the form so you can review and explicitly Save. Continue keeps the earlier checkpoint and pauses protection of new edits until you restore or discard it. Discard removes the applicable checkpoint without changing saved content.

If the saved page changed elsewhere, review the current saved content and confirm that review before restoring. Save checks for later conflicts again. Current site access, role permissions, account activity, content locale and workflow are checked throughout recovery. Different users, forms, locales and editing sessions keep separate checkpoints.

Recovery does not create a revision or publish content. It covers existing draft and staged pages; prepare a staged update before editing a published page. Shared Slot editing, new unsaved pages, file uploads and credential fields remain outside recovery. A modern browser with tab isolation support is required; unsupported or unavailable recovery is shown explicitly.

Checkpoints are limited to 256 KiB and 512 form controls, with up to 32 unfinished editing sessions per user. They expire seven days after their last update. Successful Save and explicit discard clear the matching checkpoint; failed saves retain it. The scheduler prunes expired checkpoints daily. Operators can also run php artisan webblocks:editor-recovery:prune to remove expired checkpoints.