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.

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.

Drupal's emerging agent interfaces are beginning to expose actions as well as information. MCPIO 1.0.0-alpha1 presents external Model Context Protocol clients with two entry points, search and execute, through which they can discover and invoke a wider set of Drupal operations. WebMCP User Forms takes a different route, adding WebMCP-style tool metadata to Drupal's login, password-reset, and registration forms so browser agents can identify their inputs more explicitly. These are different interfaces, but both make capabilities that were designed primarily for people or Drupal code more legible to automated actors.

Once a capability becomes callable, the harder question is not simply whether an agent can find it. Will Huggins' argument about Drupal publishing capabilities puts authentication, permissions, workflow, guardrails, and controlled context alongside the interface itself. In that model, an agent-facing tool should not create a route around Drupal's existing governance controls; the authority to perform an action still has to come from an identified actor with defined access.

The current projects do not establish one settled architecture for doing this. MCPIO remains an alpha release and is not covered by Drupal's security advisory policy, while WebMCP User Forms is also an alpha project outside that coverage. MCP, WebMCP, Tool API, and other agent-facing approaches also operate at different layers, from external protocol clients to capabilities exposed inside a browser. That distinction matters because making an operation discoverable is not the same as deciding who may execute it.

Issue 36 of Editor's Pick looked at a broader requirement for machine-facing websites: meaning must be explicit, access constrained, and important rules represented in ways software does not have to infer from prose. The next question is narrower. As Drupal makes more capabilities available to agents, interface design and permission design begin to meet at the same boundary: which actor is represented, which actions that actor may invoke, and which Drupal controls remain in force when the request comes from software rather than a person. The implementations are still emerging, but that authority boundary is becoming harder to treat as a secondary concern.

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

This issue of Editor’s Pick was written and curated by Allen Jason.

Generating software is becoming easier. Knowing what went into it, whether it can be trusted, and who will maintain it is becoming the harder problem.

Using AI to review AI-Generated code: Astra vs. Opus vs. DeepSeek John Locke Sun, 09/13/2026 - 19:00 Astra built an impressive amount of working code, but missed serious performance problems. DeepSeek found several of them for 22 cents. Opus cost dramatically more and found a substantially different set of problems, especially around UI and accessibility. Dev Corner

• Read more about Using AI to review AI-Generated code: Astra vs. Opus vs. DeepSeek
• Add new comment

Handing an outside developer your one and only SSH login because the job was one theme on one site is the oldest mistake in hosting, and the collaborator button on the big platforms only hides the question of what that seat can actually do. On a BOA server a Client, the control panel's word for the person a site belongs to, gets its own limited login built automatically, one which sees that Client's sites and their files and nothing else; and now your host can turn on a second login of the platform kind for that Client, which reaches the whole codebase of every platform whose sites are all the Client's, with Composer and the Drush shipped inside the platform, and refuses any platform where somebody else's site is parked as well. The grant is decided by root from one line, re-derived every three minutes and readable in one file and one log; Drupal 8 and newer platforms are unlocked for the developer an hour at a time, on request, and locked back by themselves.

Some of the hardest technology failures arrive without a broken component or a clear error. Two DrupalCamp Poland speakers examine what teams can learn from convincing AI mistakes, system-level performance failures, and automation that still depends on human judgement.

Rebuilding a data-driven Drupal site: Separating data objects from pages

In the previous post in this series, I described how we rebuilt our page templates with Layout Builder. I ended that post by mentioning that templates are less suitable when the page hierarchy must be derived from the data itself.

To explain that part of the rebuild, it helps to look at a more basic change. In the Drupal 7 site, an imported data object and the page that presented it were the same node, whereas the rebuilt site stores them as separate entities.

berliner Fri, 09/11/2026 - 11:07 Tags

• architecture
• migrations
• layout builder
• blocks
• content entities

Is Drupal outdated? Ask around and you might get a confident yes. Sitback developer Max spent a free weekend designing his ideal CMS from scratch, to work out what he’d build instead. Step one: build your own CMS, how hard can it be? Right. That’s it. I’ve had enough of legacy CMSes. Bloated, over-engineered, designed ...

On today's show we are talking about Site Templates, What they do, and How you can use them with guests Tim Lehnen & Adam Globus-Hoenich. We'll also cover Haven as our module of the week.

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

Topics

• MOTW: Haven
• What Site Templates Are
• Canvas Components Included
• Promoting Templates Beyond Drupal
• Templates vs Distributions
• Who Benefits from Templates
• Template Types and Adoption
• Where to Find Templates
• Featured vs Installer List
• Free vs Paid Templates
• Recipes vs Templates
• Distributions and Themes
• Empowering Site Builders
• Exporting a Template
• Designing for Users
• Releases Without Upgrades
• Best Practices and AI
• How to Contribute

