Skip to header Skip to main navigation Skip to main content Skip to footer

Main navigation

  • Home
  • Drupal Theming
  • Web Designer In Austin
  • Drupal Development Portfolio (opens in new tab)
  • Blog
  • Videos
  • Contact
Web Designer In Austin
Designing Drupal, Defining Distinction

The Drupal 11 Module and Theme Stack, With Versions Checked

Alaa Haddad, professional Drupal developer based in Austin, TX   Drupal Care
  10:38 PM CDT, Mon September 14, 2026
Share

This is the module and theme stack actually installed on the Drupal 11 sites behind this page, with the reason for each one and the core versions each declares. Every version string below was read from the .info.yml file on disk, not from memory — and one of the findings is that most contributed modules have not yet declared Drupal 12 support, which matters more than any feature list.

How to judge a module before you install it

The list matters less than the method. Four checks, in this order:

  1. Read core_version_requirement in the .info.yml. It is the module telling you, in its own words, which Drupal it supports. An inventory of these strings across your site is the first page of any upgrade plan.
  2. Look at the issue queue, not the star count. Recent commits and answered issues predict your next two years better than the number of installs does.
  3. Ask whether core already does it. Media, workflows, layout building and responsive images are all core now, and each contributed module you avoid is one fewer thing to upgrade.
  4. Install with Composer, always. A module unzipped by hand cannot be updated predictably and drops out of security tooling.

Core modules to enable first

Before installing anything, turn on what is already there: media and media_library for file handling, responsive_image for images that are not oversized on phones, content_moderation and workflows for editorial states, layout_builder where editors need per-page composition, path and path_alias for URLs, ckeditor5 for editing, and big_pipe, page_cache and dynamic_page_cache for performance. That is a capable site with no contributed code at all.

Administration and developer experience

  • Admin Toolbar — drop-down access to the whole admin menu. Declares ^9.5 || ^10 || ^11.
  • Module Matrix — a replacement modules page with filtering and package navigation, for sites where the module list has become unreadable. Declares ^10 || ^11 || ^12.
  • Config Split and Config Ignore — environment-specific configuration, and the escape hatch for the handful of settings that must not travel.
  • Devel — development only, never enabled in production. Declares ^10.3 || ^11 || ^12.
  • Upgrade Status — scans your site and reports what is not ready for the next major version. Declares ^10.4 || ^11 || ^12. Run it before planning an upgrade, not during one.

SEO and URLs

  • Pathauto with Token — URL patterns instead of hand-typed aliases.
  • Redirect — keeps old URLs alive. Non-negotiable on any site that has been restructured.
  • Metatag — titles, descriptions and Open Graph output, per content type.
  • Simple XML Sitemap — standards-compliant sitemaps with hreflang support.

These four cover the technical layer only. The content decisions are the part that actually moves rankings; the page speed write-up covers the other half that search engines measure.

Content modelling

  • Paragraphs — structured components inside content, instead of markup pasted into a body field.
  • Paragraphs Bundles — a ready-made suite of paragraph types so you are not modelling twenty of them by hand. Declares ^11.3 || ^12 and depends on Paragraphs, Entity Reference Revisions and Field Group. There is a longer explanation in unleashing creativity with Drupal paragraph bundles.
  • Field Group — tabs and sections on long edit forms, which is an editor-retention feature more than a technical one.

One structural warning before you build with any of these: blocks and block content are not the same thing, and confusing them is how paragraph content ends up duplicated across a site — see Drupal blocks vs block content.

Views display formats: the Vanilla Views set

Ten display formats for Views that render with vanilla JavaScript rather than a framework. They share one foundation module, VVJ Core, which is installed automatically with any of them — that is the part most listings of these modules get wrong, including the earlier version of this page.

  • VVJA — accordion
  • VVJB — carousel
  • VVJC — 3D carousel
  • VVJF — 3D flip-card
  • VVJH — responsive hero
  • VVJL — lightbox
  • VVJP — scroll-driven parallax
  • VVJR — reveal on interaction
  • VVJS — slideshow
  • VVJT — tabs

All eleven declare ^11.3 || ^12 and depend only on core's Views and Filter modules plus VVJ Core. Pair them with Better Exposed Filters when the view is something a visitor filters rather than just reads.

Front end

  • Solo — a configurable theme with 24 regions and 15 colour inputs per region, declaring ^10.1 || ^11 || ^12. The measured detail is on the Solo theme page.
  • Solo Utilities — adds rule-based colour schemes by content type, taxonomy, role or URL.
  • UtiliKit — a utility-first CSS layer generated at runtime, for teams that want utility classes without a build step. Declares ^11.2 || ^12.
  • Selectify — accessible select, radio and checkbox components for Views exposed filters and Field UI. Declares ^10 || ^11 || ^12.
  • Twig Tweak — the Twig functions you keep wishing core had.

Security, forms and performance

  • Honeypot — spam mitigation that costs a real user nothing, unlike a CAPTCHA.
  • Key — keeps API credentials out of configuration and out of your repository. Install it before the first integration, not after.
  • CSP — Content-Security-Policy headers.
  • Webform — when core's contact form is genuinely not enough.
  • Cloudflare Purge — URL, tag, prefix and hostname purging so a CDN can hold long TTLs safely. Declares ^10 || ^11 || ^12, and the reasoning is in Drupal, Cloudflare Purge and long cache TTLs.

Common questions

How many contributed modules is too many?

There is no number, but there is a test: can someone say out loud why each one is installed? Every module is a dependency to update, a possible security advisory and a thing that must be ready before your next major upgrade.

Are these modules ready for Drupal 12?

Some are and most are not yet. Of the versions installed on the codebase I read for this page, the ones declaring ^12 were Module Matrix, Devel, Upgrade Status, Views Reference, Module Filter and the projects maintained here. The rest declared ^10 and ^11 only. Check your own .info.yml files rather than trusting any published list, including this one — releases move.

Why is there no caching module in this list?

Because core has three cache layers and most sites have not configured those properly yet. Add Redis or Memcache when measurement says the database is the bottleneck, not before.

What happened to the modules that used to be on this page?

Several entries were removed because their current Drupal 11 status could not be verified from source. It is better to list twenty modules that were checked than sixty that were remembered.

Next steps

Run composer show 'drupal/*' against your own site and compare it to this list. The interesting output is not what you are missing — it is the modules you cannot justify, because those are the ones that will hold up your next upgrade.

If that inventory turns into an upgrade plan you would rather not write, Drupal services covers how an assessment is scoped, or get in touch. The projects listed above that are maintained here are all on the portfolio.

Drupal Architect

Footer menu

  • About
  • Privacy Policy
  • Terms & Conditions
  • Flash Web Center, LLC (opens in new tab)
  • Drupal Care (opens in new tab)
  • Log in
  • Contact

Copyright © 2026 Flash Web Center, LLC | All rights reserved

Developed & Designed by Alaa Haddad