School website CMS workflow

What this is for

The CMS produces the public school website at /myschool, which anyone can read without signing in. It is a separate audience from the app: nothing published here notifies a parent, and nothing posted to /notices appears on the public site. Use it for the material a prospective family or a search engine should find - about pages, academics, admissions information, blog posts, events, galleries, a staff directory, leadership messages, downloads, FAQs, achievements and testimonials.

Pages and blog posts carry a real editorial workflow, which is worth using rather than working around. Each of them has a workflow status, an author, a reviewer and an optional scheduled publish time, and each write is snapshotted as a content revision. The other collections are simpler published-or-not records. Do the brand and site setup once, then work in the draft-review-publish loop for everything after that.

Prerequisites

1. Set the palette, fonts and logo at /settings/brandbook, because public pages render against that theme.
2. Open /school-website/settings for the site-level Published switch, SEO title and description, navigation, footer links, homepage blocks, social links, popup banner, marquee text, map embed, analytics id and domain.
3. Your account must be assigned to a school. The CMS resolves the school from the user record and fails closed on a multi-school install where the user has none.
4. Create the core pages at /school-website/pages, then fill the supporting collections.
5. Watch /school-website/enquiries, which is where public contact submissions arrive.

Who can do what

The code defines a third rung, author, for a CMS user who can only draft. It is unreachable today because the access gate admits exactly the four roles above, so in practice the split is publisher versus editor. One consequence is genuinely useful: an editor saving an already published page keeps it published and keeps its original publish date, so a Vice Principal can correct a typo on a live page without either republishing it or knocking it offline.

Status model

• An editor asking to publish is refused with 403 and the message that only a publisher can publish CMS content.
• An editor asking to schedule is refused too - a future publish time requires publisher capability.
• Clearing the published flag on a scheduled item drops it back to DRAFT.
• Scheduled content needs no cron. The public queries treat a SCHEDULED row whose publish time has passed as visible, so it appears on the next public request. This is different from /notices, where scheduled publishing depends on the daily cron job.

The SEO gate that blocks publishing

Every page and blog write is checked before it is saved, and the strictness depends on the outcome. A missing title is always an error. Once the write would result in published content, every remaining warning except missing image alt text becomes blocking, and the request is rejected with 422 and the list of failing checks. In practice that means you cannot publish without an SEO description of 50 to 160 characters and a cover image, and the SEO title should stay under 60 characters. Drafts are held to the lower bar, so the honest sequence is to draft freely and finish the metadata before asking a publisher to release it.

Preview and the site switch

• The whole public site has one Published switch at /school-website/settings. While it is off, /myschool renders nothing for the public no matter how much content is published.
• Staff with CMS access can preview with ?preview=1 on a /myschool page, blog post or gallery, which bypasses the visibility rules and also works while the site switch is off.
• Gallery albums have no workflow status or scheduled time, so they are published or not. Public staff profiles need both the published flag and show on directory.

What breaks if you skip or misorder a step

• Content marked published while the site switch is off is invisible to everyone but staff using preview - the usual cause of "we published but nothing shows".
• Publishing is refused with 422 rather than a validation hint in the form when SEO metadata is incomplete, so read the returned checks.
• Scheduling before writing the metadata means the release fails at publish time expectations rather than at scheduling time; finish SEO fields first.
• A custom page whose slug matches a built-in section such as about, academics, admissions, staff or gallery will never render: those paths are served by their own dedicated routes, and the catch-all refuses them. Slugs must also be unique within the school, which is reported as a duplicate slug error.
• Publishing something that should have been private is a public change with immediate effect - there is no approval queue between publisher and live.

Handoff and limits

• The public site is the boundary. It feeds the sitemap and public metadata, and it feeds the enquiry inbox back into the school. It never touches app accounts, and it sends no notification.
• Announcements for signed-in families belong in /notices, which has its own audience targeting and email fan-out. Duplicate deliberately if you want both.
• Every page and blog write records a revision snapshot of title, slug and workflow status. There is no restore-from-revision interface; the trail exists for audit, not rollback.
• The pages and blog editors expose a Published switch and a publish time. IN_REVIEW and SCHEDULED are enforced by the API rather than surfaced as buttons, so a review-then-schedule flow is currently driven through the API.
• There is no per-field review, no comment thread on a draft, and no per-user page ownership beyond the recorded author.