Image: DriesNote, DrupalCon Rotterdam 2026 by Paul Johnson

Author: Jeremy Chinquist

At DrupalCon Rotterdam on September 29, 2026, Dries Buytaert used his keynote to show how far Drupal has come and who it can reach next. Dries framed the keynote around three pillars that bring Drupal's strengths to more people: multilingual (reach people in more languages), JavaScript and headless (bring more developers and applications to Drupal), and AI (give people new ways to work with Drupal).

This post zooms in on the AI pillar. For the full keynote, including digital sovereignty, multilingual, headless and the new Drupal Advocacy Program, read the official recap: DriesNote Rotterdam: Drupal is Light-Years Ahead of Its Reputation. To watch the six demos from the keynote, see Proof, not promises. Watch the six demos from the DriesNote Rotterdam.

Watch the full keynote on YouTube

Exclusive interview: James Hall sat down with Dries Buytaert for the Drupal AI Initiative. Watch it on LinkedIn

Image: James Hall, Everyone TV interviews Dries Buytaert following the DriesNote

A strong start for the Drupal AI Initiative

Dominique De Cooman, Head of Partnerships for the Drupal AI Initiative, opened the conference with a short welcome and a clear message: the Drupal AI Initiative is strong and active. Dries later mentioned that over 100 people have contributed to the Drupal AI Initiative so far.

Try it now: "Drupal AI Demo: Northmoor University"

On stage, Dries showed off the demo that the Inside AI team, led by Christoph Breidert, had been developing over the past few months. "Drupal AI Demo: Northmoor University" is a complete university website that shows Drupal AI at work on realistic content. Anyone can try it today at drupal.org/ai/demo. To learn how the demo was built and what it can do, read Christoph's announcement: Introducing the Drupal AI Demo.

Five parts of the demo were highlighted during the talk:

• Find weak content and fix it. Drupal AI scans the site's programs, courses, people, news, events and policies, checks them for accuracy, tone and inclusive language, and flags weak items.
• Fix it without the expert. Editors fix the flagged content themselves instead of waiting for a specialist.
• Grounded answers, every source cited. Visitors can ask the site questions. Drupal AI answers from the site's own content and cites its sources. If the answer isn't there, it marks the question as outside the site's scope and uses the content to point to the right person to contact. It is not allowed to invent an answer.
• Drafts, not surprises. Editors can connect their own AI assistant. Asked to update every page that mentions a newly promoted professor, the assistant finds 10 pages and drafts the changes, but publishes nothing. Every draft waits for a human to review and publish.
• Stay accountable. AI guardrails, one source of truth and every interaction logged.

Did you know?

Aidan Foster also used the demo site in the presentation "Encoding Expertise: How UX Research Powers Human-First AI" to show how AI guidelines can help review a site's content.

Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)

What this means for you: for agencies and site owners, this is the quickest way to see Drupal AI on a real site before planning a project. The guardrails matter as much as the features: the AI flags, drafts and cites, and people decide what gets published.

Building Drupal Canvas components with AI

Dries showed AI-assisted development for Drupal Canvas. Given a prompt such as "Build a content template for my articles," the AI assistant checks its work against Canvas Workbench, ESLint and the Canvas CLI. The result is a set of simple template files, pushed to the site with the Canvas CLI.

What this means for you: front-end developers can let an AI assistant write the first draft while Canvas' own tooling validates the result.

Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)

Connecting Drupal to AI assistants

Today, exposing a Drupal module's features to AI assistants via MCP takes around 1,000 lines of code. Dries showed a prototype that brings this down to around 20 PHP attributes, using a recipe that combines the Simple OAuth, MCP Server and Tool API modules. The principle is "describe once, use in multiple places": one description of a capability serves AI assistants, workflow tools and JavaScript components alike.

In the demo, a FindImages tool lets an AI assistant look up images on the site, with FlowDrop connecting the pieces.

What this means for you: this is a prototype, not a release. For module maintainers, it points to a future where one description makes a module usable by AI assistants.

Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)

On the roadmap: the Rosetta Sprint

The next step is the Rosetta Sprint: a four-day sprint with key maintainers to describe Drupal's capabilities once, in a form that AI agents, other systems and humans can all read. The goal is to make Drupal's data and capabilities easier to expose to AI agents, orchestration tools, frontends and more. The date and location are still to be announced.

Did you know?

Kristen Pol used the Drupal AI Demo to record the demo clips for her session "Context Control Center: Bringing AI Context to Drupal CMS." Curious how Drupal gives AI the right context? Take a look.

Talk louder about Drupal

Dries closed with a clear request: "Here is my ask: Talk louder about Drupal." Try the demo, share what you build with Drupal AI and join the Drupal Advocacy Program.

Image: Karl Hepworth (DriesNote, DrupalCon Rotterdam 2026)

Thank you, Drupal AI Partners

During the keynote, Dries thanked the Drupal AI Partners, the organizations that back the Drupal AI Initiative. Want your organization to join them? Become a partner.

Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)

File attachments:  02b-university-demo-stay-accountable.png

Today we are talking about PHP, Open Source, and Sustainability with guest Elizabeth Barron. We'll also cover AI Image Classification as our module of the week.

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

Topics

• What is the PHP Foundation
• Language Health Challenges
• Paid Core Developers
• Release Infrastructure
• Foundation Role and Perception
• Docs and Onboarding
• Elizabeth Open Source Journey
• Future of PHP Ecosystem
• Listener Elephant Question
• Ecosystem Security Hub
• Advisory Board Limits
• Modernizing Mailing Lists
• Foundation Awareness Push
• PHP Ambassadors Strategy
• State of PHP Survey
• Five Year Vision
• Community Hour Podcast
• php.net Design Refresh

Resources

• The PHP Foundation
• Derek Rethans
  • xdebug
  • Infrastructure
  • https://github.com/derickr
• Drupal advocacy
• Link to community hour podcast
• Php 8.5
• Contribute to php article

Guests

Elizabeth Barron - thephp.foundation elizabethbarron

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Tim Sharp - tea-sharp

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted the images in your Drupal media library to be automatically given alt text, a rich description, and a set of tags, using AI? There's a recipe for that.
• Module name/project name:
  • AI Image Classification
• Brief history
  • How old: created in Sep 2025 by Artem Dmitriiev (a.dmitriiev) of 1xINTERNET
  • Versions available: 1.1.1, which requires Drupal 11.2 or newer
• Maintainership
  • Actively maintained, latest release and commit just two weeks ago
  • Security coverage
  • Number of open issues: 9 open issues, 4 of which are bugs
• Usage stats:
  • No usage data reported
