General Settings

The General Settings global is a single general-settings global that hosts tabs for editor-facing project settings. The Pages tab is always present and carries the optional Homepage picker (see Pages tab). The Troubleshoot tab is also always present, kept last, and carries self-service maintenance actions like the site-wide cache refresh (see Troubleshoot tab). Additional tabs appear only when their gating option is on: SEO unless the seo plugin option is disabled — site-wide title templating, meta-description, and share-image defaults (see SEO tab), Posts when the Posts module is enabled — permalink pattern and sitewide display toggles, Emails when an email adapter is configured and emails: is set in plugin options (see Emails), Cookie Consent when generalSettings.cookieConsent.enabled is true (see Cookie consent).

Enlarge screenshot

Pages tabLink to this section

The Pages tab is the first, always-present tab in the general-settings global. It currently carries one field:

Homepage resolutionLink to this section

When a homepage is configured, visiting / renders the picked page directly — no redirect, no extra round-trip. The picked page's own URL (e.g. /home) issues a 308 permanent redirect to /, so canonical links stay clean. The redirect is skipped in draft mode (after /sys/preview) so editors can preview the page at its own URL before publishing.

In draft mode / renders the picked page's newest version, including unpublished and autosaved changes, as long as the page is not trashed or deleted. For visitors, if the homepage field is empty or the picked Page has been unpublished, trashed, or deleted, Systhema falls back to the Page whose slug is '' (the classic "empty-slug homepage"). If that lookup also yields nothing, the route returns a 404. The picker retains the dangling relationship reference — it is not auto-cleared, so re-publishing the page restores the configured homepage without any admin action.

Link rewritesLink to this section

Every Page-relation href resolved through Systhema automatically maps to / when the target is the configured homepage — no 308 round-trip on navigation. This rewrite happens transparently in:

• Block renderers — Button, Chip, Card, Columns, Media, and Icon blocks.
• Lexical inline links and block link references inside the rich-text pipeline.
• Sitemap entries (the homepage entry uses '/' as its canonical URL).
• Form-submission redirects that target the homepage page.

Under the hood, every Page-relation-to-href conversion goes through a single internal helper that knows about the configured homepage. Consumers don't need to call it directly — block renderers, lexical converters, the sitemap generator, and the form-submission redirect handler all use it automatically.

CapabilityLink to this section

global.general-settings.pages.update — registered always when the generalSettings global is enabled. Inherited by admin via global.*. Editors do not receive it by default.

To grant a custom role access to this tab:

roles: {
  custom: [
    {
      slug: 'siteManager',
      label: 'Site Manager',
      capabilities: ['global.general-settings.pages.update'],
    },
  ],
}

SEO tabLink to this section

Site-wide SEO defaults live in the SEO tab; see SEO settings.

Posts tabLink to this section

With the Posts module on, a Posts tab holds the permalink pattern and the display, share and related-posts settings; see Posts module.

Emails tabLink to this section

With an email adapter and the emails option configured, an Emails tab holds the sender defaults; see Emails.

Cookie Consent tabLink to this section

With cookie consent enabled, a Cookie Consent tab holds the banner copy and categories; see Editing consent in Payload.

Troubleshoot tabLink to this section

The Troubleshoot tab is an always-present, data-free tab in the general-settings global. It hosts self-service maintenance actions for editors — nothing on it is persisted, so saving the global with this tab open never triggers revalidation by itself.

Its first (and currently only) action is Revalidate all pages: a click-to-confirm button for the "published changes aren't showing up on the live site" situation. It POSTs to a custom endpoint on the global:

POST /api/globals/general-settings/revalidate-site

The handler revalidates every published Page's own path (plus / when a homepage is configured) — the exact same mechanism as the machine-facing POST /sys/revalidate route with { paths: '*' }, sharing one internal revalidateAllPublishedPages helper so the two can't drift. The only difference is auth: the Troubleshoot button runs on a logged-in admin session, while /sys/revalidate uses the SYSTHEMA_API_SECRET bearer token for scripts and cron. On success the button reports how many pages were cleared; each rebuilds with fresh content on its next visit (that first visit may be slightly slower).

The endpoint requires an authenticated user holding global.general-settings.update or global.general-settings.troubleshoot.update. A Pages-, SEO- or Emails-only update capability does not authorize this site-wide action. By default that means dev (via *) and admin (via global.*); editors don't receive it. To grant it to a custom role, add global.general-settings.read + global.general-settings.troubleshoot.update.

Enlarge screenshot

The manual action refreshes Next.js caches. Check the Cloudflare integration separately when a CDN is enabled.

Stored data and revalidationLink to this section

Named tabs store groups under pages, posts, seo, emails and cookieConsent. The Troubleshoot tab holds UI actions only. The global has no drafts configuration. Changes to Pages, Posts, SEO or Cookie Consent invalidate the layout cache; emails-only changes do not. Page-affecting saves also invoke the configured Cloudflare automatic purge.

Reading the global requires a global or relevant tab capability. Field-level read and update guards protect the stored fields under each tab; hiding a tab is not the access-control boundary.