Choosing open-source software can free an organisation from a vendor's restrictions. It cannot free that organisation from the responsibility of maintaining what it uses. The distinction became harder to ignore when the Drupal Security Team and core release managers announced a shorter security-support window for standard minor releases. Beginning in 2027, coverage will fall from twelve months to eight, leaving site owners roughly two months to upgrade after a new minor version arrives. The decision reduces the workload for maintainers, but also leaves organisations less time to complete their own testing and approvals.

The pressure behind that decision is substantial. Between June and October 2026, Drupal published 256 security advisories across core and contributed projects, exceeding the 250 published during the preceding thirty months. The Drupal Association links the surge in reports to the growing use of AI-assisted vulnerability discovery, while funding from Alpha-Omega has supported efforts to manage the increased volume. Core release management, however, faces a separate funding problem, with experienced maintainers reporting significant reductions in sponsored hours. The result is an uncomfortable imbalance: more vulnerabilities are being discovered, but the resources needed to maintain and distribute secure software remain uncertain.

Public institutions face a similar challenge when pursuing digital sovereignty. Following DrupalCon Rotterdam's Government Summit, Bert Boerland, chair of Stichting Drupal Nederland, argued that public procurement should reward contributions to the software communities supporting government services, rather than paying only for finished applications. Governments may have the legal freedom to modify or replace their software, yet remain dependent on suppliers for the expertise to maintain it. Europe's Digital Commons EDIC strategy, which includes a maintenance funding pilot, offers one possible response to that dependency. Whether such commitments produce lasting support will depend on their implementation.

What connects these developments is the growing distance between those who benefit from open-source infrastructure and those responsible for sustaining it. Drupal's security commitments rely on maintainers whose time and expertise are finite, while public institutions depend on software communities that their procurement systems may do little to support. Neither problem can be resolved simply by choosing an open-source licence. As governments and businesses place more essential services on shared software, the question becomes less about whether they have the freedom to control it and more about whether they are prepared to share the responsibility that makes such freedom possible.

Follow The DropTimes on LinkedIn and Bluesky, or join #thedroptimes on Drupal Slack. 

Allen Jason wrote and curated this issue of Editor’s Pick.

Real-time Drupal with Drupack

One reason I want Drupal to standardize on FrankenPHP is so we can build on top of the built-in mercure server and unlock a whole new range of applications for Drupal. Of course we can do all this today, provided you maintain a separate server (most likely a nodejs server of some kind), write the integration code and make sure everything keeps working… I'm all about reducing the cost of ownership, it's not ideal to have to deal with that.

theodore November 9, 2026

Which Drupal Canvas starter includes Workbench, how do the adapters differ, and what can prevent draft previews? A tested Next.js setup provides a practical reference.

A public contract can finance a new government website while leaving the software beneath it underfunded. That gap raises questions about who should pay for future fixes and improvements.

School website design lessons from the 100 largest US districts: what their homepages ship, what most miss, and the April 2027 accessibility deadline.

Drupal Paradigms

I've been using Drupal for a number of years now, and I've built up a set of paradigms (or heuristics) that help me with building Drupal sites. These are based around both using Drupal as well as developing and maintaining Drupal sites, and even web development in general.

When putting together content types or building Drupal modules I have these rules at the back of my mind, guiding my actions. They've even been used in more than one sales document where I talk about how we work.

In this article I will look into a set of Drupal paradigms, with some explanation about each one. I'll also add example where possible to illustrate my thoughts.

First, let's start with a classic.

Don’t Hack Core

You've probably heard this one before, but I thought I'd start with it as it is just as important now as it ever was.

Back in the Drupal 6 + 7 days, when I first started using Drupal, it was quite difficult to update the site when a new version came out. It was mostly a case of copy/pasting from a download into the correct directories to override any existing code already in your site.

This was before composer was introduced to Drupal and whilst tools like Drush Make existed to automate this, they weren't widely used in the community. At least, I rarely saw them used outside of projects I was building.

Because updating code was so manual the phrase "don't hack core" became quickly adopted as it became quite difficult or time consuming to update the versions and make sure that your overrides were still in place. Altering Drupal core files (or even module files) also meant that the site could experience bugs that weren't in the original code base and that the maintainers couldn't possibly assist with.

philipnorton42 Sun, 08/11/2026 - 18:55

This Drupal AI modules overview maps release maturity, dependencies, and run costs so your team can shortlist editorial, automation, search, and agent integrations.

A member of two departments asks the intranet's assistant what the company has on SMTP. The vector database ranks the whole intranet, hands back the ten closest passages, and Drupal then throws away the ones she may not open. She gets whatever is left, fewer than she asked for and not the best she could have had. On the search page next door, the same thing shows up as a result count above a list shorter than the page, and a pager that runs past the last result she can open.