• Module features and usage
  • This recipe applies core's image media type recipe, then adds a description field and a tags field to image media, with tags in a new "Image Classification" vocabulary
  • Editors get a "Generate Alt Text" button right on the image field, using the Field Widget Actions module, with a prompt written like an accessibility expert: under 100 characters, no "image of", flag logos and graphics
  • On save, a vision model writes a description of up to eight sentences: colours, photo versus illustration, people, mood, and key objects, using the media name for context
  • Tagging is chained off that description rather than the image itself, picking or creating up to five short, general terms, and reusing similar existing tags where it can
  • It also adds bulk actions to the media admin view, so you can run description and tagging across an existing library, not just new uploads
  • Description and tag filters are added to the media library, including the widget, so editors can search for "sunny summer day" right in the image picker
  • The stated bigger goal is making images discoverable by RAG and other AI search, so good descriptions become a foundation for future AI features. In fact, this recipe is a dependency for the Canvas AI Image Search recipe, which is still a work in progress
  • Under the hood, images get scaled to 400px wide and converted to PNG before they're sent to the model, which keeps things faster and cheaper
  • One caveat: your site needs an AI provider with a default "chat with image vision" model, and the recipe checks for that when it's applied
  • Also worth a look: the description prompt asks the model to describe people's age, gender, and ethnicity, and even name them if it can, so you may want to review that prompt for your privacy policies, and adjust accordingly
  • Like any recipe, it provides a robust starting point for some compelling features, and every prompt and setting can be tweaked after you apply it
  • Lastly, I wanted to mention that in today's Driesnote in here in Rotterdam, Dries demoed being able to use MCP to search images on his own site. A recipe like this could help you make sure the images in your media library have sufficient metadata to make that work reliably

A Drupal View does not have to end as a row of equal cards. Bento Showcase tests how far sorting, promotion, and image treatment can carry a structured content collection toward a composed page.

A large multilingual Drupal site took almost 20 minutes to self-install, which made every CI run painfully slow. Here's how a PHP profiler and an AI coding agent got it down to 90 seconds.

“We’ll add the tests later” only works if the tests are fast enough that nobody is tempted to skip them. On one of our large multilingual Drupal projects, they weren’t.

The site has content in 100 languages, around 200 modules, 400+ configured fields, and up to 5,000 config files once translations are counted in. Running drush site:install against that configuration took close to 20 minutes. Add Docker startup and the actual end-to-end test run on top, and a single CI pipeline run could easily take an hour. Copying the production database into CI wasn’t an option, so a full config-driven install was the only realistic way to get a clean site to test against for every change.

An install that slow doesn’t just cost CI minutes, it costs feedback loops. So we set out to find out exactly where the 20 minutes were going, fix what we could, and see how AI could shorten the loop of measuring, fixing and re-measuring.

Setting up a profiler

The first step was getting visibility into what Drupal was actually doing during install. We used SPX, a lightweight PHP profiler that’s easy to drop into a Docker-based PHP image alongside xdebug or blackfire alternatives, without much of the performance overhead those carry.

Once enabled, SPX gives you a web UI to browse individual profiles and see wall time, memory and call counts per function:

And for any profiled request, a flame-graph-style view of the whole call stack, with a sortable table of the most expensive functions underneath:

That’s already useful for a single page load. The interesting part is what happens when you point the same tooling at an AI coding agent.

Giving the coding agent access to the profiler

SPX ships an MCP server extension, SPX-MCP, which exposes recorded profiles through a query-like interface instead of a browser UI. Wiring it into an agent’s MCP configuration means the agent can list profiles, drill into a specific request, and pull out the functions responsible for the most time, without a human first opening a flame graph and squinting at it.

In practice, that turns “let me go look at a profile and tell you what’s slow” into a two-line prompt:

The agent found the three most recent profiles, correctly noticed they were regular page requests rather than the site:install run we actually cared about, and then, once pointed at the right report, broke a 1.44s homepage request down into HTML rendering, Twig compilation, class loading, cache reads and database time, each with concrete function names attached. That’s the same triage a developer would do manually, just a lot faster to get to.

The problem with profiling a 20-minute install

Profiling a single page request is straightforward. Profiling a 20-minute drush site:install is a different story: turning SPX on for the whole run produced one profile with almost 590 million calls, weighing about 8GB on disk. That’s too large to open in the web UI, and too large for an agent to reason about as a single blob.

The fix was to split it into one profile per install stage instead of one profile for the whole run. Drupal’s installer runs through a fixed sequence of tasks (install_select_language, install_config_import_batch, install_import_translations, and so on), and there’s a single place in core, install_run_tasks(), where each task starts and finishes. A small patch there starts and stops an SPX profile around each task and tags it with the task name as metadata:

--- a/core/includes/install.core.inc +++ b/core/includes/install.core.inc @@ function install_run_tasks(&$install_state, ?callable $callback = NULL) { $task = array_shift($tasks_to_perform); $install_state['active_task'] = $task_name; $original_parameters = $install_state['parameters']; + if (function_exists('spx_profiler_start')) { + spx_profiler_start(); + spx_profiler_full_report_set_custom_metadata_str(json_encode(['task' => $task_name])); + } $output = install_run_task($task, $install_state); ... + if (function_exists('spx_profiler_stop')) { + spx_profiler_stop(); + } } while (!$finished);

That turned one unmanageable profile into a dozen small ones, each scoped to a single install task, each cheap enough for the agent (or a human) to load and query directly. For the rare case of a profile that’s still too big, there’s also SPXQ, a small command-line viewer for browsing multi-gigabyte SPX reports without loading the whole thing into memory or a browser tab.

Finding the bottlenecks

With per-task profiles available, the workflow became a loop: profile a task, find the most expensive function, patch it, install again, and check the diff in timing. Doing that by hand, task by task, function by function, is tedious, exactly the kind of repetitive, well-defined work an AI coding agent is good at once it has direct access to the profiling data instead of having to be told what’s in it.

One of the clearest examples was the install_config_import_batch task, which turned out to spend the majority of its time in EntityStorageBase::doPostSave():

Digging into that call chain showed that saving a single field config was re-triggering hooks and cache invalidation for every entity type’s base field definitions, even when only one bundle had actually changed, and it was doing that for every field, of which there were hundreds. After each fix, the agent could re-run the install, pull the new profile, and confirm the improvement against the previous run.

What actually moved the needle

After several rounds of this profile-fix-reprofile loop, here’s what made the biggest difference:

1. Cache collection names. StorageComparer::getAllCollectionNames() was rescanning the sync directory to find language collections on every one of ~2,800 config items during import, even though the answer never changes. Computing it once per import and reusing it cut that step by 27.6%.

2. Cache translatable default config. LocaleConfigManager::getTranslatableDefaultConfig() rebuilt a typed-config wrapper once per language, even though the shipped default config is identical across languages. Caching it by config name cut this by 53.5%.

3. Cache isSupported(). The sibling of the fix above, doing two redundant config reads per language for an answer that doesn’t depend on the language. Caching it removed another 5.4%.

4. Scan the translation directory once. The same, usually-empty translation folder was being scanned for every project/language pair, up to 1,580 times. Listing it once and matching filenames against that list brought the whole step down to about 6ms.

5. Skip no-op config saves. LocaleConfigManager::updateConfigTranslations() was saving configuration even when nothing had actually been translated, reloading language override objects for all languages on every save. A simple !empty($processed) guard removed 237 unnecessary saves.

6. Stop force-rebuilding a cold field map. After every container rebuild, FieldDefinitionListener::onFieldDefinitionCreate() was forcing a full field map rebuild for every single field created during install. Skipping that while the map is still cold cut getBaseFieldDefinitions() calls by 76%, with no change to the resulting field map.

7. Narrow the cache clear on field save. This was the single biggest win. Saving one field config was wiping every entity type’s base field definitions and triggering a full plugin rediscovery. Clearing only the affected bundle’s field definitions during install cut this step by 18%, verified as producing byte-identical definitions across 37 entity/bundle combinations.

