Drupal’s Content Architecture, Explained

In this article written by our Senior Digital Developer Marvin Parsons, we explore how Drupal’s content architecture comes down to four core concepts: Content Types are stand-alone pages with their own URLs — things people can find, bookmark, and share. Paragraph Types are the reusable components inside those pages — sections an editor assembles to build out each page. Views are rule-based feeds that populate themselves automatically instead of being handpicked. And Display Modes let the same piece of content look different depending on where it appears — a full page in one context, a compact card in another — without duplicating anything. Get these decisions right during planning and your team builds a site that’s faster to develop, easier to maintain, and scales without pain.

Plus, two contributed modules from the Click Here Labs team at TRG — Entity Reference View Mode Selector and Entity Reference Field Override — give content editors even more control by letting them choose how referenced content is displayed and override presentation properties on a per-placement basis, no developer needed.

You don’t need to be a developer to plan a Drupal website well. In fact, some of the most important decisions happen long before a single line of code is written. If you’re a project manager, product owner, or stakeholder involved in a Drupal build, understanding a few key concepts can save your team weeks of rework and keep your project on budget.

Let’s break down three foundational building blocks in Drupal using analogies that make sense from a business perspective.

• Content Types
• Paragraph Types
• Views

While there are thousands of modules to choose from, Paragraphs is an industry standard, and the other two are Drupal Core functionality.

Documents People Can Find and Share

Think of your website as a library of business reports. Each Content Type is a different kind of report your organization produces: quarterly business reviews, project proposals, case studies, team bios, or press releases. Each report type has its own standard structure. For example, a quarterly business review always contains a time period, key metrics, and executive summary, while a project proposal always contains an objective, timeline, budget, and team roster.

The defining characteristic of a Content Type is this: every piece of content created from a Content Type gets its own page with its own URL. When someone visits yoursite.com/blog/our-big-announcement, they’re viewing a single piece of content that lives under your “blog” Content Type. When they visit yoursite.com/products/widget-pro, that’s a piece of content from your “product” Content Type.

This is the right tool when the content needs to stand on its own. If a visitor could bookmark it, share the link, or land on it from a search engine, it should be a Content Type.

Common examples: Blog posts, landing pages, product pages, event listings, team-member profiles, case studies, press releases.

The Building Blocks Inside Those Documents

Now think about what makes up a business report. The report itself is your Content Type — it’s the document with a title that gets distributed, bookmarked, and shared. But the executive summary, the data table, the key-metrics highlight, the recommendations block? Those are your Paragraph Types. Nobody circulates “the executive summary” on its own. But those sections are what make the report functional and useful.

In Drupal, Paragraph Types are reusable components that content editors can place within a page. They’re the call-to-action banner, the testimonial carousel, the “Featured Blog Posts” section, or the three-column feature grid. They don’t have their own URL and they’re never visited directly. They exist to enhance the pages they live on and drive users to desired content or actions.

This distinction matters for planning. When a stakeholder says, “I want a section on the homepage that highlights three specific case studies,” that’s a Paragraph Type, much like a handpicked “Client Wins” section in a quarterly report where someone chose exactly which case studies to feature and in what order. It lives inside a page, not as a page.

Common examples: Hero banners, calls-to-action, curated content lists (handpicked blogs, featured jobs), testimonial blocks, accordion FAQs, media galleries, stat counters.

The Auto-Populated Section

If Paragraph Types are like handpicking which case studies go into a “Client Wins” section of your report, Views are like setting a rule that says: “Always pull the five most recent case studies tagged as ‘Enterprise,’ sorted by date.” Next quarter, when new case studies are published, the section updates itself. No one has to go back and revise the report.

Views work the same way in Drupal. Instead of an editor manually choosing which blog posts appear in a “Latest News” section, a View says: “Show me the five most recently published blog posts, sorted by date, and only include ones tagged as ‘Company News.'” When someone publishes a new post that fits those criteria, it shows up automatically. No one has to go update a separate page.

This is the right tool when content should be dynamic and rule-based rather than handpicked. If the answer to “Who decides what shows up here?” is “The system, based on rules,” you want a View. If the answer is “An editor picks them by hand,” you want a Paragraph Type.

Common examples: Latest blog posts feed, staff directory sorted by department, upcoming events list, related products, filtered job listings, search results pages.

The Same Report Section, Formatted for Different Purposes

Here’s where things get really powerful and where good planning pays off the most for scalability and flexibility.

Think about a single Case Study your company has produced. When it lives on its own page, you want the full treatment: client name, challenge, solution, results, testimonial, and supporting graphics. But when that same case study is referenced in a quarterly business review, you just need the client’s name, a one-line summary, and a key metric. And when it appears in an auto-generated “Recent Wins” list on the homepage, maybe you only show the client’s name and industry.

All three of those are the same case study (the same piece of content) displayed differently depending on the context. In Drupal, these different presentations are called “Display Modes” (sometimes called “View Modes”).

Display Modes let you define how a piece of content looks in different situations without duplicating anything. You create the Case Study once and then configure how it appears when it’s displayed as a full page, as a card in a listing, as a compact reference, or as a teaser.

