UI Suite Monthly #37 — A new look for Display Builder, and an archaeology site digs in
Introducing the Drupal AI Security Initiative: The First Six Weeks
Drupal's volunteer Security Team has protected millions of sites for more than 20 years and its process is world-class. Bandwidth among the security engineers has always been the limiting constraint. This spring that constraint met a new kind of pressure: AI-assisted analysis is finding latent vulnerabilities at an accelerating pace.
The Drupal AI Security Initiative adds funded security capacity in response. It is funded through Alpha-Omega's Security-Engineer-in-Residence (SEIR) program, coordinated by the Drupal Association, and works alongside the volunteer Security Team, which continues its normal process throughout.
This post introduces the initiative and reports on our first six weeks. The short version: the funded fractional team model is working and has already evolved our understanding of where we want to focus next.
What changed: the economics of discoveryDrupal's attack surface is what it has always been. What has changed is the cost of finding bugs. AI-assisted analysis makes discovery dramatically cheaper. AI can produce security issue reports at a volume and can discover exploit details at a speed that any volunteer effort struggles to absorb. Our advisory data shows the rate of discovery accelerating (our next post will work through what the data suggests in detail).
Tiffany Farriss Proposes Cost Accounting and Usage-Based Enterprise Funding
How Dripyard gave Tojio a fast foundation for Drupal CMS
When we started building Dripyard as a business, we had a clear objective: Drupal developers should be able to move fast without giving up the things that make it Drupal. Structured content, editorial control, accessibility, open-source ownership, and long-term maintainability should not be traded away just because a project has a tight timeline or limited budget.
TDT Town Hall Links Newsroom Changes With Drupal’s Wider Future
Sumaris
Layout Builder Is Over-Applied: A Decision Framework for When It Actually Fits
A team starts a Drupal project. Someone asks how editors will build and arrange page content. Someone else says "Layout Builder," and that is the end of the conversation. Nobody asks what the editors actually need. Nobody asks what the content model demands. Layout Builder gets switched on because it is powerful, modern, and comes with core.
Six months later, one of two things has happened. Either the editors are happily composing layouts and everyone is glad, which is the good outcome. Or the editors are confused by a tool that gives them more power than they wanted, the developers are fighting to constrain a system designed to be open-ended, and the content is inconsistent because thirty editors made thirty different layout choices. That is the bad outcome, and it is more common than the Drupal community likes to admit.
The tool is not the problem. The reflexive selection of the tool without asking whether it fits is the problem.
The Four OptionsBefore the framework, a quick map of what you are actually choosing between when you decide how editors build pages in Drupal.
Layout Builder. Editors compose pages by placing blocks into regions of a layout, visually, per page or per content type. Maximum flexibility. Maximum editor power. The editor decides the structure.
Paragraphs. Editors add and arrange predefined content components in a field. Structured flexibility. The developer defines the components; the editor arranges them. The structure is constrained by what you built.
Custom templates. The developer defines the layout in Twig and the editor fills in fields. Zero layout flexibility for the editor. Maximum consistency and developer control.
Protecting PII in Drupal AI: An introduction to Guardrails
A "Humanizer" Should Not Become a House Style Manual
A developer I work with sent this skill over recently, asking whether it was worth adopting across the agency's client projects (an additional pass before publication under a client's name). That's a fair question to ask before rolling something out across multiple sites, so I read the source rather than taking the pitch at face value.
Last Chance: MidCamp 2026 Call for Sessions Extended to March 13
We heard you... and we want to hear from more of you!
The MidCamp 2026 Call for Sessions has been extended. The new deadline is March 13, 2026.
If you had a session idea brewing but didn't quite get it across the finish line, now's your window. We extended the deadline because we want a lineup that reflects the full range of people who use, build, and care about Drupal — and we're not there yet without you.
What We're Looking ForMidCamp sessions are open to all skill levels and all corners of the Drupal ecosystem. Whether you're a developer with a deep technical dive, a project manager with hard-won lessons, a designer with a perspective the community needs, or an end user who figured something out the hard way — there is a place for your session at MidCamp.
We're especially interested in talks around:
- Drupal AI — practical applications, integrations, and what's actually working in the field
- Drupal CMS / Canvas — building with and extending Drupal's newest tools
- Decoupled and headless implementations — real-world lessons from the front lines
- Accessibility, equity, and inclusion — building a better, more accessible web
- Community and contribution — how we grow the ecosystem together
Not sure if your idea fits? Submit it anyway. We'd rather review more proposals than miss a great talk.
How to SubmitSession submissions are open now through March 13, 2026.
Need help shaping your proposal? Join the #speakers channel on the MidCamp Slack — there are people there who will help you get it over the finish line.
Slack: https://mid.camp/slack
MidCamp Chicago 2026 call for sessions open through Feb 26
We're excited to celebrate you -- our future speakers! If you've got an idea for a session, now's the time to get involved in MidCamp 2026, happening May 12-14 in Chicago.
Call for SpeakersSince 2014, MidCamp has hosted over 300 amazing sessions, and we're ready to add your talk to that legacy. We're seeking presentations for all skill levels, from Drupal beginners to advanced users to end users and business professionals!
For full submission details and guidelines, visit: midcamp.org/events/2026/how-submit-session
Key Dates- Call for Proposals Opened: February 10, 2026
- Proposal Deadline: February 26, 2026
- Speakers Notified: Week of April 2026
- MidCamp Sessions: May 12-13, 2026
Looking to connect with the Drupal community? Sponsoring MidCamp is the way to do it! Whether you're recruiting talent, growing your brand, or simply supporting the Drupal ecosystem, MidCamp sponsorship offers great value. Act early to maximize your exposure!
Stay in the Loop- Join us on MidCamp Slack to chat and get updates.
- Follow us on Bluesky and Mastodon for announcements and news.
- Subscribe to our newsletter for updates on the venue, travel options, social events, and speaker announcements.
Ready to submit your session? Click away and let's make MidCamp 2026 unforgettable!
Helping agents discover my site search with Agentic Resource Discovery
Yesterday I blogged about the API catalog that announces my site's search API to agents. In response, someone pointed me to the ARD specification, a draft announced last month by a working group that includes Google, Microsoft, GitHub, Hugging Face, Cisco, Nvidia, and Salesforce.
What ARD adds to yesterday's API catalog is discovery. If an agent has never heard of you, it does not know to look for your API catalog. Ask an agent what people have written about the future of Drupal, for example, and it will probably search Google. It may not think to check dri.es or drupal.org directly.
The web solved discovery decades ago. Search engines find the right site, so you do not have to know where the answer lives.
ARD provides the building blocks for search engines for AI agents. Sites publish catalogs, crawlers discover them, and registries index them. An agent can then ask a registry a plain-language question, such as "Who can answer questions about the future of Drupal?". The registry returns a ranked list of relevant resources, perhaps pointing the agent to my site's search API.
You opt in by publishing a manifest at /.well-known/ai-catalog.json. Yes, that is almost the same path as my existing /.well-known/api-catalog.
Here is what my /.well-known/ai-catalog.json currently returns:
Talking Drupal #562 - Acquia Fair Trade Initiative
Today we are talking about Supporting Open Source, Acquia, and The Acquia Fair Trade Initiative with guest James Sims. We'll also cover Image Effects as our module of the week.
For show notes visit: https://www.talkingDrupal.com/562
Topics- Fair Trade Initiative Explained
- How the Program Started
- Why Fair Trade Matters
- Adoption and Open Framework
- Agency and Freelancer Benefits
- Partner Funded Giving
- Who Can Be Makers
- Tracking Participation
- Tax Deduction Questions
- Community Shaped Program
- Money Counts Too
- Early Challenges
- Timeline And Launch
- Sustainability Built In
- How To Get Involved
- Defining Success
- Origins Of Fair Trade
- Acquia Fair Trade Initiative
- Taste of chicago
- Giordanos Recommended by John
- Lou's pizza
- Five For The Future
- Image Convolution Playground
James Sims - rcjmselp85
Outside AI - The State of Agent Experience in Drupal.
By Scott Falconer, Product Lead, Outside AI
Where Drupal really stands with AI agents, where it has a right to win, and what we need to do next.
AI agents can build with almost anything. That is both great news and a problem for Drupal.
A person can ask an agent to recommend a platform, rebuild an existing site, create a content model, configure permissions, or change a running system. The agent then has to decide whether Drupal is a good path, reach it, understand it, act on it, and verify the result.
When that experience fails, we usually do not get a bug report. The agent works around Drupal, produces something that only looks finished, or quietly chooses another stack.
That makes agent experience a growth problem for Drupal, not just a developer-experience problem.
Drupal does not need to be the fastest way to generate any page. Drupal should be the safest, clearest way to a governed, inspectable, long-lived site - and agents should be able to use it effectively.
By governed, we mean the controls that make a site safe to run and hand off - a real content model, scoped roles and permissions, review and audit, safe rollback - not just quick to generate.
This is the purpose of Outside AI, the workstream the Drupal AI Initiative launched: making Drupal legible, callable, safe, and verifiable for agents and builder tools operating from the outside.
The distinction from Inside AI, in shorthand:
Inside AI is building what our partners asked for
By Christoph Breidert, Product Lead, Inside AI
A year into the Drupal AI Initiative, AI inside of Drupal has a clear goal for the months ahead. At DrupalCon Rotterdam at the end of September, we want to show a single Drupal site where AI Search, an AI chatbot, AI content review, and AI translation all work together on real, multilingual content, with observability and security running underneath. The idea is simple: rather than describe these features one by one, let people see them working together on one site.
This post is about how we plan to get there, what our partners told us to build, and the team we are putting together to build it.
Security advisory coverage removed - QA Accounts - PSA-2026-07-22
QA Accounts enables you to login to a Drupal site using a well known username/password combination. When 1.0 was released, it also was marked for security coverage. The module prioritizes ease of use rather than security and is only intended to be used on sites that are not accessible on the internet (e.g. behind firewall or other protection). The maintainers are choosing to remove security coverage.
Solution:Ensure qa_accounts is not enabled on any publicly available site.
Reported By: Fixed By:Minimizing Downtime During eCommerce Migrations
Some downtime during a platform migration is inevitable. Data, sometimes huge amounts of data, has to be transferred. Domain records need to be updated. The final checklist before launching is extensive.
However, any reputable agency will minimize this inevitable downtime, because every hour an eCommerce site is offline costs money. A migration that drags on for days is unacceptable, causing a direct hit to revenue and customer trust.
We've migrated eCommerce operations ranging from several thousand orders to several million, with product catalogs spanning a few hundred to several hundred thousand SKUs and customer records well into the hundreds of thousands. Through that work, we've developed a set of practices that consistently keep actual site downtime to a few hours, even on the most complex projects.
Here’s how to minimize your downtime.
Start migration planning as soon as the architecture is setWhen do you start thinking about data migration? As soon as the architecture is nailed down. As soon as entities and fields are defined, old data stores can be mapped to the new database.
Read moreHelping agents discover my site search with an API Catalog
I kept running into the same small frustration. My site has its own search, but when I ask an AI agent whether I have written about a topic before, it searches Google instead of using my site's search directly. As a result, it often misses relevant posts that Google has not indexed.
At the same time, the web is gaining a new audience. In addition to people visiting pages, AI agents increasingly access a site's knowledge and tools directly.
That combination led me to add support for /.well-known/api-catalog to my site. A request to https://dri.es/.well-known/api-catalog currently returns:
{
"linkset": [
{
"anchor": "https://dri.es/search/json",
"service-desc": [
{
"href": "https://dri.es/openapi.json",
"type": "application/openapi+json"
}
]
}
]
}
RFC 9727, an IETF Proposed Standard, defines /.well-known/api-catalog as a predictable location for discovering a site's public APIs.
The catalog is a small JSON document written in the Linkset format. It advertises my search endpoint and, in turn, links to an OpenAPI document that tells software how to use it.
The JSON endpoint at /search/json predates the catalog and powers my site's search. However, it was not documented or easy for software to discover. The catalog now makes it explicit.