8. No-op the translation status key/value store during install. A small wrapper turns locale.translation_status lookups into an in-memory no-op during install (and passes through normally afterwards), avoiding repeated database hits for a value that’s meaningless mid-install.

9. Disable remote translation lookups for CI installs. During an automated test install there’s no reason to reach out to the localization server, so translation.import_enabled and related settings are simply turned off for that environment. This one is a CI-only optimization, not something you’d want in production.

10. Skip irrelevant entity hooks during install. Some entity_update/entity_insert hooks have no meaning during install or fixture loading. Guarding them behind $entity->isSyncing() avoided pointless work; for example, the Search API module’s _search_api_view_crud_event() handler.

None of these are exotic. Individually, most are the kind of “don’t redo work you already did” fix any Drupal developer would recognize once pointed at it. What changed was how quickly they could be found and verified: instead of manually reading flame graphs and re-running a 20-minute install to check each guess, the agent could query a profile, propose a targeted fix, and confirm the improvement against the previous measurement, over and over.

The result

After all of it: 1 minute 30 seconds, down from roughly 19 minutes 30 seconds. A 13x improvement on the number that mattered most for us, the total install time inside the CI pipeline.

Not every fix here is something we’d apply blindly to every project. Some, like skipping remote translation downloads, only make sense for a throwaway test install. Others touch Drupal core behaviour around cache invalidation and are being submitted as proper core patches with issues on drupal.org, since they need review and testing well beyond “it worked for us”.

Bonus

Both the SPXQ profile viewer and a reusable “profile, analyze, fix, validate” skill for coding agents are public:

• SPXQ, a CLI profile viewer for large SPX reports.
• A Claude/Codex skill that walks an agent through profiling, analyzing, fixing and validating performance issues on its own.
• The core patches from this round of optimization are collected in this gist.

Tags: Drupal Planet, Drush, Performance, AI, Drupal, DrupalCon

After watching the Driesnote (aka the keynote) from DrupalCon Rotterdam, I was inspired and overwhelmed by everything happening in Drupal that I need to catch up on.

Immediately, I should help get the new Tool API working with the Webform module, but first I need to work through the Webform module issue backlog. Second, I need to learn more about Drupal Canvas and start defining a roadmap for my organization to move to Drupal Canvas. Lastly, I have no experience with ECA, and now there's FlowDrop to look at too.

My new AI reality is that I'm generally no longer overwhelmed by new technical challenges because I leverage AI to help me learn and plan how to evolve my knowledge base and the applications I support. I've used AI enough, building and maintaining a Drupal site and its modules, to know just how capable today's frontier models are. At the same time, I struggle to communicate with AI and get it to understand my requirements to achieve my goals. During these struggles, I get slapped in the face with AI slop.

After deleting most of my agent skills and starting over, I began experimenting with one of the most popular agent skills, /grill-me, which proved to be a game changer.

The /grill-me skill was created by Matt Pocock and is mentioned in many Reddit threads. I was not sold on even trying it until I listened to Read More

File (Field) Paths is stable. 8.x-1.0 is the first stable release since the Drupal 7 one (long may it live), and it does what it has always done: sorts and renames your uploads with token patterns, so you get a filesystem you can read.

If you've been holding off while it sat in RC, you don't need to. It has 215 automated tests and 1287 assertions where beta8 had 21 tests, a safer default for where uploads wait, and a plan for what comes next. It's under active maintenance again.

Core file fields let you choose a directory, and that setting takes tokens. Drupal ships [date:custom:Y]-[date:custom:m] as the default. What it can't take is a token about the entity you're attaching the file to, because at the moment the file is saved those values don't exist yet. The file name isn't touched at all.

Continue reading →

In December 2017, on Ægir's tenth birthday, Steven Jones of ComputerMinds joked that within ten years Ægir would be an AI, setting up cat gif websites for its own purposes. With fourteen months left on the clock we checked how the prophecy is doing. In BOA, our Ægir hosting stack, the agent which keeps a server current is called Skynet since a 2012 commit meant to replace boring welcome messages, the installer still pretends to charge your credit card as it did in 2010, and the family named after a Norse sea giant and his doorman, Ægir and Eldir, grew a Barracuda, an Octopus and this summer a Kraken. Since 2025 the Ægir 3 projects on drupal.org are maintained by us, after the prophet himself asked, fairly enough, whether they should be marked obsolete, and in 2026 the stack is built with AI tools: eleven stable releases against three last year, for Drupal, Drupal CMS and Backdrop sites. The AI stays on our desks and nothing on your server guesses, so only the cat gifs are late.

Not every Drupal AI update calls for the same response. Recent releases may require teams to rebuild search indexes, update agent configuration or keep experimental Views changes under close human review.

Author: Christoph Breidert, Product Lead, Drupal AI

Earlier this year, the Drupal AI Initiative set itself a clear goal: at DrupalCon Rotterdam, show one Drupal site where AI search, content review, chat-driven editing, and AI translation all work together on real content. Today we are delivering on that promise. The Drupal AI Demo is live, and Dries revealed it in the Driesnote.

You can open it, use it, and see for yourself what Drupal AI looks like when it is built as a complete product. The demo is the website of a fictional university, with the kind of content and structure a real organization's site would have.

The Drupal AI Demo: a realistic, multilingual university website where every AI feature runs on the same content

From a list of features to something you can try

Until now, Drupal AI has mostly been something we described. We had roadmaps, feature lists, module pages, and conference talks. All of that was accurate, but none of it was tangible. A list of features asks people to imagine how the pieces fit together. A demo lets them see it.

That difference matters to two groups of people in particular.

If you are evaluating Drupal, the demo lets you test the AI features instead of reading about them. I believe Drupal is the most powerful AI-powered CMS available today. Until now, that was a claim you had to take on trust. Now you can check it yourself, try the features on realistic content, and plan your own website around capabilities that are already implemented and working.

If you already build with Drupal AI, the demo shows how each feature is intended to be used. You can evaluate every feature, see how it is configured, and adapt that setup to your own use case. That is a much better starting point than piecing together a feature from documentation alone.

What you can try

The demo focuses on the features our Drupal AI Partners told us matter most. In May, we asked them which capabilities they most wanted to have ready to use in Drupal. They are at the heart of the demo.

AI content reviews. Check a page against criteria like brand voice, legal requirements, and reading level, and get concrete suggestions for improving it.

AI content review scores a page against brand, legal, and readability criteria and suggests concrete improvements

AI search. Ask a question and get an AI-generated answer, grounded in the site's own content and with the sources behind it.

AI search answers a question with a summary, the sources behind it, and ranked results from the site's own content

Chat-driven content editing. Describe what you want to change, and the AI edits the page for you, right inside the editing experience.

Chat-driven editing: an editor describes a change in the chat, and the AI updates the page directly

AI translation. Move content across languages, with results good enough to publish.

AI translation moves a page into another language, ready for review and publishing

Connect your own AI agents. Connect agents such as Claude, ChatGPT, and others to Drupal through MCP, and make changes to the website from the outside.

An external AI agent, connected through MCP, making a change on the demo website

What makes the demo different from trying these features one at a time is that they all run together on the same site and the same content. That is what building a real website involves, and it is where the hardest work was.

