CMS / DRUPAL
Drupal: Complete Guide to the CMS, Content Types, Modules, Themes & Website Development
Drupal is an open-source CMS and application framework used to build structured, flexible and content-rich websites and digital experiences.
This guide covers Drupal’s own architecture and terminology accurately, with honest comparisons and no superiority claims.
- Entities, content types, fields, taxonomy and Views
- Modules, themes, Twig, blocks, regions and permissions
- SEO, security, performance, Composer, Drush and migration
Drupal separates content structure, data, classification, display and presentation into distinct layers. That separation is the point of the platform.
THE BASICS
What Is Drupal?
Drupal is an open-source content management system that behaves, in practice, as much like an application framework as a website builder. Its defining characteristic is that you define your own content structure rather than fitting content into predefined types.
Where many platforms give you posts and pages, Drupal gives you the tools to define exactly what a Product, a Case Study, an Event or a Staff Profile contains — which fields, of which types, with which validation, related to which other content. That structure is then queryable, displayable and reusable throughout the site.
This is a genuine strength and a genuine cost. Content modelling is real design work requiring thought before you publish anything, and Drupal expects that investment. Sites whose content has real structure benefit substantially. A five-page brochure site does not, and will feel like considerable overhead for no return.
Drupal is free and open source under the GPL, maintained by a large community with a formal security team and published advisories. It is not “WordPress with more features” — it is a different architecture with its own vocabulary, and reading Drupal documentation through WordPress assumptions produces confusion rather than understanding.
On versions: Drupal 11 is the current major release series. Patch releases change frequently, so check drupal.org for current figures rather than any article’s.
Drupal in seven parts
│
├── CONTENT
│ ├── Content Types — structure definitions
│ ├── Fields — structured properties
│ ├── Entities — the data objects
│ └── Media — reusable media entities
│
├── STRUCTURE
│ ├── Taxonomy — vocabularies and terms
│ ├── Menus
│ ├── Views — listings and displays
│ └── Blocks — placed into regions
│
├── EXTENSIBILITY
│ ├── Core modules
│ ├── Contributed modules
│ └── Custom modules
│
├── PRESENTATION
│ ├── Themes
│ ├── Regions — defined by the theme
│ └── Twig templates
│
├── ACCESS
│ ├── Users
│ ├── Roles — group permissions
│ └── Permissions
│
└── CONFIGURATION & DATABASE
ARCHITECTURE
How Drupal Works
A request reaches the web server, which hands it to PHP running Drupal. Drupal routes the request, loads the relevant entities and configuration, lets modules act along the way, passes the result to the theme where Twig templates render it, and returns HTML, CSS and JavaScript.
Drupal Core is the base software: the entity system, field API, routing, user and permission handling, configuration management, and a set of core modules and themes. Core is maintained by the Drupal project with its own release and security cycle.
Three categories of extension exist and the distinction matters for maintenance. Core modules ship with Drupal. Contributed modules come from the community via drupal.org, each with its own maintenance status and version compatibility. Custom modules are written for one site and are entirely your responsibility — including keeping them working across major version upgrades.
One architectural decision shapes a great deal: Drupal separates configuration from content. Your content types, field definitions, Views, permissions and site settings are configuration, exportable to files and version-controllable. Your articles and pages are content. This separation is what makes a development-to-production workflow practical, and it is unusual among CMS platforms.
Drupal runs on PHP and outputs HTML, CSS and JavaScript like any server-rendered application.
CONTENT MODELLING
Entities, Content Types and Fields
Entities are Drupal’s structured data objects, and the concept is broader than “pages”. Drupal distinguishes two kinds.
Content entities hold data users create — nodes (the general content entity), users, taxonomy terms, media items, files and comments are all content entities. Configuration entities hold structural definitions: content types, fields, Views, image styles and roles are themselves entities, stored as configuration rather than content.
That distinction explains a lot about how Drupal behaves. A taxonomy term is not a label attached to a node — it is an entity in its own right, with its own fields, its own page and its own permissions. So is a media item. This is why Drupal can build relationships between things that other platforms treat as metadata.
Content types define the structure of a kind of content. Rather than fitting everything into a generic body field, you define that an Event has a date, a venue reference and a capacity, while a Staff Profile has a role, a photograph and a department.
Fields are the structured properties attached to entities. Available types include text, long text, number, date, boolean, email, link, image, file, list and entity reference — the last being the one that makes relational content modelling possible, since it points one entity at another.
The payoff is that structured data can be queried, filtered, sorted and displayed consistently. A price stored as a number field can be sorted on; a price typed into a body field cannot.
CONTENT TYPE: ARTICLE
CONTENT TYPE: PRODUCT
Illustrative examples. You define which fields each content type has, of which types.
Common field types
- Text and long text, with or without formatting
- Number, date, boolean and email
- Link, image and file
- List fields with defined allowed values
- Entity reference — pointing at another entity
- Media reference for reusable media items
├── Technology
│ ├── SEO
│ ├── Web Development
│ └── AI
├── Design
│ ├── UX
│ └── Branding
└── Business
VOCABULARY: Regions
├── Asia
│ └── India
└── Europe
Each term is an entity with its own fields and page.
STRUCTURE
Taxonomy and Views
Taxonomy classifies content. A vocabulary is a set of related classifications — Topics, Brands, Regions, Departments. A term is an individual item within one, and terms can nest hierarchically.
Terms being full entities matters practically: each has its own page, can carry its own fields, and can be referenced by any content type. A Region term can hold a map, an address and a contact, referenced by both Offices and Events.
Views is the feature most Drupal users would name first if asked what distinguishes the platform. It is a query builder with a user interface: you choose what to query, how to filter and sort it, which fields to output and how to display the result — as a page, a block, a feed or an API response — without writing SQL.
Latest articles filtered by topic. Events after today, sorted by date. Products in a category, in stock, ordered by price. Staff in a department. All built through configuration.
Views is also where performance problems most often originate. A View with many relationships, complex filters and no caching can generate expensive queries, and this scales badly with content volume. It is worth building Views with an eye on what they actually query.
FUNCTIONALITY & PRESENTATION
Modules, Themes, Twig, Blocks and Regions
The clearest division in Drupal: modules provide functionality, themes control presentation. They are separate systems with separate purposes, and keeping them separate is what makes a Drupal site maintainable.
Modules extend what Drupal does — adding entity types, altering forms, integrating external services, providing workflows, handling search. Note that Drupal modules are not plugins in the WordPress sense; Drupal has its own plugin system operating at a different level, inside modules.
Themes control how output is rendered: templates, CSS, JavaScript, and the regions available for placing blocks. Themes can inherit from a base theme, which is how sub-themes customise without duplicating everything.
Twig is Drupal’s templating engine. It receives prepared data and determines the markup, keeping presentation separate from application logic. Twig templates can be overridden in your theme with increasing specificity, so you can change how one content type renders without affecting anything else. Twig also escapes output by default, which prevents a category of security problem.
Blocks are reusable units of content or functionality. Regions are the areas a theme exposes where blocks can be placed. Blocks carry visibility conditions — by path, content type, role or language — which is how one theme serves pages that look genuinely different.
Modules
Functionality. Core, contributed and custom. They add capabilities, alter behaviour and integrate systems. Each contributed module is a dependency with its own maintenance status.
Themes
Presentation. Templates, styling, regions and asset handling. They determine how output looks, not what the site can do.
Regions are defined by the theme. Blocks are placed into them, with visibility conditions controlling where each appears.
ACCESS & CONFIGURATION
Users, Permissions, Configuration and Workflows
Drupal’s permission system is genuinely granular. Roles group permissions, users hold one or more roles, and permissions are defined by modules — so installing a module adds its own permissions to the matrix.
Permissions operate at a fine grain: create content of a specific type, edit own versus edit any, view unpublished content, administer a particular Views display, access specific admin pages. Field-level access can be controlled too. For organisations where different groups genuinely need different capabilities, this is a real advantage.
The accompanying honesty: this flexibility is only valuable if you need it, and the permission matrix on a site with many contributed modules becomes large enough to require deliberate review.
Configuration management is one of Drupal’s more distinctive engineering features. Because configuration is stored separately from content, it can be exported to files, committed to version control and imported into other environments. That makes a genuine development-to-staging-to-production workflow practical — you build a content type locally, commit it, and deploy it, rather than repeating clicks in each environment.
Content moderation provides editorial workflows with defined states and transitions, controlling who can move content between them. Combined with permissions, this supports organisations where content genuinely requires approval rather than relying on convention.
SEO & SECURITY
Drupal SEO and Security
Drupal does not make a site rank. What it provides is control — clean URLs, metadata handling, structured content and extensibility. Implementation and content decide outcomes, as with any CMS. See our website SEO guides.
Several SEO considerations are Drupal-specific. URL patterns are usually generated per content type, which is powerful and worth planning before publishing. Taxonomy term pages are created automatically and are frequently thin — a term page listing two items may not warrant indexing, and reviewing which should be indexed is worthwhile. And Views listings can produce paginated or filtered URLs that need canonical attention. See our technical SEO guide.
On security: Drupal has a formal security team and publishes advisories with severity ratings, which is a genuine strength of the project. Core has a good track record.
The risk sits where it sits on every CMS — contributed modules and delayed updates. Before installing a contributed module, check whether it is actively maintained, whether it has a stable release for your Drupal version, and whether it is covered by the security advisory policy. An unmaintained module is a liability that worsens with time.
Custom modules carry a particular obligation: nobody else is auditing them, and they are your responsibility across major version upgrades when APIs are deprecated.
SEO checklist
- Clean URL patterns configured for each content type
- Metadata handled consistently across content types
- XML sitemap generated and submitted
- Canonical URLs correct, especially with Views listings
- Redirects in place for any changed paths
- Taxonomy pages reviewed — many are thin by default
- Structured data added where genuinely applicable
- Image styles producing appropriately sized images
- Alt text required on image fields where it matters
- Internal linking built into the content model
- Views listings checked for duplicate or paginated content
- Caching enabled and performance measured
Security practices
- Keep Drupal core updated promptly
- Keep contributed modules updated
- Follow Drupal security advisories
- Remove unused modules rather than disabling them
- Vet contributed modules for maintenance status
- Use Composer to manage dependencies
- Apply least-privilege roles and permissions
- Review the permission matrix periodically
- Serve everything over HTTPS
- Keep tested, off-site backups
- Keep PHP and the database on supported versions
- Test updates on staging before production
[ ] Clean URL patterns configured for each content type [ ] Metadata handled consistently across content types [ ] XML sitemap generated and submitted [ ] Canonical URLs correct, especially with Views listings [ ] Redirects in place for any changed paths [ ] Taxonomy pages reviewed — many are thin by default [ ] Structured data added where genuinely applicable [ ] Image styles producing appropriately sized images [ ] Alt text required on image fields where it matters [ ] Internal linking built into the content model [ ] Views listings checked for duplicate or paginated content [ ] Caching enabled and performance measured
[ ] Keep Drupal core updated promptly [ ] Keep contributed modules updated [ ] Follow Drupal security advisories [ ] Remove unused modules rather than disabling them [ ] Vet contributed modules for maintenance status [ ] Use Composer to manage dependencies [ ] Apply least-privilege roles and permissions [ ] Review the permission matrix periodically [ ] Serve everything over HTTPS [ ] Keep tested, off-site backups [ ] Keep PHP and the database on supported versions [ ] Test updates on staging before production
PERFORMANCE & HOSTING
Performance, Caching, Hosting and the Database
Drupal’s caching system is sophisticated and worth understanding, because Drupal uncached and Drupal properly cached perform very differently.
Page cache serves complete pages to anonymous visitors. Dynamic page cache handles authenticated users by caching everything except the genuinely personalised parts. Render cache works at the component level, storing individual rendered pieces. Cache tags track which content each cached item depends on, so changing a node invalidates exactly what referenced it rather than everything — which is a genuinely well-engineered piece of the platform.
Beyond caching: image styles producing appropriately sized derivatives, aggregated CSS and JavaScript, a CDN where the audience is spread, and attention to Views, which is where expensive queries usually originate. See Core Web Vitals and website speed.
For hosting, Drupal expects more than a typical shared plan. Drupal 11 requires PHP 8.3 or newer, and current documentation lists supported databases including MySQL 8.0+, MariaDB 10.6+, PostgreSQL 16+ and SQLite 3.45+. Command-line access is effectively necessary for Composer and Drush workflows, which rules out some cheaper hosting. Verify current requirements at drupal.org before committing to a host. See our hosting guides.
The database stores content entities, configuration, users, taxonomy, media references and application data. Files live on disk with the database holding references — which matters for backups, since a database-only backup restores a site with every file missing.
DEVELOPMENT
Development, Composer, Drush and Decoupled Drupal
Drupal development uses PHP with Twig templating, and the modern codebase builds on Symfony components — services, dependency injection, event subscribers and routing follow patterns familiar from that ecosystem. Developers extend Drupal through custom modules and themes using its APIs and plugin system.
Composer manages dependencies and is central to modern Drupal. Core and contributed modules are installed as Composer packages, with dependencies and version constraints resolved automatically. This is not optional convenience — it is how Drupal projects are structured, and understanding it is a practical prerequisite for maintaining a site.
Drush is a command-line tool widely used for administration and development: clearing caches, running database updates, importing and exporting configuration, managing users and running maintenance tasks. Most Drupal workflows assume it is available, which is part of why command-line hosting access matters.
Drupal provides APIs for building custom functionality and integrating external systems. It also supports decoupled architectures, where Drupal manages content and exposes it through an API while a separate frontend renders the site. Check current Drupal documentation for available API modules and authentication rather than assuming.
Decoupled Drupal buys frontend flexibility and costs complexity: two systems, two deployments, and you take on rendering, caching and SEO decisions the theme layer would otherwise handle. It suits multi-channel content delivery; it is not an upgrade path every site should take. See our website APIs guide.
Development toolchain
- Composer — dependency and package management
- Drush — command-line administration
- Twig — templating with automatic escaping
- Configuration export — version-controlled structure
- Custom modules for functionality
- Sub-themes for presentation
CAPABILITIES
Multilingual, Accessibility, Commerce and Site Types
Multilingual and accessibility
Multilingual support comes from core modules covering three distinct layers: interface translation for Drupal’s own text, content translation for your entities, and configuration translation for things like field labels and Views titles. That third layer is one most platforms handle poorly, and it matters on a genuinely multilingual site.
Accessibility has been a stated priority of the Drupal project, and core aims to follow WCAG guidance in its own output and admin interface. That gives you a reasonable starting point rather than a finished result — your theme, your contributed modules and your content still determine whether the delivered site is accessible. See our website accessibility guide.
E-commerce
Drupal supports commerce through Drupal Commerce and comparable projects rather than core functionality. These provide products, variations, carts, checkout, orders, payments and tax handling, built on Drupal’s entity and field system — so products are entities with fields you define, and Views can query them like any other content.
That architecture suits complex catalogues with unusual product structures or heavy integration requirements. It is a different proposition from a hosted commerce platform, where far more arrives configured. Which fits depends on how much of your requirement is standard and how much is specific to you.
Government & Public Sector
Structured content, accessibility requirements, multilingual needs and defined publishing processes.
Universities & Education
Large content volumes, many departments, granular permissions and complex navigation.
Publishers & Content Portals
Editorial workflows, taxonomies, many authors and high content volume.
Enterprise Websites
Integration with external systems, content governance and multi-site requirements.
Multilingual Sites
Content, interface and configuration translation handled through core modules.
Community Platforms
User accounts, roles, permissions and user-generated content.
Business Websites
Where content genuinely has structure worth modelling.
E-Commerce
Through Drupal Commerce or comparable projects, rather than core functionality.
COMPARISONS
Drupal Compared With Other Platforms
These describe differences rather than declaring winners. Every platform here is a reasonable choice for some projects and a poor one for others.
Drupal vs WordPress
Both are open-source PHP CMS platforms. The clearest difference is where they start: WordPress gives you a working publishing system to extend, Drupal gives you tools to define your own. Drupal’s learning curve is genuinely steeper, and that cost is only repaid when the content has real structure. See our WordPress guide.
Drupal vs Joomla
Both handle structured content and granular permissions better than most. Joomla arrives closer to a functioning site with its article and category model; Drupal expects you to define the model first and gives more freedom in doing so. See our Joomla guide.
Drupal vs website builders
Against Webflow, Wix or Squarespace, the trade is control and modelling capability against convenience and managed infrastructure. Drupal assumes technical capacity; the builders assume you would rather not need any.
Drupal vs WordPress with Elementor
These are not comparable things, and the comparison needs stating carefully. Drupal is a CMS with a content modelling architecture. Elementor is a third-party visual page builder plugin for WordPress — not part of WordPress Core, and not a CMS in its own right.
The realistic comparison is Drupal against WordPress-plus-Elementor as a combination, and even then they answer different questions. Elementor is about designing pages visually — dragging elements, adjusting spacing, seeing the result. Drupal is about structuring content so it can be queried and displayed consistently in many contexts.
Someone whose priority is designing individual pages will find WordPress with Elementor far closer to that. Someone with a thousand products needing to appear in filtered listings across a site will find Drupal’s model closer to that. Neither is a substitute for the other, and a project usually points clearly at one.
FIT
When Can Drupal Be a Good Fit?
Drupal can be considered when a project’s shape matches what it does well. Fit is the honest question rather than ranking.
Complex Content Structures
Where content has many types with genuine relationships between them.
Granular Permissions
Where different groups need genuinely different capabilities.
Multilingual Requirements
Including configuration translation, not only content.
Editorial Workflows
Where content genuinely requires review and approval.
System Integration
Where the site must connect to external systems.
Technical Capacity
Where there is a developer or team to build and maintain it.
Equally worth stating plainly, because it saves people from expensive mistakes: Drupal is a poor fit for small brochure sites, for teams without developer capacity, where budget cannot cover ongoing maintenance, or where speed to launch matters more than structure. Choosing Drupal and then using none of its modelling capability means paying the learning curve and the maintenance burden for nothing.
Drupal is also not the automatic answer for “enterprise” requirements. What matters is whether the content genuinely has structure worth modelling — a large organisation with simple content needs is not a Drupal project by virtue of being large.
OPERATIONS
Migration, Upgrades, Maintenance and Troubleshooting
Migration covers several distinct scenarios that should not be conflated: moving hosting environments, upgrading between major Drupal versions, and migrating from another CMS. Each has different risks.
Major version upgrades are where Drupal demands the most planning. The limiting factor is compatibility — contributed modules need releases for the target version, custom modules need updating for deprecated APIs, and themes need checking. The order that works: audit what you have, check every module’s compatibility, update PHP to meet requirements, resolve deprecations in custom code, test thoroughly on staging, then deploy.
An honest caveat: no single upgrade procedure applies to every site, because every site’s module set differs. Instructions that worked elsewhere may not apply to yours, which is precisely why staging exists.
Migrating from another CMS is a content modelling exercise before it is a technical one. You have to decide what your Drupal content types will be and how the source content maps onto them — and that mapping is usually the hard part, not the transfer.
For troubleshooting, the reliable first question is what changed? Drupal problems almost always follow an update, a new module or a configuration change. Drupal’s own log messages are the first place to look.
These are possible causes rather than diagnoses. The same symptom frequently has several causes, which is why isolating changes on staging beats applying fixes found in forum threads.
Maintenance checklist
- Drupal core updated
- Contributed modules updated
- Security advisories reviewed
- Custom modules checked against API changes
- Backups running and verified by restoring
- Configuration exported and committed
- Performance measured
- Database reviewed as content grows
- Logs checked for recurring errors
- Permissions reviewed
- Unused modules removed
- Composer dependencies reviewed
- Major changes tested on staging
[ ] Drupal core updated [ ] Contributed modules updated [ ] Security advisories reviewed [ ] Custom modules checked against API changes [ ] Backups running and verified by restoring [ ] Configuration exported and committed [ ] Performance measured [ ] Database reviewed as content grows [ ] Logs checked for recurring errors [ ] Permissions reviewed [ ] Unused modules removed [ ] Composer dependencies reviewed [ ] Major changes tested on staging
REFERENCE
Drupal Core Concepts at a Glance
Drupal’s vocabulary is precise, and using it correctly makes documentation, issue queues and module descriptions considerably easier to follow.
Model Content First
The content model is the foundation. Design it before building.
Keep Core Updated
Security releases are the highest-value maintenance you do.
Vet Contributed Modules
Check maintenance status, stable releases and security coverage.
Use Composer
Dependency management is how modern Drupal is structured.
Version Configuration
Export it and commit it. This is what makes deployment work.
Optimise Views
Watch queries as content volume grows.
Test Backups
A backup never restored is a hope, not a backup.
Review Permissions
The matrix grows with every module. Check it periodically.
Use Staging
Especially for major version upgrades.
FAQ
Drupal: Frequently Asked Questions
Short answers to the questions people ask most about Drupal as a CMS, content framework and development platform.
NEXT TOPICS
Related CMS Topics
Each platform trades control, modelling capability, ease of use and maintenance responsibility differently. Which suits a project depends on the project.
WordPress
A widely used open-source CMS with a larger ecosystem and a gentler learning curve.
Joomla
An open-source CMS with hierarchical content organisation and granular access control.
Webflow
A hosted visual development platform combining design tools with a CMS.
Wix
A hosted builder focused on ease of use, with infrastructure managed for you.
Shopify
A hosted commerce platform built specifically for selling online.
Squarespace
A hosted builder with design templates and integrated hosting.
Framer
A design-led site builder with a visual canvas and publishing.
Web Development
The languages and frameworks underneath any CMS.
Explore the CMS Landscape
Continue exploring CMS platforms, hosting, website development, SEO, performance and ecommerce topics.