webjoke.de

Drupal Meets Matrix part 2: Live Comments with ECA and HTMX John Locke Sat, 10/10/2026 - 12:00

A comment thread in Drupal works totally fine. You fill in a form, click submit, and your comment gets posted. Same way it has for over 20 years.

But if somebody else replies when you're on the page, you don't see anything change, you don't get any notification.

Dev Corner

• Read more about Drupal Meets Matrix part 2: Live Comments with ECA and HTMX
• Add new comment

Read more

Opening DrupalCon, a summit

DrupalCon Rotterdam: building Drupal’s AI future togetherdrupalSaturday, October 10, 2026 - 19:41

Can it be all so simple? Migrating a 13-year-old WordPress blog to Drupal CMS Image

Can it be all so simple? Spoiler: no, it can't. But it was fun.

Can It Be All So Simple (CIBASS for friends, and yes, the name comes from the Wu-Tang Clan song) is a Spanish blog about cinema, music, comics, TV series and culture that has been publishing since 2013. Some friends started it, and later a bunch of others joined, including me. I ended up hosting it and doing its maintenance for years. And we even ended up earning an award.

It ran on WordPress all that time. Maintenance was painful. In 2021, I alleviated part of that pain by migrating it to roots/bedrock and managing updates with Composer, but still, I wanted to migrate it to Drupal at some point. If you explore its contents, you will end up finding quite a few articles written by Drupal people. 

On October 1st, 2026, thanks to Drupal CMS 2.2.0 and its multilingual support improvements, that could finally happen. Even if activity on the blog has been at its lowest, I still wanted to do that to keep the site online with minimal maintenance, while I refuse to accept that the project is almost dead. 

What we were migrating

The first step: an inventory. By setting up both the WP project and the new Drupal CMS one in DDEV, we made sure they could see each other. Looking at what was actually in the database:

• 717 published posts (and 5 drafts), 2013 to 2022.
• 4,110 attachments. 3,741 of them JPEGs.
• 545 approved comments, 104 pingbacks, and 1,190 spam comments that stayed behind.
• 13 categories and… 5,861 tags. For 717 posts. Yes.
• 3 users. Bylines lived in the post body as "Por NAME, @HANDLE".

Audit your content before the migration too, not only after. The database will surprise you.

In 2021 I said that upgrading your site is the best time for taking the trash out. Still true: the spam and 5,580 revisions stayed in WordPress.

The shape of it: Drupal CMS, recipes and a direct database source

The site is built on the Drupal CMS project template. Everything specific to CIBASS lives in project recipes: one per vocabulary, one per content type, one per media type, all bundled in a site template recipe. A fresh clone installs the whole site, in Spanish, with a single command. Then the migrations fill it.

For the source I didn't use the XML export of wordpress_migrate. wordpress_migrate_sql reads the WordPress database directly. With DDEV, the WordPress clone runs as its own project, and the Drupal one connects to its database container. 24 migrations, run in order by a script that stops at the first failure.

The development happened on a parallel branch of the same repository, and at cutover it was a plain git merge into master, plus running the migration live. The WordPress code is now only in git history. RIP.

The content model: let the data decide

WordPress had "posts". CIBASS had three different things pretending to be posts: critiques, interviews and articles. So the plan was to split them, and the first plan said "around 337 critiques".

The data said otherwise. A critique on CIBASS is a post with a rating, and the rating is… an image. A picture of a score at the end of the post. So the rule ended up being "a critique is a post with exactly one rating image". Posts with several ratings are compilations ("our 10 favorite movies of the year"), and those became articles flagged for editorial review.

The final numbers: 185 critiques, 22 interviews (plus 2 manual overrides) and 513 articles. Ratings are now a real field, and a custom field formatter outputs that same image.

Bylines became a contributor vocabulary. Parsing "Por NAME, @HANDLE" sounds easy until you find multiple authors, authors joined with " y ", and the same person written in 61 different ways. A small overrides table at migration time brought it down to 46.

Twelve rules to read a blog post