How we got here

The idea of a demo was always there. We knew from the start that Drupal AI would need one, but first we needed a foundation strong enough to build it on.

The official Drupal AI sprints started in January this year. We spent the first three months refining the core AI functionality. By the second quarter, we had a stable code base to build on. In May, we ran the partner survey, and that was the moment the demo became a shared goal. The partners bought into the idea, and together we agreed on the features it should show. June went into preparation. In July, we started building.

The last eight weeks were the most intense. Between 1 August and 26 September alone:

• More than 100 people contributed code, reviews, or merge requests
• 1,442 commits landed across 54 projects
• 616 merge requests were merged on drupal.org
• Roughly 596,000 lines were added. That figure covers module code as well as the demo's content, theme, and configuration, and leaves out build output and lock files.

Activity grew steadily over those weeks, from about 70 commits in the first week of August to more than 300 per week in September. And the part I am most proud of is not the size of those numbers. It is that the result simply works.

Weekly commits across the demo and the drupal.org projects it builds on, 1 August to 26 September 2026

The people who built it

The demo was built by contributors from across the Drupal AI Partners, the organizations that fund and staff this initiative, together with many contributors from the wider Drupal community. Working together, we could build a more advanced AI experience than any of us could have built alone, and everything we build for the demo makes Drupal AI better for everyone who uses it.

Most of the load of the demo itself was carried by four people: Marcus Johansson, Artem Dmitriiev, Aidan Foster, and myself. Marcus, Artem, and I also met in person for three days to do nothing but sprint on the demo. Some of the hardest problems got solved in that room.

[IMAGE 8: sprint photo]

Marcus Johansson, Artem Dmitriiev, and Christoph Breidert during their three-day, in-person demo sprint

Many others did substantial work on the demo itself. I want to thank Darren Oh, Kristen Pol, Abhisek Mazumdar, Dan Lemon, Eric Homanchuk, Akhil Babu, and Kiran Kadam.

Of course, a demo is only as good as the modules underneath it, and many projects were heavily developed to be ready for Rotterdam. The main contributors there include Giorgio Alfredo Pagano on AI Disclosure, Michael Lander and Matt Glaman on the Tool API, MCP Server, and Canvas tools, Kristen Pol on AI Context, Rob Loach, Scott Euser on AI Search, Ahmad Khader on AI Content Review, and Sven Decabooter on AI Translate. Much of this work also depended on review: Artem and Marcus alone merged more than 100 merge requests from other contributors in these two months.

A personal note

Coordinating a distributed effort of this size, with contributors across many organizations, countries, and time zones, in such a short time is its own kind of challenge. My role was to set the direction, define the work packages, and align with key contributors and organizers to make sure we were building the right things. I also reviewed a great deal of work along the way. The day-to-day operations were led by our delivery managers, Arian Raeesi and Vidit Anjaria, who planned the work into sprints and kept it moving every day.

What I had never seen before is so many people building something together that actually works as one. Being part of that is amazing.

The demo was something I had in my head for a long time. Seeing so many people take that idea and make it real, and seeing it work, is one of the most rewarding experiences I have had in the Drupal community.

To everyone who contributed: thank you. This demo is yours.

Try it, and help us make it better

The demo is live at drupal.org/ai/demo. Try it, test it, and tell us what you think.

If you want to help shape what comes next, join us in the #ai-initiative channel on Drupal Slack, or explore becoming a Drupal AI Partner.

Everyone who contributed between August and September 2026

Abhinav Jha, Abhisek Mazumdar, Abhishek Dhariwal, Adam G-H, Adrian McKee, Ahmad Khader, Ahmad Khalil, Aidan Foster, Akhil Babu, Alex Urevick-Ackelsberg, Andrei Mateescu, Andrii Sakhaniuk, Angela Saldaña, Anikó Viola, Ann Mary Sruthy, arne michiels, Artem Dmitriiev, Ashish Dalvi, attilatilman, Avinash jha, Bharat Kelotra, Brooke Mahoney, Bruna Emerich, Bruno Bruno, calmforce, Carlos Romero, Cesar Miquel, Chad Peppers, Christian Burk, Christoph Breidert, Craig Wood, Dan Goodwin, Dan Lemon, Daniel Rodriguez, Darren Oh, Dave Long, David Bravo, Denise Spangler, Dezső Biczó, Dimitris Spachos, Dries Buytaert, Emma Horrell, Eric Homanchuk, George Kastanis, Giorgio Alfredo Pagano, Ignacio Pérez Puertas, István Csáki, Jeff Warrington, Jeremy Cerda, Jibran Ijaz, Joonas Meriläinen, Jordan Graham, JoshHayter, Joshua Fernandes, Juan Correa, Jurriaan Roelofs, Jérôme Tchania, Jürgen Haas, Kenneth Bolívar Castro, Kieran Cott, Kiran Kadam, KJ Monahan, Konstantine Kirkitadze, Kristen Pol, Lee Rowlands, Levente Besenyei, Manuel Garcia, Marcus Johansson, Markus Kalkbrenner, Mateu Aguiló Bosch, Matt Glaman, Matthew Tift, Michael Lander, Miguel Guerreiro, Narendra Singh Rathore, Nick Opris, Nick Pasiuk, Nik LePage, Norman Kämper-Leymann, Pieter Frenssen, Prabhavathi Vanipenta, Pravesh Poonia, Punam Aseem Beedkar, Reinhold Schachner, Ricardo Castañeda, Richard Porter, Rob Loach, Rodel Duterte, scontzen, Scott Euser, Scott Falconer, Sergiu Nagailic, Shashank Rai, Shibin Das, Shivam Sen, Simon Morvan, Sven Decabooter, szato, Tamas Balog, Tekla Aivazashvili, Tormi Tabor, tribekk, Valery Lourie, Will Huggins, Wolfgang Ziegler.

The official Drupal AI Demo is live. Explore how Drupal AI features work together in one real-world demo!

The DriesNote at DrupalCon Rotterdam made one argument above all: Drupal is light-years ahead of its reputation. The strongest evidence was on screen. These six demos show a platform that speaks more languages, welcomes JavaScript developers as first-class citizens, and treats AI assistants as another interface to Drupal, with governance built in.

Everything here is open source and available today. Here are the demos, with the story behind each one.

1. Multilingual sites, easier to build

80% of the world doesn't speak English as a first or second language, so multilingual is how Drupal reaches billions more people. Two things used to hold teams back: setup was hard, and Drupal Canvas didn't yet support multilingual content. Drupal CMS 2.2 changes both, with a language selector right in the installer, a guided Multilingual add-on, three levels of translation configurability, and full translation support in Canvas, including review workflows and optional AI translation. Watch for Dashi, a multilingual food magazine template made entirely by Drupalers.

2. JavaScript as a first-class citizen

JavaScript front ends are where many developers start their careers, and Canvas is built for them: a standalone front-end project scaffolded in one command, with React, TypeScript, and Tailwind CSS, previews via Canvas Workbench with zero configuration, and AI coding agents in the workflow. One push with the Canvas CLI and everything is ready for content teams to use visually. No Drupalisms, no trade-offs.

3. Canvas Headless: your choice of front end

