Drupal for media and publishing

Why Drupal for media and publishing teams

Drupal fits a newsroom or publisher that wants to own its editorial, paywall and syndication logic. Drupal core and the contributed modules on Drupal.org are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself, so the platform cost is the cost of the people and infrastructure that run it. Self-hosted in your own cloud account or data center, the code that decides who sees an article, when it publishes and how it is syndicated can be changed by your team without waiting on a vendor's roadmap. That ownership is the main reason publishers choose it. The platform choice is separate from build quality, though: a Drupal site built on undocumented custom code and unplanned caching will fail under a traffic spike just as any other CMS would.

For editors, the change is mostly in the workflow. Content types, revision history, moderation states and scheduled publishing can be modeled around how your desks actually hand off stories, including legal or standards review before a timed release. For developers, the change is in how custom logic is organized: paywall rules, access checks and syndication feeds become custom modules with tests and code review, so a Drupal upgrade does not turn into a rewrite. Ask your partner to show how each custom component will be versioned and tested. For the business, the question is who holds the code and the hosting contract. Confirm with your team which parts you want to keep in-house after launch and which you want supported under a retainer, because that decision shapes the total cost more than the license does.

Publishing requirements and what they mean for the Drupal build

This table maps the core demands of a newsroom or publisher onto the Drupal decisions they force, with the supplied source that anchors each row. Read each row as a question to settle before the build starts, not as a finished design. The main takeaway is that version support, editorial workflow and cache behavior shape the architecture from the first sprint.

Publishing requirement	What the source establishes	Build consequence
Editorial scheduling and approval	Core releases follow a fixed bugfix and security cadence, so editorial features depend on the core line you choose.	Confirm which workflow and scheduling modules you need on your target core version before modeling approval states.
Traffic spikes and cache invalidation	Drupal runs on Apache or Nginx with MariaDB, MySQL, PostgreSQL or SQLite, so caching and database sizing are set by your hosting choice.	Plan reverse proxy or CDN purging by cache tag and test breaking-news load on a staging copy of your real stack.
Subscription and paywall access	The OpenID Connect module can create accounts on first sign-in and supports Okta, Google and generic OAuth 2.0 providers.	Decide which system is the source of entitlement, and keep paywall checks out of cached pages so anonymous caching stays valid.
Syndication feeds and canonical URLs	Feeds and canonical tags are built by your templates and modules, not supplied by core as a finished publishing pipeline.	Specify URL aliases, canonical link rules and feed fields in the content model so syndication partners receive one authoritative URL per story.
Search and SEO metadata	Metadata, sitemaps and structured data depend on contributed modules and theme output, which must be checked per release.	Map metadata fields into content types early, and confirm module support for your Drupal version before committing to a design.
PHP and core version support	Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later. Drupal 10 reaches end of life on December 9, 2026.	Choose the core line and PHP runtime together, and schedule a Drupal 12 readiness check before the end-of-life window for your current line.

Which modules and integrations matter in a newsroom

Newsroom content is rarely a single article type. Stories, live blogs, galleries, explainers and corrections each need different fields and layouts, and editors need to rearrange modules on a page without a developer. Paragraphs lets you model reusable content blocks inside a node, while Layout Builder controls how those blocks are placed on templates and individual pages. Together they decide how much flexibility editors get and how much markup your theme has to handle.

Content types first: Define article, live blog and correction structures before choosing layout tools, so layouts serve the model rather than the reverse.
Paragraphs scope: Limit the block library to what editors actually publish, since every paragraph type adds fields, templates and test cases.
Layout Builder rules: Decide which templates editors may override, and keep a locked default for sponsored and legal content.
Editorial workflow and scheduling: Confirm how draft, review, approval and scheduled publishing states are handled, and whether the workflow module you choose supports them for your Drupal version.
Archive search: Search API with Solr gives archive and topic search a dedicated index, which is usually needed once the archive is large.

Before choosing any of these, confirm each module's release compatibility with your target Drupal version, and confirm how your chosen modules behave on the Drupal version you will run after your next upgrade.