This applies to Paragraph Types too. A “call-to-action” Paragraph Type might have a bold, full-width display when used on a landing page but a more compact version when placed in a sidebar.

Why should you care about this during planning? Because Display Modes are where design, content, and development intersect. When your team identifies Display Modes early it prevents the common problem of designers creating one-off layouts that look great in a mockup but create a maintenance nightmare in the real system. “We need a ‘card view,’ a ‘teaser view,’ and a ‘full view’ for Case Studies” is a concept that stakeholders, designers, and developers can all get on the same page about.

The Template System

Drupal has a beautifully logical system under the hood for handling all of this, and understanding it at a high level helps in grasping why these planning decisions matter so much.

Think of it as your company’s corporate style guide. Every report your organization produces follows the same brand standards: the same fonts, the same heading styles, the same layout rules. A “Key Metrics” section looks the same whether it appears in a quarterly business review or a project proposal. But when needed, a specific report type can have its own formatting rules, and a specific section within a specific report can be overridden further still.

Drupal uses a naming convention for its templates that follows a predictable pattern. There’s a general template for “Any content displayed as a card,” a more specific one for “A Case Study displayed as a card,” and potentially an even more specific one for “This particular Case Study displayed as a card.” Drupal automatically uses the most specific template it can find, then falls back to the more general ones.

What this means for your project

Consistency without rigidity. A Blog Card and a Case Study Card can share the same basic structure, but each can have tailored details where needed. When your team changes the shared card design, all cards update. When they need a Case Study Card to look slightly different, they can override just that one without touching everything else.

Easier maintenance: Because the system is predictable and hierarchical, making site-wide changes, like updating the look of all “Teaser” displays, becomes a targeted task instead of a scavenger hunt.

Faster development: When planning identifies the Content Types, Paragraph Types, Display Modes, and Views upfront, developers can build a lean, reusable template system from the start. This avoids the costly pattern of “We need another custom layout” six months after launch.

A Planning Exercise

Here’s a practical example. Suppose you’re planning a company website with a blog, a team section, and a careers page.

Content Types you’d likely need: Page (general content), Blog Post, Team Member, Job Opening.

Paragraph Types for building pages: Hero Banner, Call to Action, Curated Content List (for featuring specific blog posts or team members), Text with Image, Statistic Counter.

Views for automated sections: “Latest Blog Posts” (most recent five posts), “Open Positions” (all published job openings filtered by department), “Our Team” (all team members sorted by last name).

Display Modes to define: Blog Post → Full (the blog post page itself), Teaser (for listing pages), Card (for curated selections in Paragraph Types). Team Member → Full (their profile page), Card (for the team grid), Compact (for blog post author attribution). Job Opening → Full (the job description page), Teaser (for the careers listing page).

When you map this out before design even begins, your entire team starts from a shared understanding of how the site should work and look: designers, developers, content editors, and stakeholders alike. Design comps align with the real-content model. Developers build reusable patterns instead of one-offs. And content editors get a system that’s intuitive and maintainable for years to come.

Planning a Drupal site well isn’t about understanding the code. It’s about understanding the purpose of each building block and making intentional decisions about what gets its own page, what lives inside a page, what’s handpicked, and what updates automatically.

Get these decisions right early, and you’ll launch a site that’s not only easier to build but dramatically easier to maintain and grow.

The Click Here Labs team at TRG has released two new modules into Drupal’s contributed module ecosystem to take View Modes and Drupal content architecture to the next level for content creators.

Entity Reference View Mode Selector (drupal.org/project/ervms)

Remember the Display Modes section above, where the same team member can appear as a full profile, a card, or a compact byline? Normally that decision is locked in by a developer. If the “Related Content” section on your blog always renders referenced articles as cards, it renders every article as a card, every time.

This module hands that choice to the content editor. When an editor adds referenced content to a page, a simple drop-down appears next to each item, letting them choose: show this one as a teaser, that one as a card, and this other one as full content. Same field, same page, different presentations, all chosen at the time of editing, no developer needed.

Think of it like a picture-frame shop. Before, the developer picked one frame style and every photo in the gallery got the same one. Now, the editor gets to choose the frame for each photo individually.

Entity Reference Field Override (drupal.org/project/erfo)

This module solves a different but equally common problem: what happens when a reusable component needs to look slightly different depending on where it’s placed?

Say you’ve built a call-to-action paragraph, a “Sign Up Today” banner with a blue background. It looks great on the homepage. But on the product page, it really needs to be green to match the page’s color scheme. Without this module, you’d have to duplicate the CTA and create a second version just to change the color. Multiply that across dozens of pages, and you’ve got a content management headache.

Entity Reference Field Override lets editors change specific presentation properties, like background color, layout style, or visual emphasis, on a per-placement basis, without touching the original component. The original CTA stays exactly as it is. The override lives within the page that’s using it, not with the component itself. It’s like putting a colored filter over a spotlight: the bulb doesn’t change, but the light looks different depending on what effect is desired at the point of insertion.

Better Together

These two modules are designed as companions. ERVMS controls which Display Mode a referenced item uses, while ERFO fine-tunes how it looks in that specific context. Together, they give content editors a level of per-page, per-placement control that previously required either developer intervention or content duplication, neither of which scales well.