Organisations often compose experiences from multiple backends, and that calls for a headless front end. Canvas Headless connects yours by configuring a URL, with Canvas visual editing built in: editors see a live preview of the real application while developers build in the framework they prefer. Starter templates cover Next.js, Astro, Nuxt, and TanStack Start, and Angular support arrived the very week of the keynote, five frameworks in all.

4. Try Drupal AI for yourself

There's been so much Drupal AI work that demoing it all would fill the keynote. Instead, there's now a demo experience anyone can try: a fictional university site where AI reviews every page against your standards, visitors get answers drawn from your own content with sources shown, and guardrails, a central knowledge hub, and full logging keep it accountable. It's working today, open source, built by leading Drupal AI companies, and pre-configured so you can also use it to show customers. Try it at drupal.org/ai/demo.

5. Fixing content with an AI assistant

A content editor spots Dutch translations showing prices that shouldn't be live yet. From ChatGPT, connected with her own account, she asks for the previous Dutch versions back, English untouched. It happens, with every change recorded as a new revision under her name. She didn't need to know where to click or how revisions, moderation, and permissions work; Drupal handled the governance behind the scenes. You can do this today with a recipe combining Simple OAuth, MCP Server, and the Tool module, built by Michael Lander, Matt Glaman, and others: drupal.org/project/agent_access

6. One module, many interfaces

The most surprising demo wasn't about AI at all. Dries's personal site holds more than 10,000 photos in a custom album module he tool-enabled himself, the work behind his "describe once, use everywhere" idea. The creator of FlowDrop, a visual workflow tool for Drupal, showed that module's MCP server powering a plain form, searching photos and albums with no AI anywhere, and then an agent that chooses its own tools to answer questions. When capabilities are described once and answers come back structured, AI becomes a choice, not a requirement. That idea is what the upcoming Rosetta Sprint will take forward.

Watch the DriesNote in full, or read the full recap of everything Dries announced, from digital sovereignty to the Drupal Advocacy Program.

In a major shake-up, your advocacy work now earns Drupal contribution credit.

Drupal is now light-years ahead of its reputation. It's time we changed that.

The Drupal Advocacy Program is a new Drupal Association pilot that awards contribution credit for work that helps people discover and understand Drupal.

Drupal is light-years ahead of its reputation. The platform has changed dramatically in recent years, but the market's picture of Drupal runs years behind. If you have ever heard "oh, is Drupal still around?", you have felt that gap first-hand — and research by major Drupal agencies confirms it. The fix is not a bigger ad budget. It is education at community scale: authentic stories from the people who build with Drupal, told in their own voices to the audiences they know best.

Our community can be uneasy with the word "marketing". But you are already advocates for Drupal, day in and day out — and that is exactly what this moment needs. If you have ever written a tutorial, recorded a demo, translated an article, or shared someone else's talk with a new audience, you have been doing advocacy. Starting today, that work earns recognition.

How it works

Tell the story. Create, share, and boost content about modern Drupal. A blog post for your market. A video for your audience. A talk at a non-Drupal conference. A customer story in your language. And amplification counts: share someone else's DrupalCon talk or case study, tell us about it, and you earn credit too.

Themes multiply your impact. Four to six times a year, we will roll out a theme — a consistent message with messaging and proof points ready to build on. Take it and make it your own: translate it for your language, reframe it for your industry, make it relevant to your network. Advocacy content on the current theme earns 2x–3x credits, because 126 certified partners and a huge global community telling one story at the same moment is what moves the market. 

Credits flow back. Advocacy runs through the same contribution credit system that recognises code. It counts toward your standing in the ecosystem, including Drupal Certified Partner visibility. Credits will be awarded in bulk each month, guided by a published scale (to come), weighted by quality and reach, because we want content that travels beyond the Drupal world. Each month we will also spotlight the best advocacy content and award it extra credit.

The ground rules are simple. This is about promoting Drupal and what Drupal can do. You can mention where you work, and you can absolutely draw on case studies from your own business — as a way of showing what Drupal makes possible.

Ways to take part

• Post. A thoughtful LinkedIn article or thread in your own words
• Write. A blog post specific to your audience, region, or industry
• Record. An explainer, tutorial, reaction, or customer-story video
• Boost. Share and amplify someone else's talk, case study, or post
• Adapt. Translate or localise the story for your language and market
• Speak. A talk or lightning talk, especially at non-Drupal events and meetups
• Pod. Appear on or host a podcast episode
• Show your work. A customer or project story that highlights what Drupal can do
• Teach. A tutorial, demo, or code walkthrough that shows modern Drupal in action

Choose something that fits you. You do not need to become a salesperson. As Dries put it in his DrupalCon Rotterdam keynote: Drupal doesn't need hype. It needs a better public record.

Submitting is simple

For now, it is a short form at drupal.org/advocacy. In the coming days you will also find a submission form across many Drupal Slack channels. Either way, telling us about your content should take a minute — because for this to work, submitting needs to be exceedingly easy.

This is very much a pilot. We will start by reviewing and crediting submissions by hand, look for ways to automate over time, and let what we learn from your submissions shape how the program grows. And we want to celebrate the people who lead the way: at next year's DrupalCons, we will present awards to Drupal's biggest advocates.

Start today

Every story you tell adds to Drupal's public record — the record that search engines, AI assistants, and agentic search increasingly draw on when people ask what to build with. More authentic voices means Drupal showing up where decisions are actually made.

Submit your advocacy work at drupal.org/advocacy. You will find the current theme, its messaging and proof points, and guidelines on attribution and what qualifies for credit.

You have done the work. Now start talking.

File attachments:  06-advocacy-hero.png

The winning projects span AI, public services, publishing, education, healthcare, commerce and other areas of Drupal implementation.

Watching the DriesNote at DrupalCon Rotterdam, one part of Dries Buytaert's argument felt immediately familiar.

Key takeaways from the DrupalCon Rotterdam Driesnote: MCP support through PHP attributes, Canvas updates, and a new Drupal advocacy program.

What Migrate Plus adds to core, when a custom source plugin is the right answer, and the anatomy of one that survives real data, with working PHP and YAML.

I’ve worked in several settings where technical people announced their focus was on the technology, not the user of the technology. They would say things like: “I don’t care what they do, I just want to build it.”

This is a terrible way to work. It leads to bad solutions and miscommunication.

You cannot find the flaws in the spec, and there are always flaws, if you cannot sanity check it yourself. You cannot know for sure your solution worked if you don’t know what the data means and how it is used.

The Importance of Understanding

When my wife and I attended the Polo match pictured above we tried to ask some of the regulars basic questions about what was happening. They responded to us using all the words of the sport, but not in a way we could understand. If they wanted to attract new fans to the sport, they needed to explain the game to us in words we understood. It got even worse when a horse got injured and no one really explained what was happening until the ambulance trailer pulled onto the field.

To do our best work we need to understand the end goal of our users. The most effective way I know to communicate clearly is to use the same language as my audience does when talking about their work. If you try to force them to use the terms and phrases you know best they will likely make mistakes that cause you problems.

We must meet our audiences where they are.

When I was a Drupal developer, I was creating web sites that were customized to a specific organization’s needs. When I was a Salesforce consultant and developer, I was tailoring the platform to handle the specific needs of those users. In my role inside a nonprofit energy company I am making sure our Salesforce org meets our needs.