How a publishing rollout is phased

The sequence moves a newsroom from an inventory of today's content and workflows to a tested Drupal site that editors trust on deadline, with each phase closing on evidence rather than on a calendar. Durations depend on scope and must come from a written plan.

Audit content, templates and editorial workflows
Inventory existing content types, story formats, sections, bylines, syndication feeds, paywall rules and the approval steps each desk actually follows, including informal ones. The audit is run with editors, section leads, audience and engineering staff together. It closes with a written list of what must migrate, what can be retired and which workflows need a pilot. Confirm with the client which of these inputs already exist in documented form before the audit starts.
Design the content model and roles
Translate the audit into Drupal content types, fields, taxonomies, media handling and revision rules, plus roles and permissions for reporters, editors, copy desks and admins. The design covers scheduled publishing, embargoes, corrections and update history, since these shape the data model. DeployOpen produces the model as a reviewed document and a configuration baseline. The step closes when editorial leads sign off on every story format against a sample of real assignments.
Build custom modules, integrations and theme
Build the components the model depends on: custom modules for paywall and entitlement checks, syndication feeds, analytics tagging and any identity or subscription connectors agreed in scope. The theme is built from components so that layout changes do not touch article logic. Code is reviewed and covered by automated tests before it enters the shared environment. The step closes with a working build that passes the agreed test suite in a staging environment.
Pilot the editorial workflow with real desks
Move one or two desks onto the new site for live work, such as a single section or a regional team, while the existing system stays in service. Editors use real assignments, scheduling and corrections, and the pilot logs every point where people work around the tool. Findings go into a prioritized fix list reviewed weekly with desk leads. The step closes when the pilot desks agree the remaining gaps are acceptable for wider rollout.
Test caching, CDN purging and load before launch
Configure the page cache, reverse proxy or CDN, cache tag invalidation and any queue or cron jobs, then run load tests that model breaking-news traffic spikes and a scheduled publish burst. Tests check that a published correction purges every affected page, that logged-in and paywalled responses are not cached publicly, and that origin capacity holds under the agreed peak. The step closes with a written test report, the failures fixed and a repeated run that passes.
Run a parallel period and rehearse cutover
Publish to the new site alongside the existing one for an agreed period, comparing URLs, feeds, subscriber access, analytics and search indexing. Rehearse the cutover steps, DNS changes, redirect map, feed switchover, rollback trigger and communications to desks and readers. The step closes when the reconciliation shows no unexplained differences and the rollback steps have been run successfully in staging. Ask the partner to confirm the exact parallel-run length in the written plan.
Cut over and hand over operations
Execute the agreed cutover window, watch error rates, cache hit ratios, paywall behavior and syndication delivery, and keep the rollback path open until the agreed exit criteria are met. Hand over runbooks for publishing incidents, cache purging, update routines and on-call escalation. Ongoing work such as Drupal security releases, which arrive on the third Wednesday of the month, and core updates is scheduled under a support arrangement. The step closes when operations staff run a recovery drill unaided.

Where newsroom Drupal projects usually go wrong

Most newsroom Drupal failures come from decisions made early and discovered late: how pages are cached, where paywall logic runs, which platform versions are still supported, and who owns each editorial step. Each card names the consequence and the design control that prevents it.

Launch-day cache misses overload origin

A breaking story can send traffic far above normal within minutes. If the CDN and reverse proxy do not serve most anonymous pages from cache, every request reaches PHP and the database at once. Check that cache tags are purged when an article is edited, that cache warming runs before embargo lifts, and that origin capacity is load tested against a realistic launch scenario agreed with editors.

Paywall logic leaking into cached pages

When a page is cached for everyone, a per-user entitlement check can show subscriber content to anonymous visitors or hide articles from paying readers. The usual fix is to keep the paywall decision out of the shared cache, either by rendering it client-side or through an edge check with a separate cache variant. Ask the team to write down which content types are gated, which cache contexts vary by user, and how a test account is verified in each cache tier.

Drupal 10 end of life arrives mid-build

