Getting changes live
The short version
- Save your work.
- Submit for review.
- Someone with approval rights approves it.
- Add it to a release.
- Publish the release.
Steps 3 and 5 need admin rights. If you are an editor, your part ends at step 2 — though you can add documents to a release yourself.
Submitting for review
Submit for review on the toolbar marks your draft as ready. It stops being something you are working on and becomes something waiting on someone.
If you save again afterwards, it goes back to being a draft, because a version someone is reviewing should not change while they read it.
An approver can request changes, which sends it back to you with a note.
Releases
A release is a batch of documents published together.
This matters when a change spans pages. Launching a product might touch the product page, the home page, the navigation and a blog post. Publishing those one at a time leaves the site briefly inconsistent, and nobody reviews the change as a whole.
To add the document you are editing: use the release button on the toolbar, pick a release (or name a new one), and press Add to release.
To add several at once: open Releases, open the release, and add candidates from the list.
A release takes a snapshot
A document is added as it is at that moment. If you edit it afterwards, the release still carries the older version until you add it again. The release page shows which snapshot it holds.
Previewing a release
Before publishing, open the release and press Preview release. It opens the site showing that release's content, with everything the release does not touch shown as it is now, so links still work.
This is what an approver should look at. It answers "what will the site look like", which the list of documents does not.
Publishing
Publish on an approved release writes its content to the live site and asks the site to rebuild.
Two checks run first and can refuse:
Link integrity (before approval) — a link points at a page this release does not include and the live site does not have. Publishing would create a broken link. The message names the page holding the link and the field it is in.
Renderability (before publishing) — the live site cannot draw something in this release: a section type it has no design for yet, or a required field left empty. Usually this means a developer's work has not been deployed yet.
Neither can be overridden. If one blocks you, the message says what to fix.
"Published, rebuild not confirmed"
Publishing writes the content, then asks the site to rebuild itself. Those are different events, and the second can fail.
Until the CMS has checked the live site and found your changes there, the release says rebuild not confirmed. This is normal for a minute or two.
If it stays that way, the release lists each route and why:
- Not rendered from the CMS — a developer's deploy has not gone out. Republishing will not help.
- Older content — the site rebuilt too early. Press Retry rebuild.
- No page returned — something is wrong with the build. A developer needs to look.
Undoing a release
Revert on a published release builds a new release containing what the site had before it. You approve and publish that like any other, and the same checks apply — which is what stops a rushed undo from breaking something else.
Sometimes reverting is refused, because going back that far would restore pages using designs the site no longer has. The release page says so.