What was common across all those roles is that I needed (and still need) to talk with my users and understand their needs and the work they need the tool to do for them.

Problems with Failure to Understand

When I was a web developer, often the spec I was working to support was a graphic design. The designers would create a very attractive design, the client would approve it, and I was told to go implement it. Drupal, of course, can be implemented many different ways. To create a good implementation I needed to understand the designer’s intent and why the client liked the design (beyond it being pretty). I would ask why images were placed where they were, not to challenge the design but to make sure I called them the right thing in the backend. Those names were important to the content editors to help them select the right image in the future.

Working with Salesforce brings the same challenges. To understand if a Flow is working right, or even worth building at all, I need to know what the user expects to happen and why. When organizing a page layout, I need to know which information is most important and what fields are related to group them sensibly.

A Quick Note About Ethics

A complete discussion of the ethics of technology is impossible here; it’s a whole field of thought within Philosophy. Still we all should care how our work impacts the world. If I create a tools that’s helping someone commit evil, I’m supporting that evil. There is a mountain of nuance and detail to be thought through.

Just because the topic is huge and complicated does not free us from the basic responsibility to care about it. When someone tells me they don’t care how the technology is used, they are implicitly announcing they are comfortable supporting outcomes they consider evil.

When Do I Know Enough?

Probably never.

Over the course of my career so far I have worked on projects that involved:

• International peace and conflict resolution efforts
• The US federal budget
• Private prisons
• Economic empowerment of women in Africa
• Lobbying at the federal and state levels
• The DNS system
• Youth empowerment in the US and other parts of the world
• Explaining Quakerism
• Phone system setup and operation
• Desktop computer and server hardware
• Web development
• Web site infrastructure
• Virtual machines
• Open source licenses
• Copyright (copyleft) and trademarks
• General nonprofit fundraising techniques and strategies
• Basic accounting practices
• The child welfare system in several US states
• Life guarding and water safety
• Natural disaster planning and response
• Rules for credit card processing and security
• Sales of kayaks, canoes, and other related products
• Advanced and basic marketing strategies
• Chemical coatings for packaging
• The US sales tax “system”
• The energy industry in California and generally around the US
• …and probably a bunch of other stuff I’m not thinking to include

While that might be a little more than is average in just over 25 years of professional life it’s probably not all that high for someone with a similar career track. If you’ve been working for a few years, think about all the different things you have had to work on – it’s a bigger list than you’ll expect.

All of that learning can be exhausting; I understand the temptation to say “I know enough, I don’t need to know more.” But if I want to keep getting chances to advance, I need to be ready to understand the next thing I need to know.

It helps to be curious.

How Tag1 Reviews Code with AI covered the tools Tag1 built to put AI into the PR review process. This post shows the pattern: AI drafts your whole review into GitHub pending reviews or GitLab draft notes, and you decide, line by line, what gets published under your name.

Where AI Fits in Code Review

AI is good at the unglamorous parts of review: actually reading every line of a large diff, knowing the obscure API pitfalls no single reviewer carries in their head, checking the change against the rest of the codebase for consistency, and asking every "what if this input is empty" question without getting bored. What it can't tell you is which of its twenty comments actually matter.

There are two ways to put that to work, and they're not in competition. The first is the one most people have seen: a bot that reads the pull request and posts its review straight to it. That's a good fit for CI and merge gating. Tag1's own ai-pr-review runs on every push, combining deterministic scanners with AI reviewers, and can gate merges on what it finds: a leaked credential, a known CVE, a phpstan error, or a logic bug an agent caught.

The second way is quieter, and easy to overlook. Both GitHub and GitLab have a staging layer for reviews: comments you write that nobody else can see until you press submit. GitHub calls it a pending review; GitLab calls them draft notes ("Start a review"). Point your AI at that layer instead of at the publish button and you get the machine's thoroughness with a person still accountable for every published word. That's what this post is about, and it's what you want when the review goes out under your name, especially when you're the gate a client is paying to stand between their code and their production site. There, the reviewer of record should be someone who read the change and chose to sign it.

The Workflow

The workflow has four steps:

1. AI reads the PR and writes review comments into a pending review, under your account, visible only to you.
2. You open the PR in the normal web UI, and edit, delete, or add comments like you always do.
3. Optionally, ask the AI to look at your edited pending review and flag anything you missed or got wrong. Repeat.
4. You press submit. Every published word is one you chose to publish, under your name. You can wire this up yourself, which is what the rest of this post covers. If you'd rather start from something prebuilt, Greg Chaix's comprehensive-review already packages the pattern: it runs the review locally and can stage its findings as a draft review for you to edit and submit.

GitHub: Pending Reviews

When you comment via "Start a review" in the Files changed tab, GitHub holds the comments in a pending review — they're "pending and only visible to you," per GitHub's docs, until you submit as Comment, Approve, or Request changes. The same states exist in the REST API: create a review without an event and it lands in PENDING; a second call to .../reviews/{review_id}/events submits it; DELETE abandons it. Each user gets one pending review per PR. GitHub doesn't seem to document this anywhere, but the API enforces it with a 422 error: "User can only have one pending review per pull request."

The detail that matters is that if the AI authenticates with your token, the pending review it creates is yours. It shows up in your browser as your own draft, fully editable.

One approach for integrating AI into human-owned reviews is the official GitHub MCP server, which wraps everything in purpose-built tools. One command connects it to Claude Code (create a Personal Access Token (PAT) with repo scope first):

claude mcp add --transport http github https://api.githubcopilot.com/mcp \ -H "Authorization: Bearer YOUR_GITHUB_PAT"

This exposes the purpose-built tools: pull_request_review_write to create, submit, or delete a review, and add_comment_to_pending_review to add inline comments to your latest pending review. Then, prompt with something like:

Review PR #123 in tag1/example. Read the full diff. Start a pending review and add inline comments only for real problems: correctness, security, performance. Prefix each with Critical/Minor/Nit. Do NOT submit the review; I'll edit and submit it myself.

Because the agent runs as you, a second round works too: "I've edited the pending review. Read it back, tell me what I misjudged, and add pending comments for anything I missed."

The gh CLI is the more dependable approach. There's currently no native pending-review command for gh pr (no gh pr review --draft), but gh api can do it in a single call with nothing extra to install, and when Claude Code prompts you to approve the call it shows the full comment text in a readable form which the MCP doesn't.

# Create a pending review with inline comments (no "event" = stays pending) gh api repos/tag1/example/pulls/123/reviews --input - <<'EOF' { "body": "First pass by Claude; edited by Jeremy.", "comments": [ { "path": "src/Form/SettingsForm.php", "line": 87, "side": "RIGHT", "body": "Critical: user input is concatenated into the query; use a placeholder." } ] } EOF

You then edit and submit in the web UI. The one thing gh api can't do is append comments to a review you've already started: the REST endpoint only accepts comments at creation time, and the append path needs GraphQL, as discussed in the GitHub community. That's the case where the MCP server has an advantage, since it does the GraphQL for you.

GitLab and Drupal: Draft Notes

For those of us in the Drupal ecosystem, most contribution happens through GitLab merge requests on git.drupalcode.org. Fortunately this uses the same pattern, but with different names.