This is where most of the work went. Thirteen years of hand-written HTML, three generations of WordPress editors (classic, shortcodes, Gutenberg), and a lot of copy-paste from YouTube. While at it, we wanted to use the power of media in Drupal, so we needed to ensure we could unify all these different kinds of embeds from several different social networks this site has outlived (hey Vine!).

As an example, every critique body goes through a chain of twelve process plugins, in this order:

field_content: - plugin: wp_strip_byline_blocks - plugin: wp_rewrite_inline_formatting - plugin: wp_strip_rating_image - plugin: wp_rewrite_gallery_shortcodes - plugin: wp_rewrite_manual_galleries - plugin: wp_rewrite_caption_shortcodes - plugin: wp_rewrite_gutenberg_blocks - plugin: wp_rewrite_embed_shortcodes - plugin: cibass_image_override - plugin: wp_rewrite_img_urls - plugin: wp_relativize_links - plugin: wp_rewrite_search_to_tag

Each one does one thing. Remove the byline, because it's a field now. Remove the rating image, same reason. Turn [gallery ids="…"] (62 of them, 828 images) and the galleries people built by hand into gallery media. Turn 521 [caption] shortcodes into embedded media with captions. Turn [embed], bare URLs and raw iframes into the right remote media. Turn every <img src="…/uploads/…"> into a <drupal-media> token. Make links relative. And convert old ?s=query search links into tag pages.

Order matters. If the rating image isn't stripped (step 3) before images are converted (step 10), the rating image ends up as a media item in the body.

And then there's the rule that is not a rule: CIBASS editors use [sic], [mos] and [habla] as editorial brackets in Spanish. They look exactly like shortcodes. They are not. Leave them alone.

Write each transformation as its own small process plugin, with its own tests. You'll rerun the migration dozens of times, and you want to know which rule broke.

That's around 2,250 lines of process plugins and 186 test methods in the migration module. It sounds like a lot. It's the reason I could rerun everything without fear.

Media: eleven types for one blog

Those rules need somewhere to put things. The site ended up with eleven media types, and some of them deserve a story:

• Images (4,102): caption and description moved from the post to the media item, so they travel with the image.
• Remote video (344, YouTube and Vimeo): 73 of them were dead. Some got curated replacements; the rest went into an editorial backlog, created automatically during the migration, for human review.
• Gallery (65): a custom media source that holds a list of images. A gallery is a media type referencing other media types

A customer submits a web enquiry. Someone reads it, copies the details into the CRM and asks for missing information. When that happens every day, enquiry preparation is a useful place to test whether AI can save time. Choose one task with a clear finish line AI business process automation becomes easier to evaluate when the task has a defined start and end. For a web enquiry, it starts with submission and ends when the responsible person has checked the information and knows the next action. Our recommendation is to begin with a summary, a suggested category and a draft response. A person approves prices, delivery dates and commitments. This gives the team a bounded task whose time savings can actually be measured. The approach may suit a manufacturer receiving descriptive quotation…

Drupal is changing how developers organize some of the code behind your website. Here’s what the transition means for custom functionality, theme maintenance, and planning your next upgrade.

This is a cross-post of a blog by Nathaniel Catchpole, Senior Performance Engineer and Technical Lead at Tag1

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

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

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

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

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

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

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

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

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

Reducing Pipeline Wall Times

We reduced pipeline wall times via the following approaches.

Concurrent Test Running and Parallel CI Jobs

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

Slowest Tests Run First

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

Optimize or Split Up the Very Slowest Tests

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

Reducing CPU Time for Test Pipelines

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

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

Test Types

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

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

Installer Improvements for Functional Tests

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

Figure 4: Installing multiple modules in Drupal 11.2

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

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

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

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

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

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

Kernel Test Performance Improvements

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

Re-Evaluating On-Commit Pipelines

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

Reducing Wall Time for Contrib CI Runs

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

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

Effect on the Drupal Association's Hosting Costs

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

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

So, Where Have I Been?

Henadzi Koltun argues that Drupal’s value lies in durable engineering rather than short-term gains. He discusses when headless architecture is justified, why AI still needs human oversight and how accessibility becomes an organisational responsibility.

