Stop writing prompts that sound like YAML. The Drupal Views AI agent now speaks plain English, and it brought a chatbot.

Dries Buytaert opened DrupalCon Rotterdam with a tour of a platform moving at remarkable speed. Multilingual sites that take a fraction of the effort to build. Components written in React. Headless delivery across five frameworks. AI assistants that connect directly to your content. A pipeline of innovation that has Europe's push for digital sovereignty looking closely at Drupal.

Then he named the problem: hardly anyone outside this community knows. The market's picture of Drupal runs years behind what the platform can do today.

Rotterdam has a saying: "Niet lullen maar poetsen." Stop talking, start working. Dries argued we have taken that advice almost too well, and he flipped it. The work is done. Now it's time to talk louder about what is working, and for the first time, that work earns contribution credit.

Here is what he covered.

Europe needs digital sovereignty, and Drupal is ready

Dries opened with a challenge facing Europe: reducing its dependence on technology it does not control. When the European Commission asked for feedback on digital sovereignty, Dries submitted his thinking, and his writing was referenced in the official policy recommendation that followed.

His point: open source projects like Drupal offer more than software. They offer ongoing maintenance, security releases, and a global community of care. He gave it a name he hopes will catch on: Stewarded Open Source.

For governments and organisations that need control over their digital infrastructure, Drupal is exactly that: open source with a steward, proven at scale, and owned by no single vendor. As Dries put it: "Europe needs Drupal. And Drupal needs Europe too."

Innovation is back, and it is reaching new people

Two years after launching the Starshot initiative, Dries reflected on what it delivered: Drupal CMS, recipes, site templates, Canvas, and a wave of AI tools. Then he showed four ways Drupal is bringing its strengths to more people:

• Multilingual. Building multilingual sites is now dramatically simpler, and Drupal Canvas fully supports multilingual content.
• JavaScript. Canvas code components can be written in React, treating JavaScript developers as first-class citizens.
• Headless. Official headless support now spans five frameworks, including newly added Angular.
• AI. A new public demo site lets anyone explore Drupal's AI capabilities, made possible by the partners of the Drupal AI Initiative.

AI assistants are becoming another interface to Drupal

You can already connect an AI assistant to a Drupal site using a recipe that combines Simple OAuth, MCP Server, and the Tool module. Dries demonstrated it on his own photo album module, built to answer questions like "Do you have that photo of Oma wearing her sunglasses?"

Fully exposing his module's capabilities took around 1,000 lines of code. A research prototype built with Matt Glaman reduced that to roughly 20 PHP attributes. Describe a capability once, and it becomes available everywhere: to AI assistants, to workflow tools like ECA, to JavaScript components, and to humans who never touch AI at all.

The Rosetta Sprint: one description, readable by everyone

To turn the prototype into a shared roadmap, Dries announced the Rosetta Sprint. Like the Rosetta Stone, which carried one decree in three scripts, the goal is for Drupal to describe its capabilities once, in a way that AI agents, other systems, and humans can all read.

The sprint will bring key maintainers together for four days of focused work.

The Drupal Advocacy Program: contribution credit for talking about Drupal

Dries named Drupal's reputation gap as the project's number one challenge. Too many people are judging the Drupal of ten years ago, and AI systems trained on old information repeat that outdated story.

His answer is not hype. "Drupal doesn't need hype. It needs a better public record."

So the Drupal Association is launching the Drupal Advocacy Program, a pilot that awards contribution credit for work that helps people discover and understand Drupal: writing tutorials, recording demos, translating articles, amplifying someone else's talk. Each quarter, a focus theme with a ready-made source kit earns double credits.

Submissions open today at drupal.org/advocacy.

Start now, in Rotterdam

Dries closed with the Rotterdam Pilot: a challenge to everyone at DrupalCon to turn the buzz in the room into buzz outside it. Share a takeaway. Clip a talk. Write about someone else's session and credit them.

"Drupal is now light-years ahead of its reputation," he said. Closing that gap is work we can all do, starting this week.

Slides will be posted at dri.es.

File attachments:  Europe Needs Drupal.png QRCodes.png LightYearsAhead.png

Introduction

