Introduction
In this post, we’ll look at why Draft Blocks don’t show in Page Preview by default, and I'll show you a clean, drop-in solution to fix that. The result? Editors get a more accurate “what you see is what you’ll publish” experience - no more hidden draft blocks.
Problem: Preview doesn’t show drafts
By default, when you hit Preview in Optimizely CMS 12 (without using Projects), the system behaves like View mode. That means:
ContentAreaRenderer
only treats Edit mode as “editor state”IContentAreaLoader
fetches published versions even in Preview
So draft blocks disappear. That’s confusing to editors.
Note on Projects vs normal Preview
If you’ve ever wondered why drafts sometimes appear in Preview already: Optimizely Projects can preview draft content that’s part of the active project. That’s project-scoped preview. Outside Projects, default Preview behaves more like public view, so unpublished blocks won’t show.
Solution overview
Here’s what we’re going to do:
- Make Preview behave like Edit in the
ContentAreaRenderer
- Replace
IContentAreaLoader
so it loads the latest version (which may be a draft) in Preview/Edit - Hook them into your DI container cleanly - no internal types, no circular dependencies
1) Preview behaves like Edit in renderer
This means the renderer stops skipping draft blocks in Preview - just like it would in Edit.
2) Loader returns latest in Preview
By providing your own IContentAreaLoader
, you can:
- In Preview/Edit: resolve the latest version (draft if available)
- In View: revert to published content
That way, Preview reflects the editor’s current work - not stale published content.
3) Clean DI setup
Register the custom renderer and loader after services.AddCms()
using a factory method:
This avoids trying to resolve internal types or causing DI loops- everything stays simple and robust.
Outcome
- Editors see draft blocks in Preview (even outside Projects)
- Public users still only see published content
- The experience feels consistent and reliable
0 comments :
Post a Comment