During the lifecycle of a Drupal site, content changes and the site evolves, requiring content maintenance. One of the issues that can happen is redirect chains. Why Drupal sites accumulate hundreds of redirect chains

A Drupal site with many years of life, one or more migrations, or frequent content changes accumulates redirects automatically. Every alias change and every moved page leaves one behind, until there are hundreds or even thousands of them. A new project gets there too once content starts to be created, redirects added, and URLs moved.

The problem is silent. Nobody decides to create a redirect chain; chains appear when redirects pile up on top of each other over time. Reviewing them manually is unfeasible because of the time it would take, so they stay. These situations usually surface in audits run with different tools: until that moment they go unnoticed.

Redirect chains and loops cost performance, SEO, and dead pages

A redirect chain is several hops in a row: a → b → c → d. Each additional hop increases navigation latency for users and makes crawling harder for search engines. Keeping every redirect at a single hop contributes to better SEO.

Googlebot follows up to 10 hops in a chain before giving up, but …

Pierre Rudloff, Joseph Zhao, Bram Driesen and Swan Kalata have moved from provisional to full membership of the Drupal Security Team. Their public records show experience in vulnerability reporting, fixes, advisory coordination, core contribution and community leadership.

Today we are talking about Drupalcon Rotterdam, Canvas and evaluating modules. We'll also cover Revision Graph as our module of the week.

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

Topics

• DrupalCon Rotterdam recap
• AI summits and training
• FrankenPHP app servers
• Driesnote highlights
• Advocacy and WordPress
• Rosetta Sprint and MCP
• Canvas multilingual and headless
• 3Frameworks And Voiceover
• Canvas And SDCs
• Headless And Signage
• Drupal 12 Beta Testing
• Rector And Deprecations
• PHP 8.5 Requirements
• Rethinking Module Evaluation
• AI And Commit Scale
• Module Discoverability
• 0Distributions Versus Recipes

Resources

• Wordpal
• Core metrics

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan Martin Anderson-Clutz - mandclu.com mandclu Tim Sharp - tea-sharp

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to see a node's revision history drawn like a Git graph, with each translation as its own branch? There's a module for that.
• Module name/project name:
  • Revision Graph
• Brief history
  • How old: created in Sep 2019 by Shibin Das (D34dMan) of Factorial
  • Versions available: 4.0.0, which works with Drupal 11 and 12, and 3.1.1 for Drupal 10 and 11
• Maintainership
  • Actively maintained, 4.0.0 landed in mid-August after two alphas the same week
  • Security coverage
  • Test coverage
  • Documentation: a solid README plus in-depth technical and revision-model docs in the repo
  • Number of open issues: zero open issues
• Usage stats:
  • 242 sites
• Module features and usage
  • With the module installed, every node gets a Revision Graph tab, right next to the core Revisions tab
  • One row per revision, one lane per language, so you can see when a translation branched off and how it's evolved since
  • Each dot tells you two things: a solid ring means that revision was live at some point, a dashed ring means it's a draft that never was, and a filled center means it's what that language is serving right now
  • It works with Content Moderation if you have it, showing your workflow states as text badges with whatever names your site uses, and adapts cleanly when you don't
  • Reverts, and edits made from the published version while a draft is pending, show up as forks instead of a straight line
  • Under the hood: Drupal doesn't actually store which revision a new one was derived from, so the module adds a small base field that records it at presave
  • Older revisions don't get backfilled, on purpose, since reconstructing that would mean guessing. Those edges are inferred, and the graph draws inferred edges differently from recorded ones, so it never implies more precision than it has
  • So on an existing site, make sure you run drush updb after enabling it
  • Ships a distinct color for all 95 language codes Drupal knows, so it looks good out of the box, but you can override a lane's color or the fallback palette in config
  • The graph loads in pages as you scroll, so long histories render quickly, and it's keyboard navigable, ARIA-labelled, and works in forced-colors mode
  • Great for editorial teams on multilingual sites, and handy for compliance or auditing when you need to answer "what was live, and when?"
  • Caveats: it's nodes only, and for obvious reasons a user will need the "view all revisions" permission to see the graph

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.

Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.

Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.

Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.

Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.