I use AI every day to accomplish a variety of tasks. I'd like to share three tales about building, maintaining, and contributing to different Drupal modules. My goal is to discuss how I use AI and what I use it for.

At the same time, I am not trying to teach you how to use AI because I've noticed a nuance: AI can teach you how to use AI. For example, you can point an AI at this post and ask it to read the post, follow the links, and explain how things are being done. For me, open source and Drupal have always been more about sharing ideas, experiences, and stories, as well as code, allowing humans and their AIs to learn from or be inspired by each other's experiences.

My three tales are meant to be told in a specific order: building a greenfield project, maintaining a brownfield project, and contributing to someone else's project. Because of how AI works and the increased use of spec-driven development, people are discussing projects in terms of greenfield vs. brownfield. Ironically, I don't think of Drupal as greenfield or brownfield, but as infrastructure that fields and projects sit on top of. The most fundamental greenfield project in Drupal is building a new site for an organization, and for contributions to Drupal, building a new module.

Building a module using AI

Building a Drupal module with AI isn't new. I've written several posts that range from learning to build a Drupal module using AI to having AI build a module. The most recent module I've "built" with AI and contributed back to Drupal has a unique nuance: the initial code and solution came from an existing client project we are modernizing, and I had AI...Read More

Perhaps the most revealing thing about DrupalCon Rotterdam is that its programme does not tell one tidy story. Drupal is preparing to discuss its transformation into a production-ready Agentic CMS while another session asks, quite directly, why developers still do not choose Drupal. Canvas has become central to Drupal CMS, yet Rotterdam will also put it against Display Builder in a real-world project. Those collisions matter because Drupal’s next phase depends less on any one initiative succeeding than on whether these different bets can reinforce one another without carrying old friction forward.

Connecting Drupal to models and agents is no longer the difficult part of the AI story. Rotterdam moves quickly into hallucination, reviewer trust, orchestration, governed workflows and human control because production use raises harder questions about what an agent may do once it can act rather than merely answer. Permissions, auditability, validation and human approval are becoming part of the product itself. If the Agentic CMS idea is going to mean more than a collection of AI capabilities, those boundaries have to become as deliberate as the capabilities they constrain.

Adoption tests another part of the same argument. Drupal CMS 2.0, Canvas, Recipes and AI-assisted tooling have changed the product presented to builders, but improved technology does not automatically change how Drupal is perceived beyond its existing community. “Why Developers Don’t Choose Drupal” puts that gap unusually plainly. The useful evidence from Rotterdam will not be another inventory of features, but signs that newcomers can enter the system more easily, that organisations are choosing Drupal CMS rather than only inheriting or upgrading Drupal, and that the new experience removes barriers people outside the community can actually feel.

Digital sovereignty makes the question more demanding because Drupal is also being asked to apply its values inward. A Rotterdam discussion on FAIR asks whether sovereignty, governance and cost problems in Drupal’s own software distribution could be addressed differently, starting from Drupal.org’s role as the ecosystem’s central distribution point. That turns openness from something Drupal offers its users into something its own infrastructure may need to demonstrate. Arguments about control become more credible when the project is willing to examine where dependence, responsibility and operational burden sit inside its own systems.

Discovery may be where all of these threads become visible from outside. A Rotterdam discussion on Drupal’s representation in ChatGPT, Gemini and Claude starts from the recognition that developers and decision-makers increasingly encounter technologies through AI-generated answers as well as conventional search. Drupal therefore has to become easier to understand, evaluate and trust not only for people already inside the ecosystem, but also for the systems mediating their choices. Rotterdam will not settle all of that in four days. What it can reveal is whether Drupal’s current direction is beginning to cohere: a product easier to adopt, agents with clearer limits, infrastructure consistent with its sovereignty claims, and a project that can explain its relevance wherever technology choices now begin.

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

Kazima Abbas wrote and curated this issue of Editor’s Pick.

A great leap backwards: fixed configuration

Drupal's configuration system has at its heart a key concept: the site owns the configuration. What that means is that after a module has provided install configuration, it no longer has any control over it. You, the site admin, can change that config or even delete it. The module is no longer involved.