That is what happens on a site built with Group 3 as soon as the search goes through Search API. Group enforces access by altering SQL queries, so Views listings of nodes respect it. A Search API search goes to its backend, where Group never sees it. The Content access processor that ships with Search API indexes node grants, and Group 3 uses none.

Search API Group Access closes that gap where it opens, inside the search backend. It is free software under GPL-2.0-or-later, and 1.0.0, released on 8 November, is its first stable release. It plugs into Search API and Group, and works on any backend that supports condition groups and IN filters: the database backend, and AI Search on a vector database such as Qdrant.

What you can build with it

• A search page on an intranet or extranet whose result count, facets and pager agree with what each member sees, because the backend ranks and counts only that.
• An AI assistant that answers from your content and retrieves only from the groups the person belongs to, so asking for ten passages returns ten they can open.
• A new member who finds the group's documents on their very next search. Memberships, roles and permissions are read when the search runs, so changing them reindexes nothing.
• Comments found by whoever may see the entity they are attached to, and reindexed when that entity changes groups, owner or status.
• Paragraphs, or any other entity Group does not relate, that take on the access of their host through one event subscriber.
• A large index rolled out with no gap in service: index the access values with the filter off while searches keep working, then switch the filter on without reindexing.

The same answer as Group, or no answer

The rule the module is built to is parity with Group: for the "view" operation, a search returns an item if and only if an entity query that checks access would, as far as Group decides. Outsider, insider and individual permissions, "any" and "own", published and unpublished. The test suite runs both for a matrix of accounts and compares the results, and it runs on Drupal 10 and 11.

Where it cannot be exact, it errs towards hiding. An item that has not been indexed with the processor yet is returned to nobody. There is one known case where Group would show an item and the search does not, in an item that belongs to two groups when the insider role grants less than the outsider role, and the module accepts that false negative rather than risk a false positive. Groups themselves are not covered, and neither are operations other than "view".

Caching gets the same care. Turning the processor on or off saves the index's views again, so a results cache never serves one member's results to the next.

Where it came from

We built it for our own intranet, where an assistant answers questions from about 270,000 items stored in Qdrant through AI Search, and every one of its searches goes through the filter. The person who sees least of the intranet asks for ten passages and gets ten, all of them ones they may open.

Getting there taught the module two things it now does by itself. Values meant to be matched exactly are hashed to plain hexadecimal, because AI Search runs every text attribute through an HTML to Markdown converter that escaped the underscores in them. And the status report flags an AI Search index whose access fields are not set as filterable attributes, where every search would otherwise come back empty. On Qdrant, give those fields payload indexes: on an index of 190,000 points, a filtered search took 100 to 210 ms without them and 2 to 16 ms with them.

Get it composer require drupal/search_api_group_access drush en search_api_group_access

Then check Group access on your index's Processors tab and reindex. It requires Drupal 10.3 or 11, Group 3.3 or later and Search API 1.39 or later. Stable releases are covered by Drupal's security advisory policy.

The README covers the rollout on a large index, AI Search and Qdrant, and the events. If you also need entity reference fields to offer only the content of the group being edited, Group Entity Reference Filter does that. And if your site shares content out by group in a way the module does not cover yet, tell us in the issue queue.

Copying facts from PDFs into a website takes time that editors could spend checking the facts themselves. To extract data from PDF into Drupal reliably, you need more than a tool that reads documents. You need a pipeline that puts each value in the right field, catches problems, and gives a person enough context to approve the result.

My Garmin runs sync to Strava with generic names like "Lunch Run." I built a Strava webhook in Drupal that renames them with the Garmin workout name and adds the workout plan to the description, working through it with Claude Code in one afternoon.

Drupal 11.4 URLs should be generated with core APIs instead of being joined from strings. This guide shows how to match the URL method to a route, entity, URI, or editor-entered path, and how to render links, check access, and keep cache metadata.

An interactive pricing calculator demonstrates how front-end developers can build a component locally and give Drupal editors control over its settings.

With Drupal PIM integration, PIM and ERP own approved product values while Drupal turns them into buyer answers. Define field ownership, synchronization, and outage behavior before building the integration.

Organizations staying on a previous Drupal minor release will have roughly two months after its successor arrives before security coverage ends. The tighter window comes as maintainers confront rising vulnerability reports and shrinking release-management funding.

A Drupal product catalog can help buyers compare specifications and contact sales without a checkout. Here’s how to build it around structured Drupal records instead of PDF files.

I just sent out the Webhaven launch email and every link in it was broken.

The image that I carefully created didn't load, the "Get Webhaven" call to action button went nowhere. A disaster.

To make it even worste all the links were pointing to localhost. This is meme material. I feel ashamed about the situation but I have to accept it and live and learn.