In the UI, Start a review / Add to review keeps comments unpublished and visible only to you until you submit (with Approve, Comment, or Request changes). This is a Free-tier feature, so it works on any GitLab deployment.

The GitLap API calls them draft notes. To use them, you first need to point glab at the right instance (create a personal access token with api scope in your GitLab profile settings). Swap git.drupalcode.org for your own GitLab host (gitlab.com or your self-managed instance).

glab auth login --hostname git.drupalcode.org

Inline comments need diff SHAs, which come from the merge request itself. Run these inside your clone of the project:

# Get the SHAs the position object needs glab api projects/:id/merge_requests/42 | jq .diff_refs # AI (or you) stages an inline comment; nobody else sees it glab api projects/:id/merge_requests/42/draft_notes --input - <<'EOF' { "note": "Minor: this hook is missing a cache tag for the config entity.", "position": { "position_type": "text", "new_path": "src/EventSubscriber/CacheSubscriber.php", "new_line": 54, "base_sha": "<diff_refs.base_sha>", "head_sha": "<diff_refs.head_sha>", "start_sha": "<diff_refs.start_sha>" } } EOF # Later, YOU publish, or just click "Submit review" in the UI glab api -X POST projects/:id/merge_requests/42/draft_notes/bulk_publish

GitLab's official MCP server (beta, Premium/Ultimate) can read MR diffs and pipelines but doesn't expose draft notes yet, per its tool list, so on GitLab the dependable recipe is to let the agent read the MR however it likes, but have it stage comments through glab api .../draft_notes. Drop the commands above into your project's CLAUDE.md and Claude Code handles the SHAs and line positions itself.

Two Rules

Two simple rules guide the workflow. First, tell the AI explicitly, every time, that it must never submit, approve, or publish anything; staging comments is its entire job. Second, run it with your own credentials, because draft comments are only editable by their author, and the author should be you.

The AI delivers the efficiency: it reads every line of the diff in minutes and never gets bored or distracted. You deliver the quality: your judgment decides what's real, what matters, and how to say it to a colleague, and the AI's optional second pass over your edits catches what you missed. Because nobody else sees the pull request until you've read it, shaped it, and chosen to sign it, you stay in control of the review from first comment to submit button. You're not choosing between doing reviews faster and doing them well. Done this way, AI helps you achieve both.

A recent post on Bluesky asked a common question: with dozens of DDEV projects, what is the fastest way to get to one? The current routine was to open Finder, dig three folders deep, drag the folder into an editor, and then run ddev start. Another post mentioned 52 projects and no idea which ones are running. Here are the techniques we use and that came up in the replies.

See What Is Running: ddev list

ddev list shows every project DDEV knows about, with its status, location, URL, and type. The underlined locations and URLs are terminal hyperlinks you can click.

To see only the projects that are running, use ddev list --active-only (or ddev list -A). ddev poweroff stops every running project at once.

Clickable Links

Hold Cmd (macOS) or Ctrl (Linux and Windows) and click a link. A location opens in your file manager, and a URL opens in your browser.

DDEV adds links only in terminals it recognizes, including iTerm2, Ghostty, WezTerm, Kitty, Alacritty, Windows Terminal, VS Code's integrated terminal, GNOME Terminal, and Konsole. The macOS Terminal app doesn't support them, so on a Mac, iTerm2 is a good choice if you want clickable links or even if you just want to live a long and happy life.

If nothing is underlined:

• Upgrade DDEV. Links need v1.25.3 or later.
• Check that links are turned on in your terminal. Konsole has them off by default. To turn them on, enable "Allow escape sequences for links" under Settings > Edit Current Profile > Mouse > Miscellaneous.
• If you use tmux or screen, DDEV can't detect your terminal. Add export FORCE_HYPERLINK=1 to your shell startup file to turn links on anyway.

The DDEV Dashboard: Just Type ddev

Running ddev or ddev tui with no arguments opens an interactive terminal dashboard that lists all of your projects and their status. You can start, stop, and restart projects, open a project's URL or Mailpit in the browser, and press Enter for a project's details. For someone with 52 projects, this may be the quickest way to see what is running.

With many projects, the most useful key is /, which filters the list as you type. The filter matches part of a project's name, type, status, or directory, ignoring case, so dr finds every Drupal project, running shows only running projects, and client finds every project under a client directory. Move to the project you want, and start it with s or open it with l. See the interactive dashboard documentation for the full list of keys.

ddevcd: Built-In Project Jump

DDEV ships a shell function that changes to a project's root directory by name:

ddevcd some-project

It needs a one-time addition to your shell startup file. ddev utility cd prints the exact line for Bash, Zsh, or fish. See the utility cd documentation.

ddevcd works from any directory, and it has tab completion for project names like the rest of DDEV. Typing ddevcd pr<tab> completes to something like ddevcd pr8859-test.

autojump: Jump by Partial Name

autojump learns the directories you visit and lets you jump to them with j and part of the name. It works for any directory, not only DDEV projects.

brew install autojump # Or `sudo apt install autojump`, etc # Follow the post-install instructions to source it from your shell rc file j myproject ddev start

If you only need to start a project, you don't have to change directories at all: ddev start <projectname> works from anywhere.

Note that autojump only knows directories you have already visited (unlike ddevcd, which knows every project DDEV has seen).

code . or phpstorm .: Open the Editor From the Project Directory

Once you are in the project directory, open it in your editor from the terminal.

For VS Code:

code .

For PhpStorm:

phpstorm .

Each command opens the current directory as the project, and reuses the window if that project is already open.

The commands have to be installed first:

• VS Code: Run "Shell Command: Install 'code' command in PATH" from the Command Palette.
• PhpStorm: Use Tools > Create Command-line Launcher in PhpStorm, or the shell scripts setting in JetBrains Toolbox. On macOS, open -a PhpStorm . also works without a launcher script.

Other editors follow the same pattern, for example cursor . for Cursor.

Put it all together to get from anywhere to a running project in your editor:

ddevcd myproject && ddev start && code . ddevcd myproject && ddev start && phpstorm . Click the Link in ddev describe

ddev describe has a short alias, ddev st, which is easy to type and worth adopting. It prints the project's details, including the project's location on disk.

The project location (~/workspace/ddev.com in the header above) is a clickable link that opens your file manager at the project root.

Advanced: Answer Fancy Questions With ddev list -j and jq

ddev list -j prints the project list as JSON, and jq can answer more specific questions. The project data is under .raw. Each entry has fields including name, approot, status, type, and primary_url.

Running projects and their directories:

ddev list -j | jq -r '.raw[] | select(.status=="running") | "\(.name)\t\(.approot)"'

Names of all Drupal 11 projects:

ddev list -j | jq -r '.raw[] | select(.type=="drupal11") | .name'

The directory of one project, which you can use with cd or code:

code "$(ddev list -j | jq -r '.raw[] | select(.name=="myproject") | .approot')" Community! Third-Party DDEV GUIs

If you would rather click than type, the community has built several graphical front ends for DDEV. They sit on top of the DDEV command line, so your projects and .ddev configuration stay the same. The DDEV project doesn't maintain or endorse any of these, and this list comes from our newsletters and from reports by their authors. Try them and judge for yourself.

In Your IDE

