A Drupal newsroom site fails in the editorial workflow, not in the theme. Reporters file fast, editors correct publicly, and traffic spikes arrive without warning. Planning the newsroom as a set of content types, moderation states, and permissions before theming starts is what keeps the build cheap to change later. This guide walks through the planning worksheet Drupal Pixels uses with news and magazine teams before a single template is styled.
The goal is not a perfect diagram. The goal is that every editorial action a real newsroom takes — filing on deadline, correcting a mistake, adding a photo gallery to a running story — maps to a content type field, a moderation transition, or a permission that the team named in advance.
Start With The Publishing Scenarios, Not The Content Types
List the six to ten stories the newsroom actually publishes in a month: the breaking alert, the enterprise feature, the live blog during an event, the photo essay, the correction, the aggregated wire piece. Each scenario becomes a content type or a variation on one. A breaking alert needs a short body field, an alert label, and a publish-now permission for senior editors. A live blog needs child update nodes and a reverse-chronological view. A correction needs a field that links it to the original story and a checkbox that appends the correction notice to the original page.
Teams that skip this step end up with one generic “article” type stretched into every shape, and every stretch becomes a field that confuses editors and breaks view modes.
Content Types Worth Planning Separately
- Standard article: body, summary, lead image, section taxonomy, author and co-author references, scheduled publish time.
- Breaking alert: short body, severity label, sticky-until timestamp, and a permission that lets only the duty editor publish without review.
- Live updates page: parent page plus update items, auto-refresh-friendly markup, and a “last updated” timestamp visible to readers.
- Correction: reference field to the original article, the corrected claim, and a reason note for the public record.
- Photo or media story: gallery paragraph type, credit and license fields, alt-text enforcement before publication.
Moderation States And Who Can Move Them
Newsroom moderation is a permission design problem. A workable default is five states: Draft, In review, Scheduled, Published, and Corrected. Reporters move Draft to In review. Section editors move In review to Scheduled or Published. Only the duty editor role can move straight from Draft to Published for a breaking alert. The Corrected state exists so a correction never silently edits history: the original text stays, the correction displays inline and in the page header, and the RSS and sitemap entries update their timestamps honestly.
Write these transitions down before the build. When they are discovered during content entry, they get implemented as admin workarounds that survive for years.
Drupal Newsroom Planning Tool Build Readiness Worksheet
This worksheet is the artifact Drupal Pixels fills with the team before theming. Each row is a promise the build must keep; a row that cannot name its proof stays open until it can.
| Scenario | Content type | Moderation path | Permission holder | Proof it works before launch |
|---|---|---|---|---|
| Breaking alert on deadline | Breaking alert | Draft to Published, skipping review | Duty editor role only | Duty editor files and publishes an alert in under three minutes on a staging copy |
| Enterprise feature with art | Standard article | Draft, In review, Scheduled | Section editor | Editor schedules publication and the scheduled queue renders it with correct byline and lead image |
| Correction to a live story | Correction | In review to Published | Copy desk | Correction appears inline on the original story and in the corrections feed |
| Live event coverage | Live updates page | Draft to Published, child updates flow freely | Assigned reporter | Twenty updates publish without layout breakage and the reader sees the newest first |
| Wire aggregation | Standard article with source field | In review to Scheduled | Section editor | Source link and wire credit display and survive syndication to the homepage view |
Fields, View Modes, And Cache Behavior For News Traffic
News traffic is spiky, so cache design belongs in the plan, not in a later performance audit. Decide early which pages are anonymous-cacheable and which are not: a live blog may need short cache TTLs or tag-based invalidation on each update, while a published feature can cache for an hour. Plan view modes per scenario — a breaking alert should not reuse the feature layout with an empty lead image slot. And enforce alt text at the field level: in a newsroom, accessibility failures reach readers at the worst possible moment, during the highest-traffic story of the month.
What To Hand The Developers
The output of the planning session is a short stack: the scenario list, the content-type definitions with fields and view modes, the moderation state diagram with role permissions, and the cache rules per scenario. With that stack, theming becomes styling known shapes instead of guessing at them. Without it, the build hardens around the first three stories and every new scenario after launch is a paid rebuild.
Common Failure Modes To Reject During Planning
Three failure patterns show up in almost every newsroom build that skipped planning. The first is the shared “super article” type: one content type carrying breaking alerts, features, and corrections, with a dozen optional fields that editors leave half-empty. The fields meant for the rare breaking story pollute every routine feature, and the empty fields leak into view modes as broken layouts. The second is review-free publishing rights granted to every role “for speed,” which turns the moderation log into noise and makes corrections untraceable. The third is treating cache and performance as launch-day tuning: the first big story melts the site because the live blog invalidates the entire page cache on every update instead of tagging its own fragments.
Rejecting these patterns costs nothing during planning and a rebuild after launch. The worksheet rows above exist precisely to force the conversation early, while answers are still cheap.
Sources And Where To Go Deeper
Two references anchor the technical claims in this guide. Drupal core ships with a content moderation system, documented in the Drupal.org content moderation documentation, and it is the base layer under every moderation plan described here. For the accessibility side, the WCAG 2.2 quick reference remains the checklist that newsroom themes and media fields must survive. Read those alongside the broader Drupal planning guide on this site, which covers the pre-newsroom planning layer: information architecture, component inventory, and the decision sequence that comes before editorial workflow design.
If the newsroom already runs on Drupal and the workflow feels strained, audit the current moderation transitions and field list against this worksheet before adding anything new. Most strained newsrooms need fewer content types and clearer transitions, not more modules.