Being on Drupal 11 doesn’t tell you how long your particular release will receive security fixes. A new support policy gives website teams less time to move between minor versions. Here’s what to check and how to make room for that work.

Today we are talking about Drupal 12, Field UI and UX. We'll also cover DruBOM as our module of the week.

For show notes visit: https://www.talkingDrupal.com/577

Topics

• Drupal 12 Release Prep
• Release Cadence Debate
• Field UI Modal UX Issues
• Button Confusion
• Modal UX Patterns
• Evidence Based UX
• Muscle Memory Traps
• Jakobs Law Explained
• Listener Feedback
• PHP Vulnerability Breakdown
• Security Hygiene Automation
• Vendor Module Support

Resources

• Drupal 12 Deprecation Status Summary
• Jakob's law Nielson
• Laws of UX

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Emma Horrell - emma-horrell

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted a full inventory of everything your Drupal site is built from, checked against public security advisories, and exportable as a standard SBOM? There's a module for that.
• Module name/project name:
  • DruBOM - Drupal Bill of Materials (SBOM)
• Brief history
  • How old: created in Oct 2023 by Paolo Mainardi (paolomainardi) of SparkFabrik, and rewritten this fall
  • Versions available: 1.0.0-beta4, which works with Drupal 11.3 and 12
  • Maintainership
  • Actively maintained, latest release and latest commit both just this past Sunday
  • Security coverage: opted in, though there's no stable release yet
  • Test coverage
  • Documentation: an in-depth README, plus separate docs on the advisory sources and on scanning in CI
  • Number of open issues: 4 open issues, none of which are bugs, and one of them is the plan for a stable release
• Usage stats:
  • 9 sites
• Module features and usage
  • SBOM stands for software bill of materials, a list of every component a site is built from, with its version, license, and source. Auditors, security teams, and customers are asking for them more and more
  • DruBOM takes a snapshot that covers the PHP runtime and its extensions, Composer packages, Drupal modules and themes, asset libraries like jQuery and CKEditor 5, and npm, Yarn, and pnpm lockfiles in your themes and modules
  • Anything it can't read shows up as a coverage gap. Gaps are always listed, never hidden
  • Advisory checks are opt-in. You can check against drupal.org security advisories, the Packagist advisory database, OSV.dev for npm, and the PHP project's own advisories
  • Packages from private repositories are never sent out, and you can list private npm scopes to keep them out of advisory checks too
  • Findings that appear in the CISA or ENISA catalogs of known exploited vulnerabilities get flagged and go to the top of the list
  • For each finding you can record a decision on whether your site is actually affected, called a VEX statement. A decision applies only to that exact package version and gets confirmed again after each new snapshot
  • The admin dashboard under Reports has an interactive dependency map, so you can see which Drupal project brought in some deep npm package
  • For CI, drush drubom:check can fail a pipeline when open findings hit a severity threshold, and the export is a standard SPDX 3.0.1 document ready for auditors
  • Under the hood, it's all pure PHP now. The original version wrapped the Syft and Grype binaries, and the rewrite dropped them. Running drush updb saves your old reports as files before removing the old settings
  • There's also a bin/drubom-scan script that builds the SBOM from the codebase files without running any of the site's code. That's useful when an auditor shouldn't have to trust the site, or after a suspected compromise
  • Caveats: you need a private file system, and few security tools read SPDX 3 yet
  • Update Status in core is the obvious comparison. Both tell you when something on your site has a security advisory, but Update Status checks drupal.org release data for Drupal projects only. DruBOM builds its inventory from lockfiles and the codebase, so it also covers Composer, npm, libraries, and PHP, and matches advisories against exact versions

Native Observability started as a way to look inside Drupal with a dashboard of its own: route timings, cache and slow queries, measured by the site and read by a person on an admin page. Now an AI agent reads the same data. Ask Claude Desktop "why is this page slow?" and it fetches the numbers through the Model Context Protocol, read-only.

Handing a model the numbers is not enough, though. It reads them with common sense, and on Drupal metrics common sense fails in specific places. In my first blind comparison, 4 answers out of 5 took a drop caused by the page cache for lost traffic, even with the right instructions in front of them.

Better instructions alone did not fix it. The site now computes the signals the model would get wrong, and explains the rest with a vocabulary checked sentence by sentence against the code. In the last round, with the vocabulary on, Claude reached the right conclusion in 30 answers out of 30.

What leaves the site follows a simpler rule than a list of forbidden words: route names go out, never a URL or a parameter value. This article covers the measurements, the mistakes I found along the way, the questions you can ask and what you need to connect an agent to your own site.

Read more

The best code your AI writes is the code it never has to write. 

When building on top of Drupal there is luckily a lot of that.