• DDEV Integration plugin for PhpStorm and IntelliJ, maintained by AkibaAT.
• DDEV Manager extension for VS Code, by Biati Digital.

macOS

• DDrovr is a new native macOS app from Bison Digital that shows all your projects on one dashboard. It offers one-click access to URLs, terminal shells, and logs, detects the project's CMS, highlights startup failures, and searches projects with Cmd-K. It needs macOS 14 or later and DDEV v1.24 or later, and works with OrbStack, Docker Desktop, and Colima. It is a download from the site, and the site lists no pricing or source repository.
• ddevbar is a menu bar app by Klemens Arro for starting, stopping, and restarting projects with a click.
• DDEVUI is a native app written in Swift and SwiftUI.

Cross-Platform

• ddev-ui is an Electron and React app for macOS, Windows, and Linux. It covers project management, database import and export, snapshots, add-ons, and log streaming.
• DDEV Manager GUI by VonLoxx is another desktop wrapper.
• DDEV GUI by ChaosKing has been tested only on Linux.

Commercial and Agency Tools

• DevWorkspacePro by damms005 is a commercial wrapper GUI. When we last looked it had no free trial.

Didn't find yours? The June 2026 newsletter covers some of these tools as well. If you built a DDEV GUI, send a PR adding it here.

Tell Us What We Can Do To Make DDEV Better For You!

We know this is awkward territory, and we're always listening to you, and want to know what we can do to make it better.

Contributions welcome!

Your suggestions to improve this blog are welcome. If you have a technique for getting around your projects that isn't here, you can do a PR to this blog adding it. Info and a training session on how to do a PR to anything in ddev.com is at DDEV Website For Contributors.

Follow the DDEV Newsletter for information about upcoming user and contributor training sessions.

The Cost of Waiting: Why CMS Maintenance Belongs in Every Website Budget Joel Steidl Tue, 09/29/2026 - 15:34 Process Drupal WordPress Backdrop CMS

Launching a website is a major milestone, but it does not mark the end of the investment.

Drupal, WordPress, and Backdrop are actively maintained software platforms. Core software changes. Modules and plugins release updates. Security vulnerabilities are discovered. PHP and other underlying technologies move through their own support cycles.

During a long website build, teams should be paying attention to those changes and applying updates when they make sense within the project cadence. That does not necessarily require a dedicated line item for updates. It does require recognizing that the software will continue to change while the site is being built.

The more important planning conversation is what happens after launch. Post-launch budgets often focus on new features, enhancements, and fixes specific to the site. Routine platform maintenance has to be planned alongside that work, or it is easy to defer indefinitely.

Updates are part of operating a CMS

Different content management systems handle releases differently.

Drupal has a well-defined release cycle, including regular windows for bug fixes and security releases. Backdrop similarly publishes scheduled minor releases and security release windows.

WordPress is less predictable. Core releases do not follow the same kind of monthly schedule, while plugins and themes are updated independently by their maintainers. For WordPress sites, that makes proactive monitoring particularly important. Checking for updates weekly or bi-weekly can help teams identify changes before they accumulate.

The operational lesson is more important than the differences between platforms: someone needs to be responsible for keeping track of change.

For WordPress, the Site Health screen provides a useful view into outdated software and configuration issues. Drupal and Backdrop have their own tools and processes for monitoring available updates and security advisories. But knowing an update exists is only the beginning.

Updates still need to be evaluated, tested, and deployed.

Small updates are easier to manage than large ones

Consider a site that receives routine maintenance every month.

There might be a core update and several module or plugin updates to review. The team applies them in a development or staging environment, tests critical functionality, resolves any issues, and deploys the changes.

Now consider the same site after maintenance has been deferred for two years.

There may be dozens of pending updates spanning multiple versions. Some dependencies may no longer be maintained. A newer module or plugin may require a newer version of the CMS. That version may require a newer version of PHP. Custom code written several years earlier may no longer behave as expected.

What could have been a series of small maintenance tasks has become a project.

The difficulty is not simply the number of updates. It is the number of things changing at once. When something breaks, there are more possible causes. Testing takes longer. Troubleshooting becomes less predictable.

Regular maintenance keeps those changes smaller and makes risk easier to manage.

Maintenance has to compete with improvement work

After launch, most organizations still have a list of things they want to change. Editors need improvements to a workflow. A department wants a new feature. An integration needs adjustment. Bugs emerge once more people start using the site.

That work is visible, and its value is usually easy to understand. Routine maintenance is less visible. Updating a dozen modules and ending up with a site that looks and behaves exactly as it did before can be difficult to prioritize against a feature someone has been waiting for.

But those two kinds of work need to coexist.

For many sites, a recurring monthly maintenance allocation is a sensible baseline alongside a budget for improvements and feature development. It creates room to review available updates, apply appropriate changes in a non-production environment, test important workflows, and deploy deliberately without forcing that work to compete every month with the next feature request.

The exact cadence can vary. WordPress sites may warrant weekly or bi-weekly checks because plugins and themes release independently. Security updates on any platform may require attention outside the normal maintenance cycle.

Testing matters too. A plugin update that looks routine can conflict with WordPress core or another plugin. A Drupal module update can affect custom functionality or configuration. Updates should generally move through development or staging before reaching production.

Backups are another part of the equation, particularly for WordPress sites where application state and content are closely connected to the database. Reliable, automated backups, preferably managed at the hosting level, provide an important recovery path when an update does not behave as expected.

The goal is not simply to install updates. It is to make maintenance a normal part of operating the site rather than something that only gets attention when there is a problem.

Maintenance starts before launch

Planning for maintenance does not mean every build needs a separate maintenance workstream.

During an active build, teams can often incorporate core, module, plugin, and dependency updates into the normal development process. What matters is that the team is paying attention. On a project that lasts six months, a year, or longer, building against a frozen snapshot of the software and waiting until launch to address updates creates unnecessary risk.

Decisions made during the build also affect how difficult future maintenance will be.

Every module, plugin, theme, integration, and piece of custom code becomes part of the site's long-term maintenance surface. Before adding a dependency, teams should consider whether it is actively maintained, how important it will be to the site, and what replacing it would involve if support ends.

Architecture matters as well. Clear separation between custom code, contributed software, configuration, and content makes future changes easier to understand and test. Automated tests around critical functionality can make routine updates considerably safer.

The same thinking applies beyond code. Structured content, consistent components, and well-defined editorial workflows reduce the number of exceptions teams have to account for when the platform changes.

Maintainability is not a separate phase of the build. It is one of the considerations that should inform how the platform is built.

The cost of waiting

Skipping maintenance can look like a savings because nothing happens immediately. It can also create more room in the budget for improvements that stakeholders can see and use right away.

But the maintenance work has not disappeared.

Updates continue to accumulate, dependencies continue to change, and older versions eventually stop receiving support. When the organization finally has to act, the work is usually larger and the options are more constrained.

A recurring maintenance budget helps turn that unpredictable future project into routine digital operations. It gives teams a chance to make smaller changes, test them carefully, and identify larger lifecycle issues before they become urgent.

That does not mean maintenance should consume the entire post-launch budget. Websites need to improve as organizational needs change. The goal is to make room for both: maintaining the platform you have while continuing to make it better.

The cost of waiting is not just more updates later. It is giving up control over when and how those updates happen.

James Nettik