Your fields can now think. Route any Drupal field automator through a tool-using AI Agent and let RAG pick the answer.

Take Away Nathaniel Catchpole, Tag1 Senior Performance Engineer and Technical Lead, Drupal core framework and release manager and contributor, walks through how Drupal core's CI pipelines dropped from around 55 minutes to 5 to 7 minutes, and the installer and test optimizations now reducing the CI minutes behind the Drupal Association's infrastructure costs.

At DrupalCon Vienna, Tim Lehnen presented on the main costs for running Drupal.org. Around 50% of the total cost of running drupal.org, or approximately $1.5m, is infrastructure costs. A significant slice of infrastructure costs comes from drupal.org's self-hosted GitLab, and in turn much of that cost is due to GitLab CI for Drupal core and contributed modules.

Figure 1: Drupal Engineering activities compared to the various funding sources

Drupal core is the single biggest project in terms of CI minutes, both due to the sheer number of tests as well as the level of activity in Drupal core issues, with hundreds of commits per month and activity on thousands of issues and Merge Requests ("MRs").

Figure 2: Drupal CI minutes by project, July 2026, core issue forks are treated as separate projects

Since Drupal originally moved to Gitlab CI from our previous Jenkins-based CI infrastructure in 2023, we've been working on reducing the time taken for Drupal core test runs.

The primary end goal of this work was to reduce the wall time for pipelines on MRs. These started at around 55 minutes when we originally moved to Gitlab CI (approximately the same as they were on Drupal CI), and now generally finish in 5-7 minutes. The 55 minute runtimes already relied on previous known optimizations like using a ramdisk for both the database and filesystem, applied to GitLab runners. GitLab does not support this out of the box.

Five minute turnaround times on pipelines have made a huge difference to Drupal core velocity. Whereas core contributors used to push to a branch, then go and eat lunch or dinner while waiting for the pipeline to finish, there's now barely enough time to make a cup of coffee, let alone drink it.

Figure 3: Contibutors recognizing and commenting the time improvement of waiting for the pipeline to finish

However, the bulk of the initial gains we made to core CI pipeline performance was in wall time, with much less impact on CPU minutes. This is now starting to change, as we're finding ways to reduce the CPU minutes while also keeping wall times as short as possible.

Reducing Pipeline Wall Times

We reduced pipeline wall times via the following approaches.

Concurrent Test Running and Parallel CI Jobs

Drupal's run-tests.sh has supported running tests concurrently for a long time. We added support for Gitlab's parallel test runs, splitting test groups with thousands of tests into smaller groups so that they can be run on multiple test runners at once. For example Drupal's functional test group is executed in 8 parallel jobs, at 15 concurrency, with a CPU request of 10 per job. This runs 150 test classes at a time on 100 CPUs. By running smaller sized individual jobs, there is also a higher chance of them fitting into test runners that become available rather than requiring a new AWS instance to be spun up.

Slowest Tests Run First

Tests are always run slowest first. Drupal's test runner has supported a #slow group for a long time, so that very slow tests can be run first. We now also order tests by the number of methods, so that tests with more methods, which overall tend to be slower, run first too. This is critical for other optimizations to be effective. If a single class takes three minutes to run, starting it at the beginning when the rest of the tests can also be completed in three minutes means the entire test run can be finished in three minutes. But if that job started last, the job could take six minutes, with just that one test being run for half the time, leading to slower wall times and idle CPUs.

Optimize or Split Up the Very Slowest Tests

In some cases we have had individual test classes that took more than 10 minutes to run. For these very slow running tests, we've split them into smaller test classes so that they can be run in parallel, and/or optimized the test set-up requirements so that no individual test takes longer than a full run.

Reducing CPU Time for Test Pipelines

With these techniques, we've been able to balance CPU requests and concurrency across the various core test types, so that every job finishes within approximately 3-4 minutes. This has given us a solid framework for keeping pipeline wall times to a minimum while allowing us to adjust CPU requests and concurrency for individual test types to match the scope of core's overall test coverage. As far as we know there are no longer obvious optimizations to make via tweaking concurrency and test running order.