This kept the configuration system simple (up to a point); after all, the development of this system was one of the harder parts of the lengthy and difficult Drupal 8 cycle ("The ConfigImporter class was written with a get this done and working attitude" wrote @alexpott on a core issue, and I think the same could be said of the configuration system as a whole).

Since then, the config transformation API was added, and various modules have been created that take advantage of this, such as Configuration Split and Config Merge. These still work in the paradigm of the site owning the configuration. But what if we could turn the clock back, just partially, to when modules could own config too?

The (different) old days

If you were around in the days of Drupal 7, you may remember the various default hooks. Modules such as Views and Flag exposed a hook which allowed modules to define configuration items. (These were not configuration in the modern sense, because there wasn't that concept at the time, but referring to them as such makes things simpler.)

These were thus a code-defined instance of a type of thing that could also be defined in the UI by site admins. A module could supply a default view, and rely on it always existing. A new release of a module could come with enhancements to a that view, and they would exist on the site as soon as the module code was updated to the new version.

Because these hooks were PHP code, it was also possible for configuration to dynamically depend on other aspects of the site. You could do something such as define a default flag for every node type.

The idea

For a long time, I've wondered if something similar could be possible with Drupal's configuration system: put simply, defining configuration in code. Or, as I'm calling it, fixed config.

Many modules, such as Drupal Commerce and LocalGov Drupal rely on configuration items which are essential to their functionality (what I call machinery). Drupal's paradigm of configuration being owned by the site means that a site admin can break or outright delete key parts of the module's functionality: a commerce system missing its cart view, or a directory system missing its node types and vocabularies.

There's a case for admins being able to enhance and tweak a module's machinery, but that leads to the problem of how to reconcile a site's changes with changes that come in a new version of a module. There are modules that aim to help with this, but configuration entities are complex data structures, and without in-depth knowledge of that structure, this is a difficult and painstaking task. Some modules take care of this in update hooks each time they want to change their machinery, but that also requires complicated work each time.

The final push to get me to work on this was the use case of Entity Pager: the maintainer of the Flippy module suggested merging the two modules. But while Entity Pager provides the means for site admins to create any pager for any entity type, Flippy's functionality is to automatically provide a pager for each node type on the site. It seemed to me that the way to achieve this feature on top of Entity Pager was to have a way for the Flippy module to define an entity pager view automatically for each node type. The same way that Drupal 7 default hooks could.

Could this be done within the modern Drupal config system? The module would be in charge, not the site. If the module's code updated and changed the definition of the config, then the site would pick up on that.

Developing the module

The basic requirement is to add config entity definitions that are coming from code.

I could see two ways of doing this: intercept the entity storage handlers, or intercept the config transformation API. I opted for the latter. Partly because working at the entity storage level would require decorating every config entity type storage handler, which seemed heavy-handed, and because working within the config system has its advantages, and finally because one general principle I have found over the years is that complexity should generally be pushed down in a system. The config system is beneath the entity system, so working there would mean that this would be completely invisible to the entity system which would just see some additional entities.

So, I experimented with the config storage transformation API. Could I make it see, for example, a hardcoded node type? The answer was yes: it's simple to add an additional config entity in the STORAGE_TRANSFORM_IMPORT event, and the site sees it just as if it were some other piece of config.

Then the real development work started: making the config system read the fixed config, but also ignore it when necessary. I decided on this simple rule:

• Fixed config is not exported to config sync. Instead, it is always re-created from files on config import.

On Drupal 7, some (but not all) default hooks had a concept of overriding. The site admin could choose to edit a default object, such as a view, and deviate from the version in code. From that point on, the site owned that object, not the module.

I've decided, for now at least, not to support overriding. I think a better, and simpler, pattern is to allow selection of config: the module provides machinery, but also provides a setting to select it as being in use. For our example of the commerce cart view, there would be the fixed config view, and also a config setting where you select which view is used for the cart. This means that the default view remains under the control of the commerce module, but a site admin can duplicate it, change the duplicate, and then use that one instead. The site then owns the duplicate view, but the default view remains available and functional at all times.

The Alpha-1 API

Having got a proof-of-concept, the next step was to design an API too. Rather than use hooks or an event, I decided fixed config should look the same as install config: YAML files. The big advantage here being that while developing it, you can move YAML files from sync or install folders to become fixed config. And it provides a system that is already familiar to developers: fixed config is simply a YAML file in a module's config/fixed folder instead of config/install. (I made a small change and a new release of Config Devel so that its module config export feature works with this folder too.)

But static YAML files doesn't cover all the use cases that the Drupal 7 era hooks used to satisfy. So I added the concept of derivers. We already have plugin derivers in Drupal (and maybe I should have tried to think of a different name); but these are config deriver plugins: they create multiple config items from a single template.

So while a static fixed config file looks identical to an install config file, a derived fixed config file has these additions:

third_party_settings: fixed_config: deriver: deriver_plugin_id dependee_config_patterns: - node.type.*

What this means is that when config whose name matches node.type.* is created or updated, the fixed config deriver plugin deriver_plugin_id reacts, and maintains the fixed config based on the YAML file that holds these properties.

The node type config entity is the dependee config; the fixed config that gets defined in response to that is the dependent fixed config.

This is how the Flippy module could then work: it defines a single fixed config YAML file for a view, and a deriver plugin which alters these config values:

• Sets the value of the node type filter.
• Sets the path for the page display.

Eating my own dogfood

I find that you never fully realise what an API needs to do or how it needs to work and how to best make it usable until you actually try to use it, and that therefore it's best to do that early on.

I started making the Entity Pager view, and I was soon struck with several things about what I'd made:

• Code that sets a view's entity bundle filters to an incoming bundle entity should be reusable.
• Code that adds the incoming entity's ID as a suffix to the view's path should be reusable, but not necessarily by the same things as the first.
• As well as deriving a single view for each node type, it might be useful to have a single view which adds a new display for each node type.

That reusability feature could be solved by using PHP traits, and requiring developers to composite them into their plugin classes. Or it could be solved by making the plugins themselves smaller, and allowing the deriving process to specify more than one. A pipeline, basically.

And the many-to-one feature could be solved by letting code alter the fixed config YAML file values, rather than deriving from them: the same config values get processed by the PHP code for every config entity it listens for, rather than making a new copy each time.

To me, this suggests a new type of plugin, fixed config alterers, which can do the work in both of these scenarios.

So what I am pondering now would look like this:

• For derived fixed config:
  • The fixed config deriver plugin does the bare minimum to the config values from the YAML file.
  • The config values are passed through multiple alterer plugins.
• For static fixed config:
  • If config patterns are specified, the config values are passed through alterer plugins for each config matching the pattern.
  • A better name is needed as it would no longer be completely static!

Am I over-engineering, I wonder? Also, the pipeline of alterers seems very much like the Migrate API's pipeline of processors, but I don't see how to reuse those as they operate on different sorts of values: entire config entity values for my case, and single content entity field values for Migrate.

I'd be interested in hearing ideas and use cases for the fixed config module. It would help me with the process of refining my initial ideas for the API.

I've made an alpha release, try it out and let me know what you think, either in the issue queue or on mastodon.

Do you have potential uses for fixed configuration? I'd love to work on this module with some real-world use cases, and I'm available for hire - contact me!

joachim Mon, 28/09/2026 - 11:05 Tags

• contrib module
• configuration

Since September, advertisers in Europe can buy ads inside ChatGPT, and the Ads Manager asks for two things before it can tell you whether they work: a measurement pixel in the browser and, ideally, conversions sent from your server. On a Drupal site that usually means pasting a snippet into the theme, writing the order_created call by hand in a template, and trying to hide the whole thing behind the cookie banner. Then the order paid by bank transfer or payment reference hours later, confirmed by a webhook, never shows up, because no browser was there to see it.

Even when a browser is there, the pixel loses part of the picture. Ad blockers stop it outright, Safari caps cookies written by scripts at seven days, and iOS removes tracking parameters from links shared in Messages and Mail and from links opened in private browsing. OpenAI's own documentation calls the Conversions API "a more reliable tracking source than the pixel alone".

We have released a module for this on drupal.org: ChatGPT Ads, free software under the GPL, for Drupal 10.3 and 11, covered by Drupal's security advisory policy. It plugs into Drupal Commerce, Webform and the Klaro consent manager through sub-modules, and sends events through both OpenAI's Measurement Pixel and the Conversions API. It is a community module, not affiliated with OpenAI.

What you can measure

• With Drupal Commerce, every product added to the cart, including from an AJAX add-to-cart button, with its SKU, quantity and price.
• The start of checkout, and the order itself when it is paid, not merely placed, so an unpaid bank transfer or an expired payment reference never counts as a sale.
• The order paid later and off-site, reported from the server when the payment webhook arrives, with the same event id as the browser, so OpenAI counts it once.
• With Webform, a contact form, a quote request or a newsletter sign-up as a lead: add the ChatGPT Ads handler to any webform and map the email and phone fields.
• Account registrations, from the browser and the server.
• Anything else, with a single call to Drupal.chatgptAds.measure() from your own script.

The pixel goes only on the pages you choose, using the same visibility conditions blocks use: paths, roles, content types, language.

What it refuses to do

Nothing is requested from OpenAI, and no cookie is set, until the visitor has decided. OpenAI's documentation suggests loading the pixel with consent withheld and granting it later, but the script sets cookies as soon as it loads, so the module does not load it at all until there is an answer.

A visitor who has not answered yet is neither a yes nor a no. Their events wait in memory and go out if they accept, so the landing page is not lost; if they refuse, they are dropped. The Klaro integration reads only decisions the visitor has confirmed, because Klaro reports a service's default from the moment the page loads, which would otherwise be read as a refusal while the banner is still on screen.

The same rule applies on the server. Hashed email, phone, IP address and user agent go to the Conversions API only for a visitor whose consent was recorded at the time of the event. For everyone else the conversion still goes, carrying the click identifier and nothing about the person.

The module never saves an order. Saving inside a Commerce transition can fire that transition twice, which on a live store means duplicate receipts and an error at checkout; the click identifiers are stored on the order when the checkout flow saves it anyway.

Pages stay cached

The pixel and the settings that are the same for everyone are cached with the page. What belongs to one visitor, the events collected for that page and, with advanced matching on, their hashed account data, arrives through a placeholder rendered on every request. A page carrying the pixel stays in Drupal's Dynamic Page Cache, instead of turning every page on the site uncacheable to deliver one visitor's identity.

Where it came from

It was built for one of the e-commerce stores we develop in Portugal, where many orders are paid by Multibanco or MB WAY, Portuguese payment methods whose confirmation often arrives hours after checkout. Bank transfers and payment references behave the same way in any country, and that pattern is why the Conversions API is in the first release rather than a later one: without it, those sales are invisible to the ad platform. The pixel, the Klaro gate and the cart events have been running on that store since mid September.

Your consent manager, your choice

Klaro gets a ready-made sub-module: install it and a ChatGPT Ads service appears in the banner, off by default. Any other consent manager reports the decision through a small JavaScript contract, and the README carries a working recipe for EU Cookie Compliance:

Drupal.chatgptAds.consent(true); // granted, now or on a later page Drupal.chatgptAds.consent(false); // refused or withdrawn

To see what else on your site reaches third parties before the visitor decides, Consent Audit records it from real visits.

Get it composer require drupal/chatgpt_ads

You need a ChatGPT Ads Manager account and the pixel id from its Conversions tab. The Conversions API sub-module stores its key through the Key module, so the secret can live in an environment variable instead of your exported configuration. The project page, the documentation and the issue queue are on drupal.org. Bug reports, questions and merge requests are welcome.

The inaugural DrupalCon Talent Show is happening at DrupalCon Orlando on the evening of Tuesday, March 23, 2027 as part of the community party!

We’re planning about two hours of entertainment and looking for roughly 10 acts to take the stage (5–7 minutes for the act, plus up to 3 minutes for stage setup).

This is DrupalCon. The goal is to learn, network, and have fun. Expect jokes, friendly razzing, questionable decisions, and plenty of laughs. You don’t need to be a professional. You just need to be willing to get up there and attempt to entertain your fellow Drupalers (within our Code of Conduct https://events.drupal.org/code-conduct, of course!)

What are we looking for?

Pretty much anything entertaining:

• Musicians
• Bands
• Stand-up comedy (keep it PG-13 please!)
• Magic
• Singing
• Dancing
• Juggling
• Puppet shows
• Ridiculous feats of skill
• Weird talents you didn’t think anyone wanted to see (we do)

Got something that doesn’t fit on the list? Even better. Solo acts, groups, first-timers, seasoned performers, and wonderfully questionable ideas are all welcome.

Think you’ve got something? Sign up here and show us what you’ve got!

FAQs When is the deadline?

The absolute last deadline to sign up is Friday, February 19th. However, submissions are reviewed on a rolling basis as they come in. Once all ~10 spots are filled, sign-ups will close early. We strongly encourage you to submit as soon as possible.

Is there a prize?

Likely, but this hasn’t yet been determined. Suffice it to say that the primary prize will be bragging rights!.

How will performances be chosen?

Performances will be chosen to ensure a wide variety of performance types, geographical regions, companies, diverse performers, etc. You can increase your chances of being selected by submitting earlier rather than later.

How long should the performances be?

5-7 minutes is ideal

Do I have to bring my instrument? Will there be microphones?

We will provide microphones for your band (up to four). If needed by multiple performers, we may be able to supply basic instruments. Details will be provided ahead of the performance if you are accepted to perform. 

Will there be a bar?

A cash (and credit card) bar will be available.

Moving from Drupal to WordPress is not a downgrade when your requirements shrank. When it is right, when it is a mistake, what the migration involves, and what you honestly lose.

Drupal 11: Migrating From Jadu Into LocalGov Drupal: Part 4

This is the fourth article in a series looking at migrating from Jadu into LocalGov Drupal (LGD) for the Central Bedfordshire site. In the first article we looked at the Jadu API itself and setting things up so that we could make calls to the API and parse the XML data using the migration systems available.

In the second article we looked at reproducing Jadu URLs to create redirects for migrated content, even though the Jadu API doesn't contain any URL information.

In the third article we looked at a more complex example of migration, taking documents and pages from Jadu and creating a guide pages from that data.

Now it is time to move onto what became the most complex part of the Central Bedfordshire migration, which was moving directories data from Jadu to LGD. Directories were used on the Jadu site to store all sorts of information, which included schools, the location of car parks, contact information of homecare providers, and even an a-to-z glossary of recycling. This data served different purposes on the site, but it was all hand created and important to bring across during the migration work.

In this article we will look at the Jadu data we needed to fetch to find directory information, and how that data was injected into the LGD structure available.

First, let's look at how we get directory information out of Jadu.

Jadu Directories API

Directories in Jadu can be fetched using the directories index at the following endpoint.

philipnorton42 Sun, 09/27/2026 - 18:45

The prototype works. Taking it to production quality is more than evenings. Whether it should is a question, not a pitch.

One thing before the rest. I am not pushing this. The series is a question to the world: is this work worth more of my time? We are not in the Federation yet, so more time means money, and money means backers. Any answer is fine with me, including no.

Every framework service that holds state is a bug under fibers. The current fix is to switch concurrency off. There is a third option.

Every Druxt site I have built signs people in by sending them somewhere else to do it: out to Drupal's login page, on to a consent screen, and eventually back. With Druxt Auth 0.5.0 the username and password can now be handled entirely in the frontend instead, either through the authorization code grant or through the password grant.

If you have not used it, Druxt Auth wires Nuxt's auth module to Simple OAuth on the Drupal side. It targets Nuxt 2 today, because @nuxtjs/auth-next does.

The first is the authorization code grant, which now takes credentials directly. Druxt Auth signs the visitor in through Drupal's JSON login route first, so the authorize step finds a session waiting and returns a code without rendering anything:

Continue reading →

AI becomes a different infrastructure problem once organisations need to know where data goes, which models are approved, and how spending is controlled. amazee.ai and Tag1 will bring those questions to DrupalCon Rotterdam through a private gateway and Scolta implementation.

A coroutine nobody owns is a leak. Under one process per request you never see it. Persistent servers take that away.

A workflow can report success and still be wrong, while a thriving community can quietly depend on too few people. These Rotterdam speakers look past the demo to the evidence, architecture, feedback, and ownership that determine whether Drupal work holds up.

Drupal CMS 2.2.0 is out, and this release is all about multilingual. Setting up a site to publish in multiple languages has always been possible in Drupal, but it was not easy. With 2.2, we've tackled the biggest pain points from the installer through to translating your Canvas pages.

Finding your language in the installer

The first thing you'll notice is the language selector in the installer. Instead of scrolling through a long select list, you can now start typing and search for your language.

It's a small change, but makes for a much better first impression.

Recipe config is now translated

Previously, if you installed Drupal CMS in another language, any configuration provided by recipes (such as content types, fields, views, even the dashboard) would still show up in English. 

Recipes can include translatable configuration and that is now translated along with the rest of the site.

The multilingual recipe

Adding a second language to a Drupal site involves a lot of steps: installing the right modules, configuring language detection, enabling translation for each content type and field, and making sure you haven't missed anything along the way. Most people figure this out through trial and error (and a fair amount of searching).

The new multilingual recipe takes care of most of this for you:

• Installs the required modules and applies the basic language settings
• Provides a multilingual setup checklist to guide you through the remaining steps
• Modifies the content translation settings page to make it more intuitive, including a 'Recommended setup' option that enables translation for the entities most commonly translated (node types, Canvas pages, menu links and taxonomy terms).

Translating Canvas pages

Canvas now fully supports translation and we're using Canvas Translate to provide the translation management within the canvas editor. You can translate any component on a page, and use the Canvas preview to see how the translated version will look before you publish it.

Using the bundled Canvas Translate AI module, you can also get AI-generated translations with one click: either for all components, or individually.

New multilingual demo

Drupal core has long shipped with the Umami multilingual demo, which has community contributed, cooked and photographed recipes. Umami will not be included in Drupal 12 anymore and it was in need of a design rethink and retooling with our new easy to use page building capabilities. This resulted in the new Dashi demo, which brings the same multilingual content to a customizable setup with Canvas page and content templates.

Try it out

Try it out by installing Drupal CMS 2.2.0!

1. Install DDEV
2. Run the following commands:

mkdir my-drupal-site && cd my-drupal-site ddev config --project-type=drupal11 --docroot=web ddev composer create-project drupal/cms ddev launchFile attachments:  Screenshot 2026-09-23 at 10.38.37 am.png Screenshot 2026-09-23 at 11.38.36 am.png Screenshot 2026-09-23 at 11.38.22 am.png content-translation.gif

DrupalCon Rotterdam 2026 is almost here. The Drupal Association staff and board are heading to the Netherlands next week, and we'd love to see you there!

Photo Credits: Ryan Witcombe

Here's where you'll find us during DrupalCon Rotterdam 2026:

Drupal.org Engineering Panel

Join the DA engineering team for an open and honest look at the current state and future of Drupal.org (the platform the entire community relies on every day). From nearly 10,000 projects migrated to GitLab, plans to support a brand new Drupal.org marketing site, and initiative support for Drupal CMS + Canvas and the AI Initiative, there's a lot to cover. The session closes with an open Q&A, so bring your questions

Day & Date: Wednesday, September 30, 2026

Time: 11:40 to 12:25 CEST

Location: Goudriaan Room I&II

Marketing Panel

Building on the momentum of the Drupal AI initiative, the Drupal Association is growing coordinated advocacy and marketing efforts in new areas, opening the door for more people to get involved and make a visible contribution.

Join the panel to understand how the initiative is taking shape, why they’re gaining traction, and what makes them different. The panelists will discuss how marketing in Drupal is becoming one of the most accessible and high-impact ways to contribute, where individuals and organizations  alike can raise their profile, earn recognition, and help shape Drupal’s future.

Day & Date: Tuesday, September 29, 2026

Time: 16:40 to 17:25 CEST

Location: Goudriaan Room I&II

Drupal Association Public Board Meeting

The DA Public Board Meeting is open to all DrupalCon attendees and is your opportunity to hear directly from the Drupal Association board. Come with your questions, your feedback, and your ideas. This is your chance to engage with the people shaping the future of the Drupal Association.

Day & Date: Tuesday, September 29, 2026

Time: 14:25 – 15:10 CEST

Location: Rotterdam Room I&II

Drupal Association Partner Lunch

An exclusive afternoon gathering for agency leaders and partners to connect with Dries and DA leadership over a seated lunch. A unique opportunity to share strategies, discuss the Drupal business ecosystem, and build meaningful relationships with peers from around the world.

Tickets are required, register here.

Day & Date: Tuesday, September 29, 2026

Time: 12:00 – 13:30 CEST

Location: Postillion Hotel & Convention Centre WTC Rotterdam

Drupal Business Dinner

Cap off Wednesday evening with the Drupal Business Dinner, an intimate gathering of Drupal agency executives for a seated 3-course dinner, a presentation, and meaningful conversations in a beautiful Rotterdam venue.

Tickets are required, register here.

Day & Date: Wednesday, September 30, 2026

Time: 19:00 – 22:30 CEST

Location: De Harmonie, Rotterdam

Photo credits: Matthew Saunders

Whether you're joining us for a session, an exclusive event, or just stopping by our booth to say hello, the Drupal Association team can't wait to connect with you.

The last few days are left to secure your ticket to DrupalCon Rotterdam 2026, if you already haven’t. See You in Rotterdam!

What changes when Drupal becomes something an enterprise AI agent can act on, rather than the place where every user must work? Pantheon plans to show that model running end to end in Rotterdam.

Digital sovereignty does not begin with replacing software. It begins with knowing which services an organisation depends on, who controls them, and what it would cost to leave.

As we see our goals for Drupal AI innovation under responsible human guidance flourishing at such a remarkable pace, we recognize a growing community need for practical, responsible ways to learn it. We’re excited to announce, as part of our efforts to fill that need, AI Inside Drupal Essentials (AIDE,) developed and presented by DrupalEasy, as the official training program of the Drupal AI Initiative. 

We’ve partnered with Drupal expert developer and highly respected trainer Mike Anello (ultimike) to ensure the program supports our mission to drive responsible AI innovation and build on Drupal’s position as the leading open-source content management system for AI integration. Mike and the team at DrupalEasy have the commitment and experience to create, maintain and present the curriculum with our standard for ethical, powerful, and accessible AI in the open-source world.

AIDE

AIDE is designed to help you move forward quickly and confidently with a solid foundation in how to conscientiously take advantage of Drupal AI benefits. The 2-week, 18-hour curriculum is presented on a timetable designed to integrate well into work schedules; meeting live, online for 3 hours every other day. The first session kicks off on November 9, 2026 and runs through November 20th. Additional sessions will be announced in the coming weeks.

In addition to DrupalEasy’s signature lively, online classes; each class session is recorded and becomes part of the video library that participants have lifetime access to. Other resources included as part of the course is a dedicated Slack channel and more than 100 pages of technical guides and implementation tools. The cost to register is $600.

Learn risk mitigation & human oversight

Mike Anello, who has meticulously developed hundreds of hours of Drupal curriculum and trained Drupal developers for more than 20 years, has created another stellar program that leads you, hands-on, through admin-facing responsible AI techniques that prioritize workflows that keep a human in the loop to review AI-generated suggestions before they are saved to the database. From class to class, you'll move from secure foundations to advanced agentic workflows and high-performance retrieval augmented generation (RAG) search, with intensive hands-on examples you can apply to your own Drupal projects right away.

Course content

The course covers four areas:

• AI Foundations: Establish a baseline for secure LLM integration. Configure the AI Automators and Field Widget Actions modules to see how AI output can be reviewed before it's saved.
• AI Agents: Implement agentic workflows and swarm orchestration agents, and deploy tool-calling capabilities that let AI interact directly with Drupal's Tool API.
• RAG Search: Build retrieval augmented generation systems using vector databases, and learn semantic chunking and representation strategies that maximize search accuracy.
• Local AI & Privacy: Deploy local models via Ollama for maximum privacy and cost-efficiency, and use the AI Metering module for automatic local fallback when commercial API quotas are reached.

Our goal, with AIDE and our other learning resources including webinars, workshops, events and the Drupal AI Demo is to make sure everyone who works with Drupal AI can do it safely and effectively.  

Learn more about AI Inside Drupal Essentials training , or ask about the course or AIDE team pricing.