Draft and published versions in Sulu: keeping edits off the live site

The publish button did not change the live page

You open a Sulu page, fix a headline, and click save. You reload the public website and the old text is still there. This is not a bug: Sulu treats saved edits as drafts by default, and the public site only shows the last published version. Until you understand where those versions live and how to promote one, it is easy to confuse "saved" with "live."

The useful takeaway is that Sulu stores each page in a PHPCR content repository—PHP Content Repository, a tree-structured storage system—and tracks changes as versioned nodes. Drafts and published versions can exist side by side for the same URL, so publishing is a deliberate promotion step, not an automatic side effect of saving.

How Sulu separates drafts from published content

When an editor saves a page without publishing, Sulu writes a new version to the repository but does not mark it as the published state. The public renderer continues to serve the most recent published version. The admin shows both states: a draft indicator for unpublished changes and a version history tab listing earlier revisions.

Versioning is configured per content type through Sulu's content type definitions and the persistence layer, not through a separate plugin. Behavior differs between Sulu 1.x and 2.x, so verify the installed major version before relying on specific admin labels or API endpoints.

Worked example: correct a typo without taking the page down

1. Open the page in the Sulu admin and edit the field.
2. Choose Save draft instead of Publish. The admin should show a draft badge, and the public URL should remain unchanged.
3. Open the version history tab for the page. A new version entry should appear for the draft save.
4. Preview the draft from the admin if your installation supports preview endpoints, then confirm the public site still shows the previous published text.
5. When ready, select Publish. Sulu creates a new published version while retaining the prior one.
6. Clear the application cache if the public site still shows stale content. From the project root, run a command such as php bin/console cache:clear --env=prod (path varies by Sulu version and installation). Run this as a user with write access to the cache directory, typically the web server user or deployment user. Expected result: no errors and regenerated cache files. Risk: the first request after clearing may be slower while caches rebuild.
7. Reload the public page in a private browser window and confirm the corrected text appears.

Trade-offs: repository growth, cache, and preview exposure

Every publish retains the previous version, which supports rollback through the version history tab but increases repository size over time. PHPCR growth can enlarge backups and slow reindexing, so plan a retention or cleanup policy if you publish frequently.

Cache invalidation is explicit. Because draft and published versions coexist, changing a published version does not always clear frontend or HTTP caches automatically. Verify that your cache warmup and clear routine covers published content URLs.

Drafts are not publicly visible by default, but misconfigured permissions or publicly reachable preview endpoints can expose unpublished data. Review preview route access controls before enabling preview for editors.

Verify before you rely on it

• In the admin, edit a page field, save as draft, and confirm a new entry appears in the version history tab.
• Publish the page, clear cache, and load the public URL in a private window to confirm the latest published version is served.
• Open the same URL while logged out or in incognito and confirm draft-only changes remain hidden.
• Check content type configuration files against the release notes for your installed Sulu minor version.

Bottom line

Sulu's versioning gives you a safety net for editorial mistakes, but only if you treat save and publish as separate actions. Save drafts for work in progress, publish to promote a version, clear cache when the public site lags, and monitor repository growth if your team publishes often.