Drupal view modes look like a theming detail until they start carrying editorial workflow, accessibility expectations, and cache behavior. Planning them before template work begins keeps the theme from becoming a collection of one-off exceptions.
The goal is not to create a view mode for every possible display. The goal is to decide which displays have different content needs, different editorial expectations, or different front-end behavior that deserves a named contract.
Map Each Display To A Real Editorial Use Case
Start with the places where the content actually appears: full article, teaser card, search result, related item, landing page feature, RSS output, and any embedded component. For each placement, write down who edits it, what fields are visible, and what problem the display is solving.
| Placement | Fields that must appear | Planning question |
|---|---|---|
| Teaser card | Title, summary, image, date or category | Can editors preview exactly what will show in lists? |
| Full content | Body, media, author, taxonomy, related links | Which fields are content and which are layout decoration? |
| Search result | Title, excerpt, type, updated date | Will hidden fields create confusing search snippets? |
| Featured block | Short title, image crop, call to action | Is this a view mode or a separate curated component? |
Drupal View Mode Planning Before Theming Starts: Decision Evidence Table
A view mode is strongest when it describes content structure, not a temporary visual preference. Field visibility, image style selection, formatter choice, and link behavior usually belong in configuration. Spacing tweaks, animation, and breakpoint-specific layout decisions usually belong in the theme or component layer.
Document the boundary before development starts. That prevents a common pattern where a field formatter is used to solve a design problem today, then blocks reuse when the same content needs a different layout later.
Include Accessibility And Preview Checks
View mode planning should include heading order, alternative text expectations, link text, focus order for interactive elements, and the editor preview path. A teaser that looks fine in isolation may still create repeated links, missing context, or confusing heading levels inside a listing page.
Drupal.org documents the core idea of display modes in its display modes guide. Treat that as the platform baseline, then add project-specific accessibility and editorial acceptance checks.
Name Cache And Performance Assumptions Early
Different view modes can introduce different image derivatives, lazy-loading behavior, rendered entity cache entries, and template suggestions. Before theming starts, identify which modes appear on high-traffic listing pages and which modes include personalized or frequently changing fields.
- Confirm image styles for each mode before templates are built.
- Avoid adding expensive computed fields to repeated teaser displays.
- Check whether taxonomy, author, or date changes must invalidate listings.
- Keep template suggestions predictable so later developers can find the active layer.
Give The Theme A Stable Contract
A theme team needs a stable list of view modes, field availability, expected empty states, and example content. Provide real sample nodes for each mode, including long titles, missing images, multiple taxonomy terms, and translated content if the site supports it.
The planning document does not need to be elaborate. A compact matrix of view mode, placement, required fields, optional fields, owner, and acceptance checks is enough to keep theming decisions grounded. When the matrix changes, the team can see whether the change is content modeling, editorial workflow, or front-end presentation work.
Run The Plan Against Messy Sample Content
The easiest way to catch a weak view mode plan is to test it with content that is slightly inconvenient. Use one long title, one missing image, one node with three taxonomy terms, one translated node if the site is multilingual, and one older node created before the current content model was cleaned up.
That sample set quickly shows whether the theme is carrying assumptions that belong in the content model. If the teaser breaks when an image is missing, the decision may be an image requirement or a fallback style. If the full view depends on editors writing summaries in a particular rhythm, the decision may belong in editorial guidance rather than Twig.
A weak handoff says, “the teaser needs to match the design.” A stronger handoff says, “the teaser view mode exposes title, summary, 16:9 image style, content type, and one taxonomy label; if the image is missing, show the type label first and preserve the card height.” That gives the theme a contract it can actually implement.
Link View Modes To The Wider Build Plan
View mode work should sit beside component and accessibility planning. Drupal Pixels has a related Drupal component library planning checklist for teams that need to decide when a display mode should become a reusable component instead of another template exception.
The practical next step is to make a one-page matrix before theming starts. List each view mode, where it appears, which fields are required, which empty states are allowed, who owns acceptance, and which examples must pass review. When that matrix is approved, theming can move faster because the hidden editorial decisions have already been named.
Do not treat the matrix as permanent architecture. Treat it as the current agreement. If editors discover that a display needs a different summary, image crop, or link rule, the matrix shows whether the change affects configuration, content modeling, component behavior, or only CSS.