forge-cms

Forge playbook — CMS (WordPress · headless)

A CMS is a content-model + editor-safety + migration domain sitting on top of a live database and uploads. The rendered front-end defers to forge-website (real content, responsive, a11y, SEO, performance); the API/secret/webhook plumbing defers to forge-integration; this file governs the content model, the CMS-specific attack surface, and migration/backup safety. The single most important rule is back up before you change anything — CMS mistakes hit live content and are often irreversible without a backup. Honest limit: Forge cannot run a live WordPress/MySQL install or take a real DB/uploads backup unless the environment provides PHP + MySQL + WP-CLI (opt-in, owner-side) — mark those steps not-run when the runtime is absent.

Hard rules (non-negotiable)

• Content model first. Define post types / fields / taxonomies (WordPress custom post types + ACF/meta) or the headless schema (Contentful/Sanity/Strapi/Payload content types) before templating. Editors must be able to change content without touching code — no business copy hardcoded in the theme.
• No secrets in the theme or repo. DB credentials, salts, API tokens, and SMTP creds live in env / wp-config.php (via env constants), never committed. wp-config.php with real values is never in git; headless API tokens are server-side only.
• WordPress output/input safety. Escape on output (esc_html / esc_attr / esc_url / wp_kses), sanitize on input (sanitize_text_field etc.), and use $wpdb->prepare for every query — WP is a large XSS/SQLi surface. Nonces (wp_verify_nonce) + capability checks (current_user_can) on every state-changing action. Never edit WordPress core; extend via a child theme and properly enqueued scripts/styles (wp_enqueue_*). Vet third-party plugins (source, active maintenance, known CVEs) and pin versions.
• Headless token + webhook hygiene. Read/write API tokens stay server-side and are never shipped to the browser; preview/draft tokens are scoped and short-lived; CORS is locked to known origins; CMS→build webhooks verify their signature before triggering a rebuild (defer to forge-integration).
• Backup before change; reversible, staged migrations. Take a full DB + uploads backup before any plugin/theme/core update or content migration. Migrations run on staging first and are reversible. Serialized data (WP wp_options, meta) must be changed with a serialization-safe tool — wp search-replace (WP-CLI), never a raw SQL find/replace, which corrupts serialized PHP and silently breaks the site.
• Keep it patched; least privilege. Core, themes, and plugins stay on security-patched versions; user roles follow least privilege (no gratuitous Administrators).
• Performance + accessibility are gates, not extras. Page/object caching, image optimization, minimal plugin bloat, lazy-loading; and a11y on rendered output (semantic markup, alt text, heading order, contrast) — the CMS must emit accessible, fast HTML.