Resources

Webinar: Drupal Canvas and Agentic Content Management: What Enterprise Teams Need to Know Drupal Site Templates Tim's book - Fog & Fireflies

Guests

Tim Lehnen - @TimLehnen hestenet

Adam Globus-Hoenich - @PhenaProxima phenaproxima

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan Stephen Cross - SecondSginalMedia.com [stephencross]](https://www.drupal.org/u/stephencross) Amber Matz - tugboatqa.com [amber himes matz](https://www.drupal.org/u/amber himes matz)

Module of the Week Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

Haven - Site Template - Designed for non-profit sites, this template features a bright, warm design that can be adapted for many use cases. It comes pre-confifgured with blog, projects and people profiles, as well as newsletter signup, donation add-ons and more.

Register for our next webinar to see a live demonstration of Centarro Bootstrap.

Every new theme for a Drupal Commerce project starts with the same sequence: define your colors, configure button styles, set typography, style your forms, change icons, and then wire all of it into whatever page-building paradigm Drupal currently offers.

After twelve years, our front-end team accumulated a long list of friction points and recurring tasks. Centarro Bootstrap is the result of addressing all of them in a single, reusable foundation. What used to take weeks of custom theming can now be accomplished in hours.

The problem Centarro Bootstrap solves

Beyond making it faster and simpler to complete repetitive theming tasks that every custom Drupal website must perform, Centarro Bootstrap also helps with dynamic page layouts.

Drupal has gone through several iterations of page builders, both as contrib modules and part of Drupal core. Canvas is the current tool, which brings a Figma-like experience. Users can place components directly on a page, compose layouts visually, and see immediate results. Content teams can create single-use content straight from the interface.

Read more

Putting paths first: Views support for path alias entities

On a recent project, I was struck by how the content editors used spreadsheets to manage their content. This wasn't just as a planning tool in the early stages; they had spreadsheets which essentially mirrored the content in Drupal, and this is where they kept track of who was responsible for sign-off on a piece of content, what stage it was at, and so on.

Leaving aside for a future post or many the matter that if editors are needing to use spreadsheets to manage their content, it doesn't speak well of the 'M' part of the CMS and that there are surely things we need to improve in Drupal, one thing I noticed was how content was listed.

The main identifier of content, the first column in the spreadsheet, wasn't the title, or the node ID, but the path. To these editors, the path was the starting point, it represented that piece of content.

This is completely add odds with how Drupal treats paths. Paths in Drupal are like an afterthought: tacked onto entities as second-class citizens. They're not even shown in the content admin pages, you're left to discover them for yourself by hovering over the content link.

But what if we could change that, and put path aliases first? What if we could make Drupal list content in the same way that these users have in their spreadsheets? It would be a first step in providing the sort of content overview and administration tools that Drupal is currently lacking for these users. Other things are needed too, such as a sign-off user content, and more complex statuses. But paths are the starting point.

Unfortunately, the flexibility of Drupal's path system is actually a problem here: paths aren't just for entities, and an alias can be for any system path. So there's no connection in the database from the path alias to the entity it points to, and there's nothing on the entity either: the path alias field you see on a node is a computed value, obtained by querying the path_alias table for the node's canonical path.

Of course, this doesn't stop SQL: you can join two tables on anything, and Views provides a 'join' plugin type precisely for these sorts of weird cases.

So we can define Views relationships from the path_alias entity type to all content entity types, using our special join plugin. The join clause then looks like this for nodes:

... JOIN node ON SUBSTRING(path_alias.path FROM 1 FOR 5) = 'node/' AND SUBSTRING(path_alias.path FROM 6) = node.nid

What that's saying is that we only join if the path alias's real path starts with 'node/' and we join the numeric suffix to the node table row of the same value. We need the first part so that we don't join an alias for 'media/42' to node 42.

With this, we can make an admin view of nodes listed by their path aliases, with all the same features as the default Content admin view:

And the wrapped up result is the Path Alias Views module, which provides the integration to show path aliases in Views: fields, sort orders, and filters.

The Views relationship is generalised to work for any content entity type that has a canonical path of the form 'something/ID'. If your custom entity type does something weird with its canonical paths (such as include the ID of a parent entity; I've done that myself with custom entity types), then you can use hook_views_data_alter() to change the relationship from path_alias entities to your entities, so that it uses your own custom Views join plugin.

The view shown in the screenshot is installed as default config, and if you also install the Client-side Hierarchical Select module, a more souped-up path component filter allows you to select the path prefix to filter on one path component at a time.

This can be used as a drop-in replacement for the default core Content Admin view, though of course it will only show nodes that have a path alias.

I'm sure there are other ways of showing paths. Replacing the URL aliases admin page with a view would be one. Reverse relationships from entity types to path aliases would open up other possibilities too. I'll be interested to see what people come up with this: do please let me know on Mastodon, in Slack, or in MRs in the issue queue.

Do you need help with doing something unspeakably twisted with Views queries? I've had plenty of experience with this sort of customisation, and I'm available for hire - contact me!

joachim Thu, 10/09/2026 - 12:56 Tags

• contrib module
• views

Open Source projects have spent decades asking companies to contribute. Projects should also give buyers the information they need to reward the companies that do.

Any Open Source project with a commercial or institutional funding ecosystem should publish an official contribution record: who contributes, how much and over what period, what kind of work they do, which parts of the project they work on, and, where disclosed, who paid for the work.

The test for a good record is simple. A buyer should be able to answer three questions in about a minute: does this vendor contribute at all, how much do they contribute compared to other vendors, and do they work on the parts of the project I care about?

Contribution does not prove that a vendor can deliver. It is one procurement factor alongside delivery capability, expertise, and price. It matters because some buyers want the money they already spend on Open Source services to help maintain the software they depend on.

Vendors that pay people to do that work carry costs that others avoid, and some of those costs may appear in their rates. A price comparison that ignores those costs can put contributing vendors at a disadvantage. I've argued that procurement should score contribution alongside price. APELL, the European Open Source Software Business Association, has also asked the EU to consider a provider's record of Open Source contribution.

Vendor claims are hard to verify and compare

Say you need a vendor for your Drupal site, your Kubernetes cluster, or whatever Open Source software you use, and two firms bid. Both say they're deeply involved in the project, and both might be telling the truth by their own definition of "involved".

Without a project record, verifying those claims often means reconstructing each vendor's contribution history yourself.

The code repository seems like the obvious place to start, but even counting commits by vendor is not simple. A project has to connect individual contributors to the organizations that employed or funded their work, and those relationships can change over time.

More importantly, Open Source contribution can include documentation, support, event organization, governance work, promotion, and more. Much of that work happens outside the code repository or isn't recorded in a form a buyer can easily interpret.

Projects decide which contributions matter

Drupal has tracked contribution credits since 2015, following a method I proposed in 2014 and now governed by the Drupal Association. Its system records more than code and gives credit not only to individual contributors, but also to the organizations and customers that fund their work.

Not every contribution counts the same. A contribution to Drupal Core or a strategic initiative earns more credit than one to a module that few sites use, and work on contributed projects counts for more when more sites depend on them.

Raw contribution data does not tell buyers which work matters most to the project. The project has the context to decide what advances its priorities and how different contributions should be weighted. Its record should publish those rules, link to the underlying contributions, and explain how mistakes or disputes are corrected. Buyers can then decide how much that record matters for a particular purchase.

Drupal has a strong foundation, and credits feed the Drupal.org marketplace where buyers compare agencies, but I'm not sure we could answer all three questions in sixty seconds today. We still have work to do to make the record easier to find, understand, and compare.

Projects can start with a simple record

Not every project needs a system as elaborate as Drupal's. A small project could begin with a short list: who its recognized organizational contributors are and what they worked on. A text file in the official repository can be enough for a first version.

More complex ecosystems may need separate categories or weighted comparisons. Whatever form it takes, the record has to be easy to find and quick to use.

So if you maintain an Open Source project with a commercial or institutional funding ecosystem, start publishing a contribution record and improve it over time. If you buy services built on Open Source, ask for the project's contribution record. Decide at the start how contribution should count in your purchasing decision, then check bidder claims against the record. If you fund Open Source, use the record to find contributors working on the parts of the project you want to support.

Where buyers can consider contribution, I expect projects with clear records to see more commercial opportunities go to their maintainers than projects that rely on appeals alone.

Special thanks to Henry Poole for his contributions to this blog post, and to Sachiko Muto, Tiffany Farriss, Tim Lehnen and Amandine Le Pape for their review.

Read one night of a Drupal or Backdrop site's log and most of it had no business with that site: WordPress login probes on a site which never ran WordPress, fishing for secret files, a thousand pages nobody ever made, from about as many addresses, one request apiece. On an ordinary server each of them wakes PHP for a not-found page, until no worker is free and your real visitors see an error instead of the site. On a BOA server those shapes are refused inside the web server before PHP or the database are consulted, the connection closed for what is only ever abuse, a cheap static not-found where a real page could once in a while match; the rest is judged afterwards by what an address did, a fleet by the share of failures it collects, the search engines whitelisted before anyone is banned; and during a swarm nobody can classify, each site keeps a limit on uncached renders so the cache answers everybody else. A block lasts about a quarter of an hour and lifts on its own.

AI is changing how people build, search, and interact with websites, but not every organisation is moving at the same speed. Chad Capellman argues that Drupal's flexibility may matter more as different generations of the web continue to coexist.