Suggest changes: edits from people who cannot edit
Authors can now propose an edit to a page they are not allowed to change. Editors see it beside the current version and apply it, publish it or decline it with a note.
Every content team has the same quiet bottleneck. The person who spots the problem on a page is rarely the person allowed to fix it. A program coordinator sees the wrong deadline on the admissions page, a city clerk notices an outdated meeting room, and the only way to get it changed is an email with a screenshot and a hopeful subject line.
Spillway's roles are deliberately strict. An author edits their own pages and nobody else's, and that is the right default for a site with a review process. It also meant the people closest to the content had no way to help with pages they did not write. As of today they do.
How it works
An author who opens a page they may not edit sees why it is read-only, and a Suggest changes button. They edit the fields as if the page were theirs, including the layout in the page builder, which then saves the suggestion instead of the page. They add a note and send it.
Nothing on the page changes. The suggestion is a separate draft that belongs to its author, and they can keep working on it until an editor picks it up.
Reviewing a suggestion
Editors find suggestions in two places: the Suggested changes panel on the page itself, and a new tab in the review queue. Opening one shows the suggestion beside the current version, field by field, with a warning when the page has moved on since the author started. From there an editor can:
- Apply as draft, to adjust it before it goes live;
- Apply and publish, when it is ready as it is;
- Decline, with a note that tells the author why.
Both sides hear about it. Editors get a notification when a suggestion arrives, and the author gets one when it is applied or declined, in the bell and through any notification channel the site has set up.
Why not just loosen the roles
Because the review process is the point. An editor still decides what goes live, every applied suggestion is a revision with its author on it, and the audit log records who suggested, who applied and who declined. Suggest changes widens who can contribute without widening who can publish.
It is in the open core like the rest of the editorial workflow. The API is /api/entities/:id/suggestions and /api/suggestions, documented in the API reference.