Drupal 10 reaches end of life on December 9, 2026, according to the core release schedule. A newsroom build that starts on Drupal 10 in the middle of its timeline may launch on a platform that no longer receives security releases. Decide the target major version at scoping, confirm the contributed modules and custom code you rely on support it, and plan the upgrade as a tracked work item rather than a post-launch task.

Unsupported PHP versions in production

Each Drupal major version sets a minimum PHP version, and older PHP releases stop receiving fixes. Hosting images, managed platforms and container base images often lag behind. Before the build, record the PHP version on every environment, including staging and the CDN edge functions that call the site, and confirm that the hosting team can move to the version the chosen Drupal release requires.

Drupal 7 sites kept on extended support

Many publishers still run Drupal 7 sites with archives, legacy paywalls and custom themes. Drupal 7 security support ended on January 5, 2025, and sites that cannot migrate can buy extended security coverage from listed providers. This is a bridge, not a plan. Inventory the legacy site, decide which content moves and which is archived, and note that themes must be rebuilt because they cannot be migrated.

Editorial workflow built before roles are agreed

Scheduling, approval states and embargo rules are easy to configure and expensive to change after editors have adopted them. If desks disagree on who can publish, who can override a scheduled time and who signs off on corrections, the workflow will be rebuilt during user acceptance testing. Settle role definitions with the managing editor, the standards desk and the audience team before any content type or state machine is built, and record each permission against a named role.

How syndication and SEO hold up at scale

Syndication and search rankings for a publisher depend on decisions made before the site is rebuilt, not after. The first decision is which URL is canonical for each story. When a wire partner, aggregator or regional edition republishes an article, the copy needs a canonical reference pointing back to the originating page, and the publisher's Drupal content model should store that reference as a field on the article node so editors and feeds can read it. Plan the rules for syndicated stories in the editorial workflow: who sets the canonical value, what happens when a partner copy outranks the original, and how syndication feeds expose the canonical URL. Confirm with your syndication partners which canonical or sitemap signals they honor, because that behavior sits outside your Drupal site.

Sitemaps and news metadata need the same care. Drupal's sitemap and metadata modules can generate XML sitemaps and structured data, but a publisher usually needs a dedicated news sitemap limited to recent articles, with publication dates and titles that match the page. Map the fields that feed that output, such as headline, publication timestamp and section, and check that scheduled articles stay out of the sitemap until they go live. Redirect and alias management is the highest-risk part of a redesign. Build the redirect map from the current crawl and analytics before cutover, pair every legacy URL with a destination, and test the map on staging with a crawler. Redirects that exist only in the database after launch tend to be incomplete, so the map should be versioned and reviewed like code. The Drupal SEO guidance covers the metadata, alias and structured data detail for these components.

What publishers ask before hiring a Drupal partner

What drives the cost of a Drupal publishing build?

The cost is driven mostly by scope: how many content types and editorial workflows exist, how many integrations are needed (paywall, subscriptions, CRM, syndication, analytics), how much custom theming is required, and how much content must be migrated. A fixed-scope quote follows from a written scope, so the scope document is the thing to get right first. Recurring costs include hosting, CDN and cache infrastructure, security updates, and support hours. Ask any partner to split the quote into one-time build work and recurring operations, and to list which integrations are included and which depend on third-party vendors you still need to select. Drupal itself is licensed under GPL-2.0-or-later, so there is no software license fee for the core platform, though contributed modules and hosting still carry their own costs.

How long does a Drupal news site take to build?

Duration depends on how many editorial workflows must be designed, how many integrations depend on external vendors whose APIs and access you do not yet control, the volume of content to migrate, and how many review rounds the newsroom schedules. Integrations with a paywall or subscription provider often set the critical path because access, sandbox credentials and test accounts arrive late. Ask for a timeline that separates discovery, content modeling, editorial workflow design, integration builds, performance testing and cutover, and confirm which milestones depend on your staff's availability. No duration should be accepted before the written scope is agreed.

What does the newsroom need to supply for the project?

