Every Drupal team eventually writes editor preview rules: components must show realistic content in preview, view modes must match the front end, editors must never meet a component that looks broken before it is even saved. And almost every team writes them into a wiki page that editors never open, which is why so many launches end with the same discovery — the preview experience quietly contradicts the published site. This article is about making the rules enforceable instead of documented: encoding them into view modes, templates, default content, and the component library so the correct behavior is the only behavior. It assumes the rule definitions from editor preview rules for Drupal components, checks them through the Drupal editor experience launch checklist, and argues they should be born in the Drupal component library planning checklist rather than retrofitted after editors complain.
The core insight is that preview rules fail for a structural reason, not a discipline reason: they describe behavior in one place while the behavior lives in another. Every technique below closes that gap by moving the rule into the place where the work happens. One class of rules deserves special mention up front: anything that affects what editors see when they check their own work against accessibility expectations should anchor to the Drupal accessibility documentation rather than to team habit, because the underlying criteria are shared standards, not project preferences, and encoding a shared standard is far more durable than encoding a preference.
Why Documented Rules Do Not Survive Contact With Editors
The failure pattern is so consistent it deserves a name. A project defines sensible preview rules at kickoff — realistic placeholder content, accurate view modes, no empty components in the library. The build proceeds, deadlines compress, and the rules survive only where they were wired into the system. Where they lived in documentation, they eroded: a component ships with lorem ipsum because the real content examples never got written, a view mode drifts from the template because nothing failed when it did, and an editor meets a preview that looks nothing like the site. Nobody disobeyed the rules; the rules simply had no enforcement surface. This is the argument for encoding: documentation tells people what to do, encoding makes the correct thing the default, and teams under deadline pressure always — always — get the default. The question is never whether the team follows the rules; it is whether the system follows them on the team’s behalf.
Encode Rules In View Modes And Templates
The first encoding surface is structural. View modes are the contract between content and presentation, and they are where the preview rule “what the editor sees matches what visitors see” either holds or breaks. The enforceable version: every component that editors will place gets a defined view mode per context, named after the context rather than the display — teaser, sidebar, full — so intent survives redesigns. Templates then render preview state from the same view modes the front end uses, which closes the classic gap where the preview uses one rendering path and the site another. Where a component genuinely cannot render meaningfully without real data — a map, an embedded feed — the correct encoded behavior is an explicit placeholder designed to say so, not a broken empty box that editors interpret as their own mistake. The test is simple and brutal: if changing a view mode would improve the front end but break the preview, or vice versa, the encoding has failed and the two paths must be reconciled, because divergence is the bug editors will find for you at the worst time.
Encode Content Rules In The Library Itself
The second surface is the component library, which should ship with its own preview discipline built in. Each component entry carries three things: realistic example content that looks like the site’s real material — names, dates, and images of plausible size rather than filler text — at least one edge case rendered honestly, such as a very long title or an empty state, and a note naming the view mode and context the preview represents. This sounds like documentation but is not: the library is the place editors and developers both actually open, which makes it the one location where a rule can live beside the thing it governs. It also changes the economics of example content — written once per component in the library, the realistic content gets copied into every content type, every demo, and every editor training session that follows, repaying its cost many times. Teams that skip this step discover the cost anyway, paid repeatedly as every training session improvises its own examples and every editor forms their own mental model of what a component is for.
The Editor-Experience Debt Argument
Teams routinely budget for technical debt and almost never budget for editor-experience debt, even though the second compounds faster. Every component that previews badly trains editors in a workaround: they stop trusting preview, they publish to check, they develop private superstitions about which fields are safe to touch. These workarounds accumulate invisibly until a new editor joins and inherits a culture of distrust nobody chose. The cost shows up in concrete places — content that never gets updated because updating feels dangerous, layout bugs reported against components that are actually misused, launch retrospectives that blame training for what is really a system that never encoded the rules. Encoding preview rules is cheap at build time and expensive never; deferring them is the reverse. A component library that enforces correct preview from day one compounds in the opposite direction: each new component arrives already trusted, and the training budget shrinks instead of growing. That compounding is the real business case, and it only requires the rules to be born where the components live.
The Friction Checklist Before Go-Live
| Check | What goes in it | Failure it prevents |
|---|---|---|
| View mode parity | Every placed component renders preview from the same view mode the front end uses | Editors previewing something visitors will never see |
| Realistic content | Every component and content type ships with example content that looks real | The lorem ipsum launch that trains editors into distrust |
| Honest edge cases | Empty, long, and missing-data states render as designed placeholders | The broken-looking preview editors file as bugs or work around |
| Library fidelity | Component library entries match the live component and name their context | Training material contradicting the site within a month |
Run the checklist during the launch window, not after it — preview behavior is cheap to fix while templates are still fluid and expensive once editors have built habits around the broken version. A component that survives all four checks rarely generates a preview-related support ticket; one that fails any of them generates tickets for years.
Where The Rules Should Be Born
The deepest fix is upstream: preview rules should be a planning artifact, not a launch repair. When a component is specified during planning, its preview contract belongs in the specification — what context it appears in, which view mode serves that context, what realistic content represents it, and what its empty state says. A component specified with its preview contract is nearly free to implement correctly; a component specified without one gets its preview behavior improvised during theming, which is precisely where the lorem ipsum and the mismatched view modes come from. Teams that make this shift report a qualitative change: editor experience stops being a launch-week firefight and becomes a property the design system simply has, like accessibility or responsive behavior. And the wiki page of rules can finally be retired — not because the rules were abandoned, but because the system learned to keep them without being told.