System Pages

System Pages let you give visitor-facing error and plugin screens the same layout and Shared Slots as the rest of a site. Find them in Pages, identified by the System badge. The page-type filter separates Content and System records. The System menu continues to hold operational configuration.

1. Select a site in Pages and expand System pages using its chevron-labelled heading. The heading also works with the keyboard.
2. Choose Prepare draft beside a built-in error screen or a screen declared by an enabled plugin.
3. The draft includes native editable starter blocks with translated heading and introductory text. Error designs also provide their normal error copy; the 404 starter includes a homepage Button Link. Open Main → Edit Blocks to change this content.
4. Select its page layout. Use the existing slot controls to attach compatible header, footer, sidebar or other Shared Slots.
5. Add surrounding content and translations, then preview.
6. Publish explicitly when the design is ready. Preparing or saving a draft does not change the public screen.

The editor requires the existing page permissions for the selected site. Shared Slot permissions remain separate. A screen already prepared opens its existing design; repeated preparation never creates duplicates. A design can be archived or deleted to restore the built-in appearance. It has no independent public slug and does not enter search results, automatic page lists or the sitemap. Duplication and moving a system design to another site are unavailable; prepare that site's own design instead. Site imports retain the screen identity but keep imported designs in draft. The existing path-based Site Promotion flow refuses packages containing System Pages; export only ordinary content pages for that flow.

The Settings tab identifies the Screen by its readable name. Expand Technical details only when you need its internal binding identifier. If the plugin definition is unavailable, the screen uses the saved page title.

The initial preparation saves the page, its blocks, translations and first revision together. Open Main → Edit Blocks to find the prepared text already filled in and edit it with the usual block controls. Preview shows the saved blocks and reflects your changes. Reopening a design preserves those changes.

Default blocks are normal Hero, Header, Plain Text or Button Link records with SQL translation rows and typed settings. No JSON template or separate plugin content store owns them. They use the same block editor and API as other pages.

The feature continues to own the form, results and processing. Authored Main blocks appear before the functional content. Required plugin forms and results cannot be removed by deleting blocks or disabling Main. Plugin previews show saved native editorial blocks and a small labelled runtime placeholder without real customer, account, payment or token data. Core error previews show their saved editorial content without a form placeholder. Custom error copy is not followed by an immutable second default message. Shared Slot blocks retain their separate publication workflow. A plugin needs to declare support; the mere presence of a public route does not automatically make it a System Page.

Core provides Page not found (404) and Maintenance (503). Updated Campaigns, Appointments, Memberships and Commerce plugins declare their confirmation, account, cart and payment screens. A single screen design covers all its runtime records.

Publish the page and its content blocks through the normal workflow. The built-in public error screen remains in use until the design has published Main content.

A published 404 design retains the actual 404 response and indexing protection. JSON errors and a host application's own 404 template remain unchanged. If a custom error design cannot render, CMS uses its built-in fallback.

Before a CMS update, the primary site's published 503 design is rendered to saved HTML. The maintenance response can then work without the application or database, retaining HTTP 503 and retry guidance. Laravel's preboot maintenance gate is shared across the installation: other domains use the primary site's prepared maintenance output. It includes the selected layout and Shared Slots, with the CMS search and consent overlays omitted. Without a usable published design, the static built-in maintenance template is used. Preparing a System Page does not itself put the site into maintenance mode.

Search and cookie preferences remain tools on the current page, so they are not System Pages. Old search and preference addresses redirect to the localized homepage and open the appropriate modal. Their JSON/form endpoints remain technical endpoints. See Search and Cookies and Privacy.