If you missed the keynote, you can watch the video below or download my slides (86 MB).

More ways to reach more people

The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.

Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.

React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.

At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.

This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.

Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.

With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.

What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.

Opening Drupal's capabilities to other software

The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.

In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.

If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.

That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.

Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.

But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.

That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.

I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.

The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.

And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:

Talk louder about Drupal

In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.

Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.

So I announced the Drupal Advocacy Program, led by the Drupal Association.

Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.

The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.

If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.

Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.

That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.

I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.

It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.

You can learn how to earn Drupal advocacy credit and submit your advocacy work.

My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.

I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.

Yet another amazing DrupalCon Europe has come to an end, leaving us with unforgettable memories. This time, we gathered in a city where futuristic architecture meets historic streets, home to Europe’s largest port and an absolutely unique food market. Rotterdam is a city that has embraced the future and innovation and is sailing towards it with all sails set.

Sponsorship for Mountain Camp 2027 Is Now Open sinduri Thu, 08.10.2026 - 16:46 Text

Sponsorship for Drupal Mountain Camp 2027 is now open. On March 2-4, 2027, the camp returns to Davos Congress for its sixth edition, ten years after the first gathering in 2017.

This year's theme is Humans with AI in the loop. Over three days of talks, hands-on workshops and contribution sprints, we look at how AI is changing the way we build software, why digital sovereignty matters, and where open source fits in.

The camp brings together people who care about the open web: developers, designers, AI practitioners, public-sector teams and open source communities from Switzerland and beyond.

Why Sponsor Mountain Camp

As a sponsor, you have a visible place at the camp and time to talk with the people who attend. Sponsoring lets you:

• Share your tools, services and expertise with people who build with open source and AI.
• Meet developers and technical leads in person, over three days.
• Connect with attendees between sessions and at the social events.
• Support an independent, community-run event that has brought people together since 2017.

We welcome sponsors of any size and from any field who want to support an open, independent web.

Sponsorship Packages

There are four packages: Platinum, Gold, Silver and Bronze. Places are limited, with 3 Platinum, 5 Gold and 8 Silver packages available.

Depending on the package, benefits include:

• Introducing a keynote speaker on stage
• A promotional video at the opening and closing ceremony
• An exhibition stand
• Job listings on the website and at the venue

Every package includes conference tickets and a logo on our sponsor page.

If you would like to support a specific part of the camp, you can also sponsor the opening reception, a social event, the session recordings, the coffee breaks or a diversity scholarship.

Become a Sponsor

You can find all packages and what they include on our sponsorship page.

To become a sponsor or ask a question, write to us at info@drupalmountaincamp.ch.

To stay up to date, subscribe to our newsletter and follow us on Mastodon, Instagram, Bluesky and LinkedIn.

We look forward to hearing from you.

My DrupalCon Rotterdam talk moved from MCP to the CLI. How Canvas Tools and agent skills let a coding agent build Canvas pages through Drush, and what's still rough.

Google has updated its guidance to emphasize human review of AI-generated content. Here’s what changed, what it means for SEO, and what website owners should check before publishing.

Vibe coding or AI rejection? Learn the pragmatic middle path for Drupal teams: what to delegate to AI, when, and how to verify it.

Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.

Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.

Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.

Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.

Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.

If you missed the keynote, you can watch the video below or download my slides (86 MB).

More ways to reach more people

The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.

Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.

React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.

At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.

This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.

Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.

With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.

What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.

Opening Drupal's capabilities to other software

The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.

In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.

If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.

That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.

Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.

But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.

That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.

I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.

The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.

And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:

Talk louder about Drupal

In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.

Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.

So I announced the Drupal Advocacy Program, led by the Drupal Association.

Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.

The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.

If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.

Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.

That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.

I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.

It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.

You can learn how to earn Drupal advocacy credit and submit your advocacy work.

My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.

I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.

Drupal AI can keep control of providers and model settings while Neuron handles agents and workflows. The new bridge also brings Neuron objects into Drupal's plugin system.

One node, many translations: how Drupal's translation model works, why Drupal 7 migrations break it, and the configuration that has to be right afterwards.