While we've been working on optimizing the tests themselves, in recent months focus is increasingly shifting in that direction as the best way to further optimize test runtimes, but more importantly, reduce CI minutes and the resulting infrastructure cost for the Drupal Association overall.

Test Types

Drupal core started with only one type of test: SimpleTest 'functional tests' that require a full Drupal install into a separate site that the tests are then run against. Over time with the adoption of PHPUnit, we've added unit tests, 'kernel tests' which include a full dependency injection container but don't do a full install, functional JavaScript tests which use a real browser, and build tests which allow creation of a completely separate code base in its own directory. There is an ongoing effort to convert functional tests to kernel and unit tests where this can be done without losing test coverage, with the recent addition of http request testing to kernel tests making many more tests eligible. Converting a functional test to a kernel test can reduce the time it takes by 3/4, so for the tests where this is possible it's one of the most effective ways to make gains, although the conversions have to happen test by test across dozens or hundreds of test classes.

Over the past couple of years there has been a concerted effort to improve Drupal core performance. Many runtime performance improvements don't necessarily make a lot of difference to test runtimes as a whole. But because functional and functional JavaScript tests install a full Drupal site and request real pages, anything which improves installer or cold cache performance tends to have an outsized effect on test runs. Installer performance generally doesn't affect production sites (because they're already installed!) and cold cache performance is often not a priority for production sites because it tends to affect a low percentage of overall requests, however as well as CI times, it can also make huge differences to the user experience for new users as well as improving responsiveness after deployments and cache clears.

Installer Improvements for Functional Tests

In 11.2.0, we changed module install to support installing multiple modules at once without a separate dependency injection container rebuild between each module. Instead of doing 50 or 60 container rebuilds during an install, we do more like 11 or 12. This took tens of seconds off Drupal installs, whether via the UI, Drush, or during test runs.

Figure 4: Installing multiple modules in Drupal 11.2

Source: Figure 4: Installing multiple modules in Drupal 11.2.

In Drupal 11.4, we made container rebuilds during the installer more conditional, reducing container rebuilds during a functional test from 11 to 8.

Recently, I've been looking at whether it would be possible to reduce the 8 remaining container rebuilds further, without necessarily an expectation that there would be much room for improvement, and found some. With all of those changes, some of which are not committed yet, we should be able to get down to an absolute minimum of 2 container rebuilds in tests. While some of the optimizations are test-specific, a real-life Drupal install of the minimal profile takes less than 2 seconds.

This investigation also uncovered further possible performance improvements in the installer.

While the combination of these changes probably saves only around 5 seconds at most from an install during a test run, this saving is multiplied by every install that occurs, with thousands of Drupal installs on every test run, this adds up to several minutes of CI time.

This has already allowed us to reduce the total CPU request for functional tests from 128 to 80 with no increase in wall time. We expect to be able to reduce the CPU request for both functional and functional JavaScript tests further once more optimizations land.

Kernel Test Performance Improvements

Kernel tests in general run much faster than functional tests, however there is still a per-method overhead which is a lot higher than unit tests. We are looking at adding an option to kernel tests to share the database state between test methods which will remove a lot of that overhead. This in turn will allow us to re-use the dependency injection container between methods. As we move functional tests to kernel tests, this should increase the impact of that change on resource usage even more.

Re-Evaluating On-Commit Pipelines

Drupal core has daily, weekly, and on-commit jobs on its branches, as well as those that run on individual MRs. In looking at the information we get from those jobs, we realised that the on-commit jobs, which on average run several times per day, and run the full test suite against multiple different database types (Mysql, MariaDB, SQlite, PostgreSQL) don't necessarily give us information that we can't otherwise get from MR, daily and weekly runs. For release branches, we need immediate post-commit feedback in case something is unexpectedly broken, which sometimes happens when two independent commits are fine individually, don't have merge conflicts, but break when combined anyway. However, we're in the process of trialling running our development branches without on-commit pipelines whatsoever. This should reduce CI minutes for core purely via running pipelines less often, on top of the in-pipeline optimizations above.

Reducing Wall Time for Contrib CI Runs

While individual contrib projects are not the biggest user of CI minutes, there are thousands of contributed projects. Several of the performance optimizations for the installer, functional tests, and kernel tests will apply to contributed module tests too, since those have to install core the same way as core tests do.

Additionally, there has been recent work to switch contrib's gitlab_templates shared pipeline definitions to running concurrent tests by default. Contrib tests previously used raw phpunit which runs each test sequentially with an option to switch to concurrent test running via run-tests.sh; the default flipped to run-tests.sh by default in September 2026. Because contrib tests should also benefit from core's 'slowest test first' strategy, this should compress pipeline times in contrib and it may have a positive impact in reducing CI minutes overall if runners are able to complete jobs in a shorter time with the same CPU request.

Effect on the Drupal Association's Hosting Costs

Taken together, these changes lower the cost of running core's CI run by run, through shorter wall times, fewer CPU minutes, and fewer pipelines overall. As Figure 2 shows, core is the single biggest consumer of CI minutes on drupal.org, so that work is aimed at the largest single driver of the GitLab CI costs behind the Drupal Association's infrastructure bill.

What that adds up to on the bill itself is a separate measurement, and will take longer to validate. Total cost depends not only on the cost per run but on how many runs happen, and core activity (commits, issues, and merge requests) is holding steady or rising. So the effect on the DA's hosting costs has to be read from same-month comparisons year over year, or averages across several months, rather than any single snapshot. We’ll be keeping a close eye on this as the latest round of changes are committed.

Written by Duncan Worrell (dunx)

DrupalCon Rotterdam is almost here. Alongside two dedicated AI summits and the main conference keynote, the program is stacked with high-value AI content for developers, strategists, and leaders alike. Whether you're looking to push agentic workflows, scale digital governance, streamline content operations, or keep your AI integrations trustworthy, here is a complete breakdown of the top AI sessions to help you optimize your schedule.

Full schedule at https://events.drupal.org/rotterdam2026/schedule
Tickets at https://events.drupal.org/rotterdam2026/registration-information

All session times are local CEST.

Summits

In addition to the main DrupalCon event, there are two AI-specific summits being held catering for two very different audiences.

Enterprise Drupal AI Summit

An executive-focused event for CXOs, Heads of Digital, and enterprise leaders connecting with curated Drupal AI partners. Hosted on the historic former ocean liner, SS Rotterdam. 

Date & Time: All day Monday, 28 September
Event details here: https://summit.enterprisedrupal.eu/schedule.html

AI Dev Summit

Getting Drupal developers up to speed on AI coding tools, AI in PHP/Symfony/Drupal frameworks, Canvas, and Drupal CMS innovations.

Date & Time: All day Monday, 28 September
Event details here: https://events.drupal.org/rotterdam2026/ai-dev-summit

Keynote

For many, the DriesNote by Drupal founder Dries Buytaert is the week’s highlight. Expect a keynote packed with the latest AI roadmap updates, architectural reveals, and live technical demos.

Date & Time: Tuesday, September 29, 2026 - 10:30 to 11:45

DriesNote will live stream on YouTube if you can’t make the event in person.

Sessions

Every session is likely to mention “AI” but we expect these sessions to be focused on AI. 

Unblocking AI: Why Programmes Stall at Pilot Stage, and How to Move Past It

Research and strategies for moving AI initiatives past the pilot phase to deliver real-world impact.

Date & Time: Tuesday, 29 September 2026, 13:00 – 13:10
Speakers: Amanda Falshaw (AI Enablement Lead at Reading Room) & Megan Harvey (Reading Room)

Open Intranet: A Drupal-Based Digital Workplace

Features AI-assisted content creation as part of an open-source Drupal intranet workspace.

Date & Time: Tuesday, 29 September 2026, 13:15 – 13:25  
Speaker: Maciej Łukiański (CEO and Co-founder of Droptica)

Culture Mapping the Human Side of AI — A Workshop to Meet Your People Where They Are

Leadership and organizational change management required to guide teams through fast-moving AI adoption.

Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15  
Speaker: Timi Csontos (Culture Consultant/Freelygive)

Reviewer-Friendly AI: A Practical Drupal Contribution Workshop

Practical AI-assisted workflows designed to turn ideas into high-quality, review-ready open-source contributions.

Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15  
Speaker: Scott Falconer (Senior Principal Software Engineer at Acquia)

Why Your AI Agent Hallucinates: Engineering Lessons From a Production Workflow Builder in Drupal

Engineering reliable, trustworthy AI agent integrations in Drupal using modules like AI, ECA, and agentic tools.

Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15  
Speaker: Shibin Devadas Kakanat (Backend Pro Lead at Factorial)

Context Control Center: Bringing AI Context Natively to Drupal CMS

Structuring, scoping, and natively managing AI context within Drupal CMS for downstream agents and tools.

Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10  
Speakers: Emma Horrell (User Experience Manager University of Edinburgh and UX Research Lead for Drupal CMS) & James Abrahams (Technical Director at Freelygive)

Encoding Expertise: How UX Research Powers Human-First AI

Applying UX research methods to train and ground AI content tools to output domain-specific quality.

Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10  
Speaker: Aidan Foster (Senior UX Strategist at Kanopi Studios)

From Shadow AI to Sovereign AI Infrastructure

Addressing data security, compliance, provider selection, and cost control as AI adoption scales.

Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10  
Speaker: Michael Schmid (Head of Technology and Co-Founder of amazee.io)

AI-assisted site migration to Drupal Canvas: a real-world case study

Testing AI coding agents on live projects to automate complex site migrations into Drupal Canvas, examining real metrics, wins, and limitations.

Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30  
Speakers: Wolfgang Ziegler (Architect, Founder of drunomics) & Jeremy Chinquist (Project Manager at drunomics)

AI-Augmented Accessibility: From Automated Alt-Text to Governance Gates

Automating inclusive governance and identifying accessibility errors early by bridging code, humans, and AI workflows.

Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30  
Speaker: Mike Gifford (Senior Accessibility Strategist at CivicActions)

Nobody Asked for a CMS: From Content Management to Answer Delivery in the Age of AI

Adapting content architecture for direct answer delivery to AI systems while increasing Drupal’s strategic value.

Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30  
Speakers: Tomi Mikola & Ulla Koho (both digital strategists and content architects at Wunder)

Clean Code in the Age of AI: Writing for Humans When Machines Write the Code

Maintaining human readability, software architecture, and clean code standards when using AI generators.

Date & Time: Wednesday, 30 September 2026, 11:40 – 12:25  
Speaker: Len Swaneveld (Senior Drupal Developer at iO)

One Brand Voice from 35 Sources: How We Rebuilt VisitEurope.com and How Drupal AI Unifies Its Tone

Unifying 35 national voices into a cohesive travel brand using generative AI integrated into Drupal.

Date & Time: Wednesday, 30 September 2026, 11:40 – 12:25  
Speakers: Krisztián Kása & Zsófia Alföldi (both Project Managers at Brainsum)

AI Best Practises

Leveraging Drupal’s structured architecture to build optimized environments for AI Agents running inside and outside CMS boundaries.

Date & Time: Wednesday, 30 September 2026, 12:30 – 12:40  
Speaker: James Abrahams (Technical Director at Freelygive)

The New Front Door: How AI Agents Are Driving Drupal's Growth

How autonomous AI agents act as primary decision-makers selecting, building, and verifying Drupal systems.

Date & Time: Wednesday, 30 September 2026, 12:45 – 13:30  
Speaker: Scott Falconer (Senior Principal Software Engineer at Acquia)

Drupal AI Product Update: From Foundation to Agentic Workflows

Official product update from the Drupal AI Initiative leadership on building production-ready Agentic CMS capabilities.

Date & Time: Wednesday, 30 September 2026, 13:40 – 14:25  
Speakers: Niels Aers (CTO/AI Tech Lead at Dropsolid) & Dr. Christoph Breidert (CEO and Founder of 1xINTERNET)

From Brief to Review-Ready in 60 Minutes: A Governed AI Campaign Workflow in Drupal 11

Generating governed, high-quality draft campaign pages straight from PDF briefs in minutes without code tickets.

Date & Time: Wednesday, 30 September 2026, 13:40 – 14:00  
Speaker: Kieran Cott (Executive Creative Technology Director at Delete Agency)

How can we improve Drupal's visibility in ChatGPT, Gemini, and Claude?

Open discussion on improving how LLMs describe, evaluate, and recommend Drupal to users.

Date & Time: Wednesday, 30 September 2026, 13:40 – 14:25  
Speaker: Larissa Tropp (Digital Marketing & Growth Specialist at 1xINTERNET)

Dismantling and Reassembling a Drupal Migration with AI

Leveraging AI tools to simplify, re-architect, and map legacy un-typed data into clean destination bundles during migrations.

Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30  
Speaker: Roberto Peruzzo (Principal Architect and Founder of Sparklingboys)

AI Mid-Life Crisis: failure stories from the silent majority

Honest post-mortems on AI project failures and pragmatic ways to navigate rapid technological shifts.

Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30  
Speakers: Dieter Blomme (Drupal Architect at Dropsolid) & Valery Lourie (Lead Software Engineer at EPAM Systems)

Scolta: Drop-in AI Search Without a Search Server

Running lightweight, client-side search powered by Pagefind with an AI layer for query expansion and summaries.

Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30  
Speaker: Jeremy Andrews (CEO and Founder of Tag1 Consulting)

SDCs, Canvas, and the Agent That Builds With Them

Training AI agents to generate Single Directory Components, insert them into pages, and verify browser rendering.

Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30  
Speaker: Matt Glaman (Principal Software Engineer at Acquia)

AI Assists, Humans Decide: Agentic Workflows in Drupal - A Drupal AI Hackathon Story

Agentic translation and governance workflows developed for the European Commission across 24 languages.

Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45  
Speakers: David Galeano & Adam Nagy (both work in the DIGIT department at the European Commission)

AI-Powered Site Building in Drupal: From Blank Site to Styled Pages in a Conversation

Enabling non-technical users to build, style, and structure complete Drupal sites via conversational prompts.

Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45  
Speakers: Francesco Pesenti & Francesco Quagliati (both are Developer Advocates and Solution Engineers at Platform.sh)

From Drupal Content to AI Answers: Learnings from EPSY

Designing constrained AI search engines over standard chatbots to deliver structured content answers.

Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45  
Speaker: Antonella Picarella (Head of Digital Communications & Content Strategy at BFF Banking Group)

From SEO to GEO: What Changes, What Doesn’t

Strategic shifts from Search Engine Optimization to Generative Engine Optimization as AI engines handle discovery.

Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45  
Speaker: Wouter De Bruycker (Digital Marketing Strategist at Dropsolid)

From local voices to global impact: Powering World Cancer Day with Drupal and AI

Translating and moderating hundreds of high-volume personal stories across 60+ languages using AI tools.

Date & Time: Wednesday, 30 September 2026, 17:00 – 17:45  
Speakers: Charles Andrew Revkin & Diego Fernando Costa (both part of the digital communications team at the Union for International Cancer Control (UICC), which runs World Cancer Day)

How Marketers Win in an AI‑First Search World (AEO & GEO Playbook)

Practical tactics for Answer Engine Optimization (AEO) and maintaining content discoverability in AI platforms.

Date & Time: Wednesday, 30 September 2026, 17:00 – 17:45  
Speakers: Reena Tripathi (Digital Marketing Manager at OpenSense Labs) & Anubhav Gupta (CEO/Technical Architect at OpenSense Labs)

Whether you’re coming to DrupalCon Rotterdam to build with AI, figure out how to govern it, or understand where it is taking Drupal next, there is a lot to choose from. From the two Monday summits through the DriesNote and a packed slate of sessions, AI is clearly woven throughout this year’s programme. Check the full schedule, plan around the sessions that matter most to you, and we’ll see you in Rotterdam.

File attachments:  DrupalCon_Rotterdam_2026___Drupal_Events.png

Project: Drupal coreProject machine name: drupalDate: 2026-September-16Security risk: Moderately critical 13 ∕ 25 AC:Basic/A:User/CI:Some/II:Some/E:Theoretical/TD:DefaultVulnerability: Third-party librariesAffected versions: >=10.5.0 <10.6.17 || >=11.0.0 <11.3.17 || >=11.4.0 <11.4.7Description: 

The Drupal project uses the CKEditor library for WYSIWYG editing. CKEditor has released a security update that impacts Drupal.

Vulnerabilities are possible if Drupal is configured to use CKEditor for WYSIWYG editing. An attacker that can create or edit content (even without access to CKEditor themselves) may be able to exploit this Cross-Site Scripting (XSS) vulnerability to target users with access to the WYSIWYG CKEditor, including site admins with privileged access.

For more information, see CKEditor's security advisory:

• High-severity Cross-site scripting (XSS) in the engine package

Solution: 

Install the latest version:

Drupal 11

• If you use Drupal 11.4.x, update to Drupal 11.4.7.
• If you use Drupal 11.3.x, update to Drupal 11.3.17.
• Drupal 11.2.x and below are end-of-life and do not receive security coverage.

Drupal 10

• If you use Drupal 10.6.x, update to Drupal 10.6.17.
• Drupal 10.5.x and below are end-of-life and do not receive security coverage.

Note that Drupal 8 and Drupal 9 have both reached end-of-life.

Instructions for contributed modules

Site owners should also review their site following the protocol for managing external libraries and plugins, as contributed projects may use additional CKEditor plugins not packaged in Drupal core.

CKEditor has also released another CVE in today's release that does not affect Drupal, but may affect custom plugins or other usecases:

• Low-severity Cross-site scripting (XSS) in the engine package

Reported By: 

• Piotrek Koszuliński (Reinmar)

Fixed By: 

• catch (catch) of the Drupal Security Team
• Lee Rowlands (larowlan) of the Drupal Security Team
• Mohit Aghera (mohit_aghera), provisional member of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

Coordinated By: 

• Bram Driesen (bramdriesen) of the Drupal Security Team
• catch (catch) of the Drupal Security Team
• Greg Knaddison (greggles) of the Drupal Security Team
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

Everybody Orchestrates. Most Do It by Hand. Photo by Giorgio Tomassetti on Unsplash Jürgen Haas Wed 16 Sep 2026 - 12:15

Every month I do my agency's billing by hand: export timesheets from one system, create invoices in another, merge, email, file, upload to the accountant. I maintain ECA. Elsewhere, a multi-agency project runs from an Excel sheet nobody can keep current, because the spreadsheet is the only place people see everything and feel in control. Everybody orchestrates, most by hand, and not for lack of tools. ECA, Maestro, FlowDrop, Tool API, AI Integration - ECA 1.0.0 and the Orchestration module with Activepieces, soon n8n, could run my billing end to end today. But the builder opens five UIs and, worse, has to decide which engine runs which step. No user can make that decision. The fix is one UI: every component of every participating system on one canvas, engine routing done by the platform. The Modeler API, the Workflow Modeler, Tool API's typed contract and Post 6's shared vocabulary are that architecture. Missing: a composite model owner, a dispatcher, the cross-system data contract. Let's build them. In Drupal.

Credentials still travel by email and by Slack on projects that are otherwise carefully built. Every integration with an external service needs them, and forwarding them from one party to the next is so routine that the risk rarely gets questioned. That habit is avoidable, and avoiding it changes who holds the secrets and who never has to see them.

The habit of sharing passwords over email or Slack

Receiving a password in plain text over email or Slack is a common occurrence on any Drupal project. It happens because every integration with an external service, whether a payment gateway, a CRM, or a third-party API, requires access credentials. Username and password pairs, tokens, private URLs, and other sensitive data that at some point need to travel from one place to another.

These credentials should never go into a code repository or into Drupal's YAML configuration files. The exposure risk is too high. The most common alternative, however, does not solve the underlying problem.

The burden of provisioning credentials in a project

The most widespread practice is to store secrets in a file outside the webroot, or to define them as environment variables accessible only to PHP. This works, but carries an operational cost that becomes apparent as soon as a password needs to change: those files must be edited by hand, and if environment variables are used, reloading Apache or Nginx may be required.

The deeper problem is the…

One rulebook for your AI: make every generated intro, summary and alt text follow the exact same governance as your chatbot.

Drupal 10 reaches end of life on 9 December 2026. Drupal 12 is planned for the same week. Our recommendation for Drupal 10 site owners is to start the Drupal 11 upgrade now instead of building the whole plan around a new release. Release week leaves no room for discovery As of 16 September, the official Drupal release schedule places Drupal 12 in the week of 7 December. Drupal 10 reaches end of life on 9 December. A planned release date does not promise that every module your site needs will be ready that day. Waiting until December to attempt an upgrade combines two problems: evaluating a new major version and dealing with the end of support for the existing one. Drupal 11 is already available for a trial upgrade. Our Drupal 10 end-of-life article covers the readiness checks. This…

Choosing between monolithic, decoupled, and hybrid Drupal should start with publishing cost - not a frontend framework preference.

Drupal architecture determines how many systems your team must maintain to deliver server-rendered HTML that readers and AI crawlers can use on the first response. Here is how to compare the three options by preview, metadata, cache invalidation, and operating work.

Joomla 3 has been unsupported since 2023. An honest look at the three destinations — Joomla 5, WordPress or Drupal — what actually breaks, and what it costs.

Join us THURSDAY, September 17 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone.

Information on joining the meeting can be found in our collaborative Google document.

The safest way to add JSON-LD to Drupal is to map Schema.org properties to existing content fields with Metatag and Schema.org Metatag.

JSON-LD in Drupal should come from the same field model that supplies the visible page - not from hand-written scripts that drift when prices or availability change. Here is how to map tokens, export config, validate rendered pages, and catch missing bundles in CI.

Drupal Code Search now index recipes

Made it easier to get a list of projects that are included in a particular recipe. It's thanks to the sponsorship of Vardot, and previously Palantir.net that I'm able to spend time on tooling for the community. Many thanks to them.

Code search:

theodore September 15, 2026

Wondering why Drupal needs another page builder? Here's what I learned installing Drupal Canvas, exposing my SDCs, and writing React right in the browser.

Architecting a Headless RAG Engine with Drupal 11 bhavinhjoshi Tue, 09/15/2026 - 12:28

Drupal 11 is evolving into something far more powerful than a traditional Content Management System. For enterprise organizations, it is quickly becoming the foundational vector engine for secure, sovereign AI.

As organizations move beyond the hype of basic generative AI, the limitations of standard API wrappers become clear. Bolting a conversational UI onto a monolithic frontend, and blindly passing proprietary node data to public third-party models, introduces unpredictable latency, unmanageable token costs, and critical data compliance risks.

The Core Architectural Dilemma

When an organization attempts to integrate AI without a solid architectural foundation, the implementation typically fails through three specific avenues:

• The "Wrapper Module" Trap: Teams prioritize speed by installing pre-built chat widgets that pass unvetted, sensitive node data directly to external public APIs like OpenAI or Anthropic, compromising data sovereignty.
• The Fixed-Token Chunking Flaw: Scraping rendered HTML and relying on basic character-count chunking destroys semantic meaning, splitting context mid-sentence and returning poor vector matches.
• The SaaS Dependency: Relying on external, cloud-based vector databases creates a secondary point of failure and pulls proprietary organizational knowledge outside the compliant corporate network boundary.

The Headless RAG Solution

Many organizations view basic LLM integration as a complete AI strategy. They assume that passing a system prompt with full node text is sufficient for enterprise intelligence.

This is a mistake.

If an organization lacks the data governance to secure its AI pipeline, it will inevitably expose sensitive IP and face spiraling API costs. True digital sovereignty requires architecting native Retrieval-Augmented Generation (RAG) directly into your core infrastructure.

Engineering the Pipeline: A New Standard

To ensure the security and longevity of an enterprise AI implementation, organizations must shift from a "plugin" mindset to an "engineering-infrastructure" mindset:

• Vectorize the Entity API: Intercept entity events (nodes, taxonomy, media) at creation. Extract plain text from field data and attachments before the content is ever rendered to a frontend.
• Intelligent Ingestion & Chunking: Integrate Python and LangChain workers to handle semantic chunking strategies, ensuring extracted text is grouped into logical, context-rich units before vectorization.
• Native Vector Storage: Utilize PostgreSQL with the open-source pgvector extension to store high-dimensional embeddings natively alongside standard relational data, effectively air-gapping your intelligence layer.
• The Decoupled AI Endpoint: Expose the RAG pipeline as an authenticated, rate-limited HTTP endpoint (a JSON:API for AI) so any decoupled application can securely access grounded intelligence.

Final Thoughts

By treating AI not as a third-party plugin, but as core data architecture, Drupal 11 transitions from managing content to orchestrating enterprise intelligence. Stop treating AI as a shiny widget, and start building secure RAG infrastructure.

We don't believe in bolting on off-the-shelf wrappers. We believe in engineering systems that respect your investment and secure your data. If you are exploring enterprise AI, we approach architecture differently.

Drupal Drupal AI Drupal 11 Drupal Planet Share this Copied to clipboard Add new comment

Your AI chatbot is making up its own rules. Here's how to make every answer follow yours instead.

Today Acquia launched a new brand, and my favorite part is the updated logo. Right under the Acquia name, it now says "Powered by Drupal".

Drupal has always been at the core of Acquia, but for the past 5 years it was less visible in how we described ourselves. Now it's front and center again.

But that is not the main reason for the rebrand. The bigger reason for the rebrand is to help people see what Acquia has become. Our products have evolved faster than awareness of them.

The new brand leads with content instead of digital experiences, and the homepage calls Acquia an "agentic content platform" rather than a "digital experience platform".

Acquia Source is our new command center, bringing content management, digital asset management, and web governance into one workspace. Acquia AI coordinates agent work across those tools.

For agents to work safely across these tools, they need content they can trust and clear rules for using it. Somebody still has to decide what is approved, who can use it, and where it can go. I wrote about that in AI and the great CMS unbundling, and the new brand puts that idea at the center of our story.

Drupal is well suited for that job. Structured content, granular permissions, workflows, and revision history are the things agents need to work safely, and Drupal has refined them for years.

Customers can use Acquia Source CMS, our fully managed Drupal SaaS offering. For teams that want full control over their Drupal sites, we offer Acquia Cloud. Acquia Source brings sites on either platform into a shared workspace.

As you scroll the new homepage, it builds up our technology stack one layer at a time, starting from Drupal.

Acquia leaning into Drupal is also good news for Drupal itself. It helps close the gap between Drupal and its reputation. Drupal is still often seen as a CMS that requires a developer for everything, even as improvements in recent years have made it easier for marketers to build pages and manage content themselves.

So alongside the new brand, we'll be investing more in helping the Drupal community evangelize Drupal, reaching developers and marketing leaders who may not have looked at it in years. I want more people to see what Drupal has become.

Your next campaign launch does not have to stall on the landing page. You describe it the way you would brief an agency (audience, goal, story, call to action), and minutes later a production-ready page sits in your own Drupal site, built only from your organization's approved components, on brand and accessible from the first draft, ready to publish the same day.

Most articles with this title are written by Drupal shops. We build on both platforms, so here is the honest version: the four situations where Drupal genuinely wins, what actually moves versus what gets rebuilt, and why most WordPress sites should stay where they are.