The project needs named editors who can define editorial workflows, such as draft, legal review, scheduled publication and corrections, because those rules become configuration and code. Content owners must approve the content model, including article, live blog, video and author types, and decide what happens to legacy URLs. Existing analytics access, including page-level traffic data and the tags used to measure referrals, is needed to plan caching behavior and SEO protection. You should also supply access to your paywall, subscription, CRM and syndication partners, with test credentials and written API documentation. Ask each partner to confirm which of these inputs their scope assumes.

Can our in-house team run the Drupal site after launch?

Yes, if the team has someone who can apply security updates, deploy code through a repeatable release process, and read logs and cache behavior when traffic spikes. Drupal releases follow a published schedule: bugfix releases come out on the first Wednesday of each month and security releases on the third Wednesday, so staff need a standing monthly routine. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. Your team should be able to plan that major upgrade. Many publishers split responsibilities: internal staff handle content and editorial configuration, while a partner holds a support retainer for patching, monitoring and incident response.

How is a Drupal 7 archive migrated to a current site?

Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later. Content is moved into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and themes must be rebuilt because they cannot be migrated. Drupal 7 security support ended on January 5, 2025, so an archive that cannot move immediately may need extended security support from a certified provider. The Drupal Association lists HeroDevs and Tag1 Consulting for that purpose. For a publisher, the work usually covers mapping old content types to new ones, preserving URLs and redirects, validating article counts and images, and deciding which old pages are archived rather than migrated.

How are Drupal security advisories handled on a publishing site?

The Drupal Security Team resolves reported vulnerabilities in core and contributed projects, publishes advisories with CVE identifiers and risk scores, and uses Wednesday security release windows. Your process should define who receives advisories, how a patch is tested on a staging copy, and how quickly a critical update can reach production outside the normal monthly cycle. For a publisher, the risk is not only the CMS but also contributed modules, PHP versions and the hosting stack. PHP requirements also change: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, and no supported Drupal version runs on PHP 7. Ask any partner to describe its advisory response steps in writing.

Which parts of a publishing build are one-time and which recur?

One-time work includes discovery, content modeling, editorial workflow design, theme build, integration development, data migration and launch testing. Recurring work includes hosting, CDN usage, security and bugfix updates, contributed module maintenance, monitoring, content operations support and periodic performance testing. Major version upgrades, such as the move from Drupal 11 to Drupal 12 that the release schedule anticipates, are a planned project of their own. Ask for the recurring portion of the quote to be stated separately, with the hours or service levels it covers, so budget owners can compare it with an internal staffing plan.

Does a publishing site need a license to use Drupal?

Drupal and contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. Legal teams should still review the licenses of each contributed module and any proprietary paywall, subscription or analytics service the site connects to, because those carry their own terms. Ask your counsel to review the full dependency list before the scope is signed.

Compliance and security considerations for publishers

Publishers carry security exposure through their CMS, their staff accounts and their reader data, and each of these needs its own control. The cards below cover patching, runtime support, staff sign-in, subscriber data and the evidence that shows the controls run. DeployOpen prepares these controls and evidence for your assessors, but it does not issue audit reports or certifications.

Security advisory response

The Drupal Security Team publishes advisories with CVE identifiers and risk scores, and it uses Wednesday security release windows, so a newsroom site needs a fixed owner and a fixed response time for each advisory. Agree in writing who reviews an advisory, who tests the patch on a staging copy of the site, and who approves the production deploy. Check that your contributed modules are covered by the same process, since advisories also apply to them. Confirm the named on-call owner before launch.

PHP and database support

Each Drupal major version requires a minimum PHP version, and an unsupported runtime stops you from applying later security releases. Map your PHP and database versions against the Drupal version you run now and the one planned next, and schedule the runtime upgrade before the core upgrade so the two changes do not overlap. Confirm which database engine your hosting provider supports and who patches it. Keep the same map in your change records so auditors can trace each runtime to its supported core.

Staff access through SAML or OIDC

Editors, contributors and administrators should sign in through your corporate identity provider rather than local Drupal passwords, so that leavers lose access in one place. The samlauth module lets Drupal act as a SAML service provider, and the OpenID Connect module creates accounts on first sign-in, which makes role mapping the decision that matters most. Define which groups map to editor, publisher and administrator roles, and remove the local administrator account for daily use. Test the deprovisioning path as well as sign-in.

Reader data for subscriptions

Subscription and paywall integrations often pass reader identifiers, entitlement status and sometimes payment references through the CMS, even when the payment itself runs in another service. Decide which fields the Drupal site stores, which it only reads at request time, and which never reach it. Restrict access to user records and logs that contain reader email addresses, and set retention periods for them in writing. Confirm with your privacy counsel how this data is classified before the integration is built.

Evidence of patching

Assessors and internal reviewers will ask for proof that each security release was applied, when, and by whom. Keep a dated record for each release that lists the advisories, the staging test result, the production deploy and the rollback plan. Store the Composer lock file or build artifact used in each release so the running code can be matched to a known version. This record is usually more useful than a policy document, because it shows the process ran.

What to confirm with your own team and vendors

Several parts of a publishing build depend on facts that change outside your project, so confirm them in writing rather than assuming them. Start with the paywall and subscription vendor. Ask for the current API reference for entitlement checks, metering, login hand-off and webhooks, and confirm which API version your contract covers and how long that version is supported. Ask whether the vendor's SDK or server-side calls work with the PHP version your Drupal release requires, and whether the vendor expects the Drupal site or the CDN to evaluate access on cached pages. Those answers decide whether your cache-aware access check is a small module change or a redesign.

Next, confirm what your CDN can actually purge. Ask whether it supports purging by cache tag or surrogate key, how fast a purge propagates across edge locations, whether purge requests are rate limited, and whether the Drupal integration module you plan to use is maintained for that CDN. Check the same things for any image service. Your editorial team will expect a breaking story to appear everywhere within seconds, so write that expectation down and test it against the vendor's documented behavior, not against a sales summary.

Check the contributed modules for your chosen Drupal version before you fix the scope. For each module in the plan, confirm the current stable release, its declared core compatibility, its maintainer activity and its open security advisories on Drupal.org, and confirm that any custom patch you depend on has a path into a release. Confirm the Drupal core release dates on the official schedule for your planned go-live window, because a major version change can land during a launch period. Finally, confirm data-processing terms with each vendor that receives reader or subscriber data, including where personal data is stored, which sub-processors are used, retention of analytics and consent records, and how deletion requests reach each system. Your privacy and legal teams should review these terms before the data flow diagram is signed off.

How DeployOpen scopes and supports publishing platforms

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted Drupal inside your own cloud accounts, data centers or air-gapped networks. For newsrooms and publishers, that means editorial workflow, caching, subscription integrations and SEO are scoped together before any build starts.

How we scope

Map editorial roles, scheduling needs and publishing workflows before naming any Drupal modules or custom code.
Define the caching, CDN and cache tag purging approach, with traffic peaks and breaking-news load written into the scope.
Agree in writing which paywall, subscription, syndication and SEO integrations are in scope, and which remain with your vendors.

How we build

Build content models, editorial workflows and scheduling on Drupal core and vetted contributed modules, with custom code limited to documented gaps.
Configure the CDN and reverse proxy layers so cache tags purge correctly when editors publish or correct stories.
Test subscription entitlements, metadata output, redirects and sitemaps in a staging environment that mirrors production hosting.

How we hand over

Deliver architecture notes, configuration exports, custom module documentation and runbooks for editors and platform staff.
Walk your editorial, engineering and security teams through the publishing workflow and the cache purge procedure before handover.
Document the Drupal core and contributed module versions in use, so your team can plan updates against the release schedule.

How we support

Offer ongoing support, security update handling and upgrade work as a retainer, scoped separately from the build.
Plan Drupal core releases against the published schedule, including bugfix, security and major version timing.
Confirm with your team which parts of the publishing stack, such as the CDN, subscription provider or syndication partners, your own staff or other vendors maintain.