At the end of November I had the privilege of going to the first ever Oaisys AI Practitioners conference in Pune, India. I wanted to share some of the memories and moments from that event.

Jamie Abrahams and I were invited to both hold sessions and lead the contribution day. It was my first time in India and since the event itself was new as well, it was hard to know what to expect. But whatever my expectations could have been, it would have surpassed it.

We arrived two days early to get over jetlag and also meet some people before the event. On the first evening when we arrived we went to dinner with Dipen Chaudhary, CEO and Piyuesh Kumar, Director of technology, both from QED42. QED42 were the main organisers of the event and had done a fantastic job putting it all together. It was great to meet them a bit before the event started and let me tell you - Indian food in Germany is not the same thing as Indian food in India. It was absolutely delicious.

The next day we met up with Pritam Prasun, founder of OpenSense Labs and CEO of RAIL. We discussed a lot about the Drupal ecosystem, about Indian culture vs western culture, but also about the RAIL project and how it can be integrated with the AI module to make the ecosystem more secure.

We also got to visit the offices of QED42 which was a great experience. The team there was super friendly and it was nice to see some faces that you had seen on video calls or Slack channels in real life.

The conference itself started on the 29th of November in the ICC Trade Tower in Pune. When I walked in the first day, I was greeted right away by people I knew from the Drupal community, but also people that had worked with the AI module or were interested in AI in general. It was a great feeling to be surrounded by so many like-minded people.

It was a great feeling to be surrounded by so many like-minded people.

Because of managing the contribution room, I only attended two sessions during the conference - Jamie's introductory session, which was always great and very well received and the end session by Piyush about How LLMs learn, which I learned myself from as well.

Meeting prominent contributors to the Drupal AI ecosystem

The highlight of the conference was to meet some of the most prominent contributors to the AI ecosystem. Specifically Prabhavathi Vanipenta and Anjali Prasannan that both have been doing amazing work on the AI module, and Akhil Babu, who has been working on the agents system in Drupal, and built many of the agents you see in Canvas. It was truly a blessing to meet them in person and thank them for all their contributions.

Prashant Chauhan, wasn't there in person, but Prabha and Anjali made sure that I got to thank him over a video call. The four of them have worked and finished over 200 issues on the AI module, which is just mind-blowing.

Well thought through ideas of how AI can be used to improve their workflows, businesses and lives

Another thing that was mind-blowing was the level of interest, energy and enthusiasm around AI in general in the contribution room. People were building the craziest things and had really thought through what and how AI can be used to improve their workflows, businesses and lives. It was inspiring to see so many people passionate about the same thing as you. I have never seen anything like it before, in the events I have attended.

Another thing that was mind-blowing was the level of interest, energy and enthusiasm around AI in general in the contribution room

The Browser AI CKEditor for instance is a project that was thought through and built during the contribution day.

A lot of discussion led directly to new issues in the Drupal AI module issue queue, that some of the people attending are working on now.

Because of family commitments I couldn't stay longer than four days, but those four days were really great. I want to thank Dipen, Piyuesh and the whole QED42 team for organising such a fantastic event and being such great hosts. A special thanks as well to Priyanka Jeph, who organized a lot of the event.

At the end of November I had the privilege of going to the first ever Oaisys AI Practitioners conference in Pune, India. I wanted to share some of the memories and moments from that event.

Jamie Abrahams and I were invited to both hold sessions and lead the contribution day. It was my first time in India and since the event itself was new as well, it was hard to know what to expect. But whatever my expectations could have been, it would have surpassed it.

We arrived two days early to get over jetlag and also meet some people before the event. On the first evening when we arrived we went to dinner with Dipen Chaudhary, CEO and Piyuesh Kumar, Director of technology, both from QED42. QED42 were the main organisers of the event and had done a fantastic job putting it all together. It was great to meet them a bit before the event started and let me tell you - Indian food in Germany is not the same thing as Indian food in India. It was absolutely delicious.

The next day we met up with Pritam Prasun, founder of OpenSense Labs and CEO of RAIL. We discussed a lot about the Drupal ecosystem, about Indian culture vs western culture, but also about the RAIL project and how it can be integrated with the AI module to make the ecosystem more secure.

We also got to visit the offices of QED42 which was a great experience. The team there was super friendly and it was nice to see some faces that you had seen on video calls or Slack channels in real life.

The conference itself started on the 29th of November in the ICC Trade Tower in Pune. When I walked in the first day, I was greeted right away by people I knew from the Drupal community, but also people that had worked with the AI module or were interested in AI in general. It was a great feeling to be surrounded by so many like-minded people.

It was a great feeling to be surrounded by so many like-minded people.

Because of managing the contribution room, I only attended two sessions during the conference - Jamie's introductory session, which was always great and very well received and the end session by Piyush about How LLMs learn, which I learned myself from as well.

Meeting prominent contributors to the Drupal AI ecosystem

The highlight of the conference was to meet some of the most prominent contributors to the AI ecosystem. Specifically Prabhavathi Vanipenta and Anjali Prasannan that both have been doing amazing work on the AI module, and Akhil Babu, who has been working on the agents system in Drupal, and built many of the agents you see in Canvas. It was truly a blessing to meet them in person and thank them for all their contributions.

Prashant Chauhan, wasn't there in person, but Prabha and Anjali made sure that I got to thank him over a video call. The four of them have worked and finished over 200 issues on the AI module, which is just mind-blowing.

Well thought through ideas of how AI can be used to improve their workflows, businesses and lives

Another thing that was mind-blowing was the level of interest, energy and enthusiasm around AI in general in the contribution room. People were building the craziest things and had really thought through what and how AI can be used to improve their workflows, businesses and lives. It was inspiring to see so many people passionate about the same thing as you. I have never seen anything like it before, in the events I have attended.

Another thing that was mind-blowing was the level of interest, energy and enthusiasm around AI in general in the contribution room

The Browser AI CKEditor for instance is a project that was thought through and built during the contribution day.

A lot of discussion led directly to new issues in the Drupal AI module issue queue, that some of the people attending are working on now.

Because of family commitments I couldn't stay longer than four days, but those four days were really great. I want to thank Dipen, Piyuesh and the whole QED42 team for organising such a fantastic event and being such great hosts. A special thanks as well to Priyanka Jeph, who organized a lot of the event.

The third feature release of Drupal 11 is here with the biggest performance boost in a decade. Serve 26-33% more requests with the same database load. New native HTMX support enables rich UX with up to 71% less JavaScript. Plus, enjoy the new stable Navigation module, improved CKEditor content editing, native content export, and cleaner OOP hooks for themes.

New in Drupal 11.3

Biggest performance boost in a decade

Database query and cache operations on both cold and warm caches have been significantly reduced. Our automated tests show that the new optimization for cold caches is about one third and on partially-warm cache requests by up to one fourth. Independent testing shows even bigger improvements on complex sites.

The render and caching layers now combine database and cache operations, notably in path alias and entity loading. BigPipe also now uses HTMX on the frontend, leading to a significant reduction in JavaScript weight.

Read more about performance improvements in Drupal 11.3.0.

Native HTMX: Rich UX with up to 71% less JavaScript

Drupal 11.3.0 now natively integrates HTMX, a powerful, dependency-free JavaScript library. HTMX dramatically enhances how developers build fast, interactive user interfaces. It enables modern browser features directly in HTML attributes, significantly reducing the need for extensive custom JavaScript.

Read more about HTMX support in Drupal 11.3.0.

Navigation module is now stable

The Navigation module is now stable, offering a superior and more modern experience than the old Toolbar. While it is an experience worth installing on all sites, it is most useful for sites with complex administration structures. While not yet the default, we strongly encourage users to switch and benefit from its improvements.

Improved content editing

CKEditor now natively supports linking content on the site by selecting it from an autocomplete or dropdown (using entity references).. CKEditor also has new, user-friendly options for formatting list bullets and numbering.. Finally, a dedicated Administer node published status permission is introduced to manage publication status of content (which does not require Administer nodes anymore).

Object-oriented hooks in themes

Themes can now use the same #[Hook()] attribute system as modules, with theme namespaces registered in the container for easier integration. This change allows themers to write cleaner, more structured code. Themes' OOP hook implementations are placed in the src/Hook/ directory, similarly to modules'. Themes support a defined subset of both normal and alter hooks.

Native support for content export

Drupal core now includes a command-line tool to export content in the format previously introduced by the contributed Default Content module. Drupal can export a single entity at a time, but it is also possible to export the dependencies of the entity automatically (for example, images or taxonomy terms it references).To use the export tool, run the following from the Drupal site's root:

php core/scripts/drupal content:export ENTITY_TYPE_ID ENTITY_ID

PHP 8.5 support

PHP 8.5 itself was released last month. Drupal 11.3.0 not only ensures full compatibility and support for PHP 8.5, but made core testing also run on it. PHP 8.5 is expected to become the minimum required version for Drupal 12, planned to be released in 2026. 

New experimental database driver for MySQL/MariaDB for parallel queries

A new, experimental MySQLi database driver has been added for MySQL and MariaDB. It is not yet fully supported and is hidden from the user interface.

While the current default drivers use PDO to connect to MySQL or MariaDB, this new database driver instead uses the mysqli PHP extension. MySQLi is more modern and allows database queries to be run in parallel instead of sequentially as with PDO. We plan to add asynchronous database query support in a future Drupal release.

Core maintainer team updates

Since Drupal 11.2, we reached out to all subsystem and topic maintainers to confirm whether they wished to continue in their roles. Several long-term contributors stepped back and opened up roles for new contributors. We would like to thank them for their contributions.

Additionally, Roy Scholten stepped back from his Usability maintainership and Drupal core product manager role. He has been inactive for a while, but his impact on Drupal since 2007 has been profound. We thank him for his involvement!

Mohit Aghera joined as a maintainer for the File subsystem. Shawn Duncan is a new maintainer for the Ajax subsystem. David Cameron was added as a maintainer of the Link Field module. Pierre Dureau and Florent Torregrosa are now the maintainers for the Asset Library API. Finally, codebymikey is the new maintainer for Basic Auth.

Going forward, we plan to review core maintainer appointments annually. We hope this will reduce the burden on maintainers when transitioning between roles or stepping down, and also provide more opportunities for new contributors.

Want to get involved?

If you are looking to make the leap from Drupal user to Drupal contributor, or you want to share resources with your team as part of their professional development, there are many opportunities to deepen your Drupal skill set and give back to the community. Check out the Drupal contributor guide.

You would be more than welcome to join us at DrupalCon Chicago in March 2026 to attend sessions, network, and enjoy mentorship for your first contributions.

The Core Leadership Team is always looking for new contributors to help steward the project. As recently various new opportunities have opened up. If you are looking to deepen your Drupal skill set, we encourage you to read more about the open subsystem and topic maintainer roles and consider stepping up to contribute your expertise.

Drupal 10.6 is also available

The next maintenance minor release of Drupal 10 has also been released, and will be supported until December 9, 2026, after the release of Drupal 12. Long-term support for Drupal 10 gives more flexibility for sites to move to Drupal 11 when they are ready while staying up-to-date with Drupal's dependencies.

This release schedule also allows sites to move from one long-term support version to the next if that is the best strategy for their needs. For more information on maintenance minors, read the previous post on the new major release schedule.

The third feature release of Drupal 11 is here with the biggest performance boost in a decade. Serve 26-33% more requests with the same database load. New native HTMX support enables rich UX with up to 71% less JavaScript. Plus, enjoy the new stable Navigation module, improved CKEditor content editing, native content export, and cleaner OOP hooks for themes.

New in Drupal 11.3

Biggest performance boost in a decade

Database query and cache operations on both cold and warm caches have been significantly reduced. Our automated tests show that the new optimization for cold caches is about one third and on partially-warm cache requests by up to one fourth. Independent testing shows even bigger improvements on complex sites.

The render and caching layers now combine database and cache operations, notably in path alias and entity loading. BigPipe also now uses HTMX on the frontend, leading to a significant reduction in JavaScript weight.

Read more about performance improvements in Drupal 11.3.0.

Native HTMX: Rich UX with up to 71% less JavaScript

Drupal 11.3.0 now natively integrates HTMX, a powerful, dependency-free JavaScript library. HTMX dramatically enhances how developers build fast, interactive user interfaces. It enables modern browser features directly in HTML attributes, significantly reducing the need for extensive custom JavaScript.

Read more about HTMX support in Drupal 11.3.0.

Navigation module is now stable

The Navigation module is now stable, offering a superior and more modern experience than the old Toolbar. While it is an experience worth installing on all sites, it is most useful for sites with complex administration structures. While not yet the default, we strongly encourage users to switch and benefit from its improvements.

Improved content editing

CKEditor now natively supports linking content on the site by selecting it from an autocomplete or dropdown (using entity references).. CKEditor also has new, user-friendly options for formatting list bullets and numbering.. Finally, a dedicated Administer node published status permission is introduced to manage publication status of content (which does not require Administer nodes anymore).

Object-oriented hooks in themes

Themes can now use the same #[Hook()] attribute system as modules, with theme namespaces registered in the container for easier integration. This change allows themers to write cleaner, more structured code. Themes' OOP hook implementations are placed in the src/Hook/ directory, similarly to modules'. Themes support a defined subset of both normal and alter hooks.

Native support for content export

Drupal core now includes a command-line tool to export content in the format previously introduced by the contributed Default Content module. Drupal can export a single entity at a time, but it is also possible to export the dependencies of the entity automatically (for example, images or taxonomy terms it references).To use the export tool, run the following from the Drupal site's root:

php core/scripts/drupal content:export ENTITY_TYPE_ID ENTITY_ID

New experimental database driver for MySQL/MariaDB for parallel queries

A new, experimental MySQLi database driver has been added for MySQL and MariaDB. It is not yet fully supported and is hidden from the user interface.

While the current default drivers use PDO to connect to MySQL or MariaDB, this new database driver instead uses the mysqli PHP extension. MySQLi is more modern and allows database queries to be run in parallel instead of sequentially as with PDO. We plan to add asynchronous database query support in a future Drupal release.

Core maintainer team updates

Since Drupal 11.2, we reached out to all subsystem and topic maintainers to confirm whether they wished to continue in their roles. Several long-term contributors stepped back and opened up roles for new contributors. We would like to thank them for their contributions.

Additionally, Roy Scholten stepped back from his Usability maintainership and Drupal core product manager role. He has been inactive for a while, but his impact on Drupal since 2007 has been profound. We thank him for his involvement!

Mohit Aghera joined as a maintainer for the File subsystem. Shawn Duncan is a new maintainer for the Ajax subsystem. David Cameron was added as a maintainer of the Link Field module. Pierre Dureau and Florent Torregrosa are now the maintainers for the Asset Library API. Finally, codebymikey is the new maintainer for Basic Auth.

Going forward, we plan to review core maintainer appointments annually. We hope this will reduce the burden on maintainers when transitioning between roles or stepping down, and also provide more opportunities for new contributors.

Want to get involved?

If you are looking to make the leap from Drupal user to Drupal contributor, or you want to share resources with your team as part of their professional development, there are many opportunities to deepen your Drupal skill set and give back to the community. Check out the Drupal contributor guide.

You would be more than welcome to join us at DrupalCon Chicago in March 2026 to attend sessions, network, and enjoy mentorship for your first contributions.

The Core Leadership Team is always looking for new contributors to help steward the project. As recently various new opportunities have opened up. If you are looking to deepen your Drupal skill set, we encourage you to read more about the open subsystem and topic maintainer roles and consider stepping up to contribute your expertise.

Drupal 10.6 is also available

The next maintenance minor release of Drupal 10 has also been released, and will be supported until December 9, 2026, after the release of Drupal 12. Long-term support for Drupal 10 gives more flexibility for sites to move to Drupal 11 when they are ready while staying up-to-date with Drupal's dependencies.

This release schedule also allows sites to move from one long-term support version to the next if that is the best strategy for their needs. For more information on maintenance minors, read the previous post on the new major release schedule.

Drupal 11.3 includes a number of significant performance improvements, altogether making it the most significant step forward for Drupal performance in the last 10 years (since the Drupal 8.0.0 release).

These improvements have been driven by enhancements to Drupal's render and caching layers in 11.2.x, notably taking advantage of Fibers, a new PHP feature added in PHP 8.1. By rendering more parts of the page in placeholders, we have enabled similar database and cache operations that used to occur individually to be combined, with particular improvements in path alias and entity loading. We have also learned from Drupal's automated performance testing framework, allowing us to identify and execute several optimizations during Drupal's hook and field discovery processes, to significantly reduce database and cache i/o, and memory usage on cold caches.

On the front end we have converted Drupal's BigPipe implementation to use HTMX, reducing JavaScript weight significantly. We also intercept placeholders with warm render caches prior to BigPipe replacement, so that BigPipe's JavaScript is not loaded at all on requests that will be served quickly without it, allowing BigPipe to be used more widely for the requests that do need it. These changes may also allow us to enable BigPipe for anonymous site visitors in a future release.

Combined, these changes reduce database query and cache operations on cold cache requests by around one third, with smaller but still significant improvements when caches become warmer, up to and including dynamic and internal page cache hits.

Drupal's automated performance tests show many of these improvements, and will ensure that we continue to build and maintain on these gains over time.

Drupal Umami demo’s anonymous cold cache front page request

Let's look at an example. These are the changes in Drupal core's included Umami demo's anonymous cold cache front page request performance test between 11.2.x and 11.3.x.

Particularly notable is the benefit for requests to pages with partially warmed caches, where site-wide caches are full, but page-specific caches are invalid or empty. In core's performance test for this scenario, we saw an almost 50% reduction in database queries. Requests like this make up a large percentage of the slowest responses from real Drupal sites, and core now provides a much lower baseline to work against. Medium to large sites often hit constraints with the database first, because it is harder to scale than simply adding webservers, and these improvements reduce load when it is at its most constrained.

Drupal Umami demo’s anonymous node page with partially-warmed cache

While different sites, and even different pages on the same site, will show different results, we would expect all Drupal sites to see a significant reduction in database and cache i/o per request once they've updated to Drupal 11.3.

Independent testing and further improvements with Paragraphs

Independent testing by MD Systems on their internal Primer Drupal distribution shows even better improvements with Drupal 11.3, especially for complex pages. This is also thanks to further improvements enabled and inspired by Drupal 11.3 in the Entity Reference Revisions module which resulted in considerable performance improvements for Paragraphs. Their results show a dramatic reduction in database and cache operations across different cache states. Their cold cache total query count dropped by 62% (from 1097 to 420), and total cache lookups decreased by 47% (from 991 to 522) compared to Drupal 11.2. At the same time their partially-warm cache total query count dropped by 61% (from 696 to 274) and total cache lookups decreased by 34% (from 562 to 373).

Even more technical details

For further details on how these improvements happened, check out some of the core issues that introduced them, or watch Nathaniel Catchpole's DrupalCon Vienna presentation.

#1237636: Lazy load multiple entities at a time using fibers
#2620980: Add static and persistent caching to ContentEntityStorageBase::loadRevision()
#3496369: Multiple load path aliases without the preload cache
#3537863: Optimize field module's hook_entity_bundle_info() implementation
#3538006: Optimize EntityFieldManager::buildBundleFieldDefinitions()
#3526080: Reduce write contention to the fast and consistent backend in ChainedFastBackend
#3493911: Add a CachedPlaceholderStrategy to optimize render cache hits and reduce layout shift from big pipe
#3526267: Remove core/drupal.ajax dependency from big_pipe/big_pipe
#3506930: Separate hooks from events
#3505248: Ability to preload frequently used cache tags (11.2.x)

There is more to do for Drupal 11.4!

If you'd like to help 11.4 become even faster yet, check out core issues tagged with 'performance' and try to help us get them done. We have multiple issues in progress that didn't quite make it into 11.3.0 but could form the basis of another significant set of improvements in 11.4.0.

Drupal 11.3 includes a number of significant performance improvements, altogether making it the most significant step forward for Drupal performance in the last 10 years (since the Drupal 8.0.0 release).

These improvements have been driven by enhancements to Drupal's render and caching layers in 11.2.x, notably taking advantage of Fibers, a new PHP feature added in PHP 8.1. By rendering more parts of the page in placeholders, we have enabled similar database and cache operations that used to occur individually to be combined, with particular improvements in path alias and entity loading. We have also learned from Drupal's automated performance testing framework, allowing us to identify and execute several optimizations during Drupal's hook and field discovery processes, to significantly reduce database and cache i/o, and memory usage on cold caches.

On the front end we have converted Drupal's BigPipe implementation to use HTMX, reducing JavaScript weight significantly. We also intercept placeholders with warm render caches prior to BigPipe replacement, so that BigPipe's JavaScript is not loaded at all on requests that will be served quickly without it, allowing BigPipe to be used more widely for the requests that do need it. These changes may also allow us to enable BigPipe for anonymous site visitors in a future release.

Combined, these changes reduce database query and cache operations on cold cache requests by around one third, with smaller but still significant improvements when caches become warmer, up to and including dynamic and internal page cache hits.

Drupal's automated performance tests show many of these improvements, and will ensure that we continue to build and maintain on these gains over time.

Drupal Umami demo’s anonymous cold cache front page request

Let's look at an example. These are the changes in Drupal core's included Umami demo's anonymous cold cache front page request performance test between 11.2.x and 11.3.x.

Particularly notable is the benefit for requests to pages with partially warmed caches, where site-wide caches are full, but page-specific caches are invalid or empty. In core's performance test for this scenario, we saw an almost 50% reduction in database queries. Requests like this make up a large percentage of the slowest responses from real Drupal sites, and core now provides a much lower baseline to work against. Medium to large sites often hit constraints with the database first, because it is harder to scale than simply adding webservers, and these improvements reduce load when it is at its most constrained.

Drupal Umami demo’s anonymous node page with partially-warmed cache

While different sites, and even different pages on the same site, will show different results, we would expect all Drupal sites to see a significant reduction in database and cache i/o per request once they've updated to Drupal 11.3.

Independent testing and further improvements with Paragraphs

Independent testing by MD Systems on their internal Primer Drupal distribution shows even better improvements with Drupal 11.3, especially for complex pages. This is also thanks to further improvements enabled and inspired by Drupal 11.3 in the Entity Reference Revisions module which resulted in considerable performance improvements for Paragraphs. Their results show a dramatic reduction in database and cache operations across different cache states. Their cold cache total query count dropped by 62% (from 1097 to 420), and total cache lookups decreased by 47% (from 991 to 522) compared to Drupal 11.2. At the same time their partially-warm cache total query count dropped by 61% (from 696 to 274) and total cache lookups decreased by 34% (from 562 to 373).

Even more technical details

For further details on how these improvements happened, check out some of the core issues that introduced them, or watch Nathaniel Catchpole's DrupalCon Vienna presentation.

#1237636: Lazy load multiple entities at a time using fibers
#2620980: Add static and persistent caching to ContentEntityStorageBase::loadRevision()
#3496369: Multiple load path aliases without the preload cache
#3537863: Optimize field module's hook_entity_bundle_info() implementation
#3538006: Optimize EntityFieldManager::buildBundleFieldDefinitions()
#3526080: Reduce write contention to the fast and consistent backend in ChainedFastBackend
#3493911: Add a CachedPlaceholderStrategy to optimize render cache hits and reduce layout shift from big pipe
#3526267: Remove core/drupal.ajax dependency from big_pipe/big_pipe
#3506930: Separate hooks from events
#3505248: Ability to preload frequently used cache tags (11.2.x)

There is more to do for Drupal 11.4!

If you'd like to help 11.4 become even faster yet, check out core issues tagged with 'performance' and try to help us get them done. We have multiple issues in progress that didn't quite make it into 11.3.0 but could form the basis of another significant set of improvements in 11.4.0.

Drupal developers always face the dilemma of building classic multi-page applications or headless solutions with a modern JavaScript stack. Especially when they need to build UIs that feel fast and are highly reactive. While there were some Drupal specific solutions for parts of this need (Form State API, AJAX API and BigPipe), these were dated, only solving very specific use cases and comparatively heavy in implementation.

HTMX is a tiny, dependency-free, and extensible JavaScript library that allows you to access modern browser features directly from HTML, rather than using extensive amounts of JavaScript. It essentially enables you to use HTML to make AJAX requests, CSS transitions, WebSockets, and Server-Sent Events (SSE) directly.

As a replacement for Drupal's mostly home grown solutions, this reduced the loaded JavaScript size by up to 71% for browser-server interactions, including HTML streaming with BigPipe. While enabling a whole set of new functionality at the same time!

HTMX was originally created by Carson Gross. The motivation was to provide a modern, yet simple, way to build dynamic user interfaces by leveraging the existing capabilities of HTML and the server-side architecture, effectively offering an alternative to the complexity of heavy, client-side JavaScript frameworks. By sending less data (HTML fragments instead of large JSON payloads and complex client-side rendering logic), HTMX often results in faster perceived performance and less bandwidth consumption. It is being adopted by developers across diverse ecosystems.

Principles of HTMX

HTMX operates on a few core, simple principles, all expressed via HTML attributes. While pure HTMX does not require the data- prefix, Drupal uses it to achieve valid HTML. That is how you'll see it used in Drupal, so we'll use that notation in this post.

1. Any Element Can Make a Request: Unlike standard HTML forms and anchors, HTMX allows any element (a <div>, a <span>, a <button>) to trigger an HTTP request. All five HTTP verbs are available.
   • Attributes: data-hx-get, data-hx-post, data-hx-put, data-hx-delete, data-hx-patch.
2. Any Event Can Trigger a Request: You are not limited to click (for anchors/buttons) or submit (for forms). Requests can be triggered by any JavaScript event, such as mouseover, keyup, or a custom event.
   • Attribute: data-hx-trigger.
3. Any Target Can Be Updated: By default, HTMX replaces the inner HTML of the element that triggered the request. However, you can use a CSS selector to specify any element on the page to be updated with the response HTML.
   • Attribute: data-hx-target.
4. Any Transition Can Be Used: HTMX allows you to define how the new content is swapped into the target element (e.g., replace, prepend, append, outerHTML) and works with the new View Transition API.
   • Attribute: data-hx-swap.

Short Code Example

This Drupal-independent example demonstrates how to fetch and swap new content into a div when a button is clicked, without writing any custom JavaScript.

<!-- The button that triggers the request -->
<button data-hx-get="/clicked" 
        data-hx-target="#content-area" 
        data-hx-swap="outerHTML">
  Load New Content
</button>

<!-- The area that will be updated -->
<div id="content-area">
  This content will be replaced.
</div>

In this code example, when the button is clicked:

1. A GET request is made to the server at the URL: /clicked
2. The server responds with a fragment of HTML (e.g., <div>New Content Loaded!</div>)
3. The HTML content of the #content-area element is replaced (outerHTML) by the response.

Introducing HTMX in Drupal 11.3.0

HTMX was added as a dependency to Drupal core in 11.2, but is now fully featured in 11.3. A new factory class is provided for developers building or extending render arrays. The Htmx class provides methods that build every HTMX attribute or response header, therefore documenting and exposing the HTMX API to Drupal.

Drupal 11.3 also extends the FormBuilder class to support dynamic forms built with HTMX. When a form is rebuilt from an HTMX request, all the form values will be available to the form class for dynamically restructuring the form. Here’s an example of both features:

function buildForm(array $form, FormStateInterface $form_state) {
  $make = ['Audi', 'Toyota', 'BMW'];
  $models = [
    ['A1', 'A4', 'A6'],
    ['Landcruiser', 'Tacoma', 'Yaris'],
    ['325i', '325ix', 'X5'],
  ];
  $form['make'] = [
    '#title' => 'Make',
    '#type' => 'select',
    '#options' => $make,
  ];
  $form['model'] = [
    '#title' => 'Models',
    '#type' => 'select',
    '#options' => $models[$form_state->getValue('make', 0)] ?? [],
    // We'll need that later.
    '#wrapper_attributes' => ['id' => 'models-wrapper'],
  ];
  return $form;
}

(new Htmx())
  // An empty method call uses the current URL.
  ->post()
  // We select the wrapper around the select.
  ->target('#models-wrapper')
  // And replace the whole wrapper
  // not simply updating the options in place,
  // so that any errors also display.
  ->select('#models-wrapper')
  // We replace the whole element for this form.
  ->swap('outerHTML')
  ->applyTo($form['make']);

In this form, whenever the make selector is changed, the models selector will be updated.

Drupal 11.3 also adds a dedicated renderer and associated wrapper format that can be used to keep the response to an HTMX request as small as possible. This render only returns the main content and its CSS/Javascript assets. There are two ways to take advantage of this renderer.

One is to add an attribute to the HTMX enhanced element, which will cause the wrapper format to be used:

(new Htmx())
  ->post()
  ->onlyMainContent()
  ->target('#models-wrapper')
  ->select('#models-wrapper')
  ->swap('outerHTML')
  ->applyTo($form['make']);

There is also a new route option that can be used when creating a route specifically to service HTMX requests. This route option will also be useful with the dynamic routes in Views as we refactor to use HTMX.

demo.route_option:
  path: '/htmx-demo/route-option'
  defaults:
    _title: 'Using _htmx_route option'
    _controller: '\Drupal\module_name\Controller\DemoController::replace'
  requirements:
    _permission: 'access content'
  options:
    _htmx_route: TRUE

Drupal is still committed to supporting decoupled architectures

HTMX is an excellent solution for progressive enhancement and dynamic front-ends. It is a powerful tool in the core toolkit, not a replacement for the flexibility offered by a fully decoupled backend. Drupal remains committed to supporting decoupled and headless architectures, especially where necessary, such as mobile applications, client-side state management, deep offline capabilities, etc.

Drupal developers always face the dilemma of building classic multi-page applications or headless solutions with a modern JavaScript stack. Especially when they need to build UIs that feel fast and are highly reactive. While there were some Drupal specific solutions for parts of this need (Form State API, AJAX API and BigPipe), these were dated, only solving very specific use cases and comparatively heavy in implementation.

HTMX is a tiny, dependency-free, and extensible JavaScript library that allows you to access modern browser features directly from HTML, rather than using extensive amounts of JavaScript. It essentially enables you to use HTML to make AJAX requests, CSS transitions, WebSockets, and Server-Sent Events (SSE) directly.

As a replacement for Drupal's mostly home grown solutions, this reduced the loaded JavaScript size by up to 71% for browser-server interactions, including HTML streaming with BigPipe. While enabling a whole set of new functionality at the same time!

HTMX was originally created by Carson Gross. The motivation was to provide a modern, yet simple, way to build dynamic user interfaces by leveraging the existing capabilities of HTML and the server-side architecture, effectively offering an alternative to the complexity of heavy, client-side JavaScript frameworks. By sending less data (HTML fragments instead of large JSON payloads and complex client-side rendering logic), HTMX often results in faster perceived performance and less bandwidth consumption. It is being adopted by developers across diverse ecosystems.

Principles of HTMX

HTMX operates on a few core, simple principles, all expressed via HTML attributes. While pure HTMX does not require the data- prefix, Drupal uses it to achieve valid HTML. That is how you'll see it used in Drupal, so we'll use that notation in this post.

1. Any Element Can Make a Request: Unlike standard HTML forms and anchors, HTMX allows any element (a <div>, a <span>, a <button>) to trigger an HTTP request. All five HTTP verbs are available.
   • Attributes: data-hx-get, data-hx-post, data-hx-put, data-hx-delete, data-hx-patch.
2. Any Event Can Trigger a Request: You are not limited to click (for anchors/buttons) or submit (for forms). Requests can be triggered by any JavaScript event, such as mouseover, keyup, or a custom event.
   • Attribute: data-hx-trigger.
3. Any Target Can Be Updated: By default, HTMX replaces the inner HTML of the element that triggered the request. However, you can use a CSS selector to specify any element on the page to be updated with the response HTML.
   • Attribute: data-hx-target.
4. Any Transition Can Be Used: HTMX allows you to define how the new content is swapped into the target element (e.g., replace, prepend, append, outerHTML) and works with the new View Transition API.
   • Attribute: data-hx-swap.

Short Code Example

This Drupal-independent example demonstrates how to fetch and swap new content into a div when a button is clicked, without writing any custom JavaScript.

<!-- The button that triggers the request -->
<button data-hx-get="/clicked" 
        data-hx-target="#content-area" 
        data-hx-swap="outerHTML">
  Load New Content
</button>

<!-- The area that will be updated -->
<div id="content-area">
  This content will be replaced.
</div>

In this code example, when the button is clicked:

1. A GET request is made to the server at the URL: /clicked
2. The server responds with a fragment of HTML (e.g., <div>New Content Loaded!</div>)
3. The HTML content of the #content-area element is replaced (outerHTML) by the response.

Introducing HTMX in Drupal 11.3.0

HTMX was added as a dependency to Drupal core in 11.2, but is now fully featured in 11.3. A new factory class is provided for developers building or extending render arrays. The Htmx class provides methods that build every HTMX attribute or response header, therefore documenting and exposing the HTMX API to Drupal.

Drupal 11.3 also extends the FormBuilder class to support dynamic forms built with HTMX. When a form is rebuilt from an HTMX request, all the form values will be available to the form class for dynamically restructuring the form. Here’s an example of both features:

function buildForm(array $form, FormStateInterface $form_state) {
  $make = ['Audi', 'Toyota', 'BMW'];
  $models = [
    ['A1', 'A4', 'A6'],
    ['Landcruiser', 'Tacoma', 'Yaris'],
    ['325i', '325ix', 'X5'],
  ];
  $form['make'] = [
    '#title' => 'Make',
    '#type' => 'select',
    '#options' => $make,
  ];
  $form['model'] = [
    '#title' => 'Models',
    '#type' => 'select',
    '#options' => $models[$form_state->getValue('make', 0)] ?? [],
    // We'll need that later.
    '#wrapper_attributes' => ['id' => 'models-wrapper'],
  ];
  return $form;
}

(new Htmx())
  // An empty method call uses the current URL.
  ->post()
  // We select the wrapper around the select.
  ->target('#models-wrapper')
  // And replace the whole wrapper
  // not simply updating the options in place,
  // so that any errors also display.
  ->select('#models-wrapper')
  // We replace the whole element for this form.
  ->swap('outerHTML')
  ->applyTo($form['make']);

In this form, whenever the make selector is changed, the models selector will be updated.

Drupal 11.3 also adds a dedicated renderer and associated wrapper format that can be used to keep the response to an HTMX request as small as possible. This render only returns the main content and its CSS/Javascript assets. There are two ways to take advantage of this renderer.

One is to add an attribute to the HTMX enhanced element, which will cause the wrapper format to be used:

(new Htmx())
  ->post()
  ->onlyMainContent()
  ->target('#models-wrapper')
  ->select('#models-wrapper')
  ->swap('outerHTML')
  ->applyTo($form['make']);

There is also a new route option that can be used when creating a route specifically to service HTMX requests. This route option will also be useful with the dynamic routes in Views as we refactor to use HTMX.

demo.route_option:
  path: '/htmx-demo/route-option'
  defaults:
    _title: 'Using _htmx_route option'
    _controller: '\Drupal\module_name\Controller\DemoController::replace'
  requirements:
    _permission: 'access content'
  options:
    _htmx_route: TRUE

Drupal is still committed to supporting decoupled architectures

HTMX is an excellent solution for progressive enhancement and dynamic front-ends. It is a powerful tool in the core toolkit, not a replacement for the flexibility offered by a fully decoupled backend. Drupal remains committed to supporting decoupled and headless architectures, especially where necessary, such as mobile applications, client-side state management, deep offline capabilities, etc.

Share this

How Drupal contributed modules do CI today?

Let's give some more details about how did we get here.

The past

In summer 2023, only 2 and a half years from today, we enabled the usage of GitLab CI for the Drupal ecosystem, which includes all contrib modules and Drupal core. We announced and promoted it at DrupalCon Lille 2023.

This new system would replace entirely the DrupalCI, the custom testing solution that Drupal core and projects used for nearly 10 years prior to enabling GitLab CI.

Core tests went from taking nearly 1h to taking 10 minutes. Adoption for contrib modules was as easy as adding a seven-line file to their project.

The present

Core continued to evolve at its own pace, and the CI runs are now down to 5 minutes. They’ve been able to leverage concurrency, caching, and many other features available on GitLab CI.

Contrib modules also saw significant changes to improve their quality. Adoption was continuously growing, and the standard templates really took off, adding many new features.

As of today, we have more than 2000 contrib projects using GitLab CI.

Jobs

We offer, without writing a single line of code, the same type of tests and checks that core does.

These are: Composer lint, PHPCS, CSpell, PHPStan, ESLint, Stylelint, Nightwatch, PHPUnit, Test-only.

In addition to those, we also have: Upgrade status, Drupal CMS, GitLab Pages.

You can see that having things like “Upgrade status” or “Drupal CMS” compatibility are key for our contrib modules, and it’s available out of the box.

Also, the GitLab Pages job allows for modules to publish a full documentation site based on their markdown files. If the files are there, the documentation site will be published. An example of this is our own documentation site for the shared CI templates: https://project.pages.drupalcode.org/gitlab_templates.

Most of these jobs will offer artifacts that can be downloaded by maintainers to fix the issues reported.

Customizations

Most of the above jobs can be disabled, if they are not wanted, with only a few lines of code (turn variables to 0).

We can also test multiple versions of Drupal, like the next or previous minors or majors, again with a few lines of code (turn variables to 1).

We achieved this by extending base jobs that can be configured via variables, like this:

composer:
  extends: .composer-base
  variables:
    DRUPAL_CORE: $CORE_STABLE
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

composer (max PHP version):
  extends: .composer-base
  rules:
    - *opt-in-max-php-rule
    - *check-max-php-version-rule
    - when: always
  variables:
    PHP_VERSION: $CORE_PHP_MAX
    DRUPAL_CORE: $CORE_STABLE
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

composer (previous minor):
  extends: .composer-base
  rules:
    - *opt-in-previous-minor-rule
    - when: always
  variables:
    DRUPAL_CORE: $CORE_PREVIOUS_MINOR
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

We always keep up with the latest core releases, so maintainers don’t need to change anything to test the latest core versions. But if they want to “fix” the versions tested so these don’t change, they can pin the version of the templates that they are using with just one line of code.

They can choose which PHP version or database engine to run tests with.

External integrations

The contrib templates can be used in external instances. This is actually a five-line file (similar to the one mentioned above), but the integration remains the same. We have several community members using the templates in their own GitLab instances with their own company projects, and everything works the same.

The future

Ever since we made the switch, we have positively shaped the contribution to Drupal. Module standards are very much aligned with core standards. We get really quick in-browser feedback about what to fix; we no longer need to upload extra (test-only) patches, etc.

The possibilities are endless, and we continue looking at the future as well. We are always open to hearing about improvements. For example, only recently, thanks to suggestions from the community, we added Drupal CMS compatibility check and support for recipes.

We are also checking if we can convert some of the jobs to reusable GitLab CI components (they weren’t stable when we launched the templates).

All in all, the future looks bright, and we are really glad that we made this move as part of our broader GitLab initiative.

How other open source projects can adopt a similar solution (aka "implementation details")

Whether you have an open source project and want to do something similar, or you are just curious, here are some of the details about how we implemented this for the Drupal Ecosystem.

We had several goals in mind, some of them as must-haves, some of them as nice-to-haves. The must-haves were that it needed to be easy to adopt, and that it should allow the same functionality as the previous system. The nice-to-haves were that it would be easy to iterate and push changes to all projects using it, without project interaction, and that we could easily add new features and turn them on/off from a central place.

At the time, GitLab components were still in the works and didn't have a timeline to be stable, so we needed to think which other options were available. GitLab has the include functionality, that allows including external YAML files in a project's CI configuration. This was our starting point.

Template inheritance

We control the templates centrally at the GitLab Templates project. In there, you can see a folder called "includes", and those are the files that projects include. That's it! To make this easier, we provide a default template that gets prepopulated in GitLab and that contains the right "includes" in the right places. The seven-line template is here.

You can create a ".gitlab-ci.yml" file in the repo and add these:

include:
  - project: $_GITLAB_TEMPLATES_REPO
    ref: $_GITLAB_TEMPLATES_REF
    file:
      - '/includes/include.drupalci.main.yml'
      - '/includes/include.drupalci.variables.yml'
      - '/includes/include.drupalci.workflows.yml'

From that moment on, the project "inherits" all the templates (that we control centrally) and will start running the above CI jobs automatically.

You can see that there are three main files: one with variables, one with global workflow rules, and one containing all the jobs.

That is just the base. Each project can deviate, configure, or override any part of the template as desired, giving them flexibility that we might not be able to accommodate centrally.

We created extensive documentation and generated a GitLab Pages site to help with this: https://project.pages.drupalcode.org/gitlab_templates.

Should you want to include this in any other external GitLab instance, you just need to adapt the above to be fully qualified links as explained in our documentation page here.

As mentioned before, we can push a change (eg: bug fix, new feature) centrally, and as long as the projects make reference to our files, they will automatically receive the changes. This gives us great flexibility and extendibility, and best of all, maintainers don't need to worry about it as it is automatic for their projects.

We define variables that control the Drupal versions to tests against, the workflow rules that determine which jobs run and under which conditions, and most important of all, the logic for all the jobs ran in the pipelines.

We did it this way because it was the solution that would allow us to get all the must-haves and all the nice-to-haves. It allows literally thousands of projects to benefit instantly from shared CI checks and integration without barely writing code.

Versioning

We don't need a complex system for this, as the code is relatively small and straightforward compared to other projects, but we realised early that we needed a system because pushing the "latest" to everybody was risky, should a bug or unplanned issue arise.

We document our versioning system in the "Templates version" page. We use semver tagging, but we only maintain one branch. Depending on the changes introduced since the last tag, we increment X.Y.Z (X for breaking changes, Y for new features, Z for bug fixes), and we also generate a set of tags that will allow maintainers to pin specific versions, or moving-tags within the same major or minor. You can see the tagging script we use here.

Excerpt:

# Compute tags.
TAG="$1"
IFS=. read major minor micro <<<"${TAG}"
MINOR_TAG="${major}.${minor}.x-latest"
MAJOR_TAG="${major}.x-latest"

...
echo "Setting tag: $TAG"
git tag $TAG
git push origin $TAG

...
echo "Setting latest minor tag: $MINOR_TAG"
git tag -d $MINOR_TAG || TRUE
git push origin --delete $MINOR_TAG || TRUE
git tag $MINOR_TAG
git push origin $MINOR_TAG

...
echo "Setting latest major tag: $MAJOR_TAG"
git tag -d $MAJOR_TAG || TRUE
git push origin --delete $MAJOR_TAG || TRUE
git tag $MAJOR_TAG
git push origin $MAJOR_TAG

This process has been working well for us for around 2 years already.

Pushing changes to all contributed projects

Once the above versioning system was implemented, it was easier and quicker to iterate, and it also gave maintainers a chance to pin things. We normally push changes to the "main" branch, so all users wanting the latest changes can both benefit from them and also help us discover any possible regressions.

Once we are happy with the set of changes from the last tag, we can create new tags that maintainers can reference. Also, once we are happy that a tag is stable enough, we have a special tag named "default-ref" and all we need to do is change that tag to point to the specific stable version we want. Once we do it, that tag will automatically be pushed to all the contributed projects using the default setup.

The script that we use to set the default tag can be seen here.

Excerpt:

TAG="$1"
DEFAULT_TAG="default-ref"

echo "Setting default tag to be the same as: $TAG"

# Checkout the tag.
git checkout $TAG

# Override the default one.
git tag -d $DEFAULT_TAG || TRUE
git push origin --delete $DEFAULT_TAG || TRUE
git tag $DEFAULT_TAG
git push origin $DEFAULT_TAG

# Back to the main branch.
git checkout main

Implement it in your project

In the spirit of open source, we've documented the overarching strategy we used so that other teams fostering open source projects can adopt similar principles. We wanted to share how we did it, in case it helps any other project.

The key is to have a central place where you can control the default setup, and from there on, let projects decide what's best for their needs. They can stick to the default and recommended setup, but they could deviate from it should they need to.

How Drupal contributed modules do CI today?

Let's give some more details about how did we get here.

The past

In summer 2023, only 2 and a half years from today, we enabled the usage of GitLab CI for the Drupal ecosystem, which includes all contrib modules and Drupal core. We announced and promoted it at DrupalCon Lille 2023.

This new system would replace entirely the DrupalCI, the custom testing solution that Drupal core and projects used for nearly 10 years prior to enabling GitLab CI.

Core tests went from taking nearly 1h to taking 10 minutes. Adoption for contrib modules was as easy as adding a six-line file to their project.

The present

Core continued to evolve at its own pace, and the CI runs are now down to 5 minutes. They’ve been able to leverage concurrency, caching, and many other features available on GitLab CI.

Contrib modules also saw significant changes to improve their quality. Adoption was continuously growing, and the standard templates really took off, adding many new features.

As of today, we have more than 2000 contrib projects using GitLab CI.

Jobs

We offer, without writing a single line of code, the same type of tests and checks that core does.

These are: Composer lint, PHPCS, CSpell, PHPStan, ESLint, Stylelint, Nightwatch, PHPUnit, Test-only.

In addition to those, we also have: Upgrade status, Drupal CMS, GitLab Pages.

You can see that having things like “Upgrade status” or “Drupal CMS” compatibility are key for our contrib modules, and it’s available out of the box.

Also, the GitLab Pages job allows for modules to publish a full documentation site based on their markdown files. If the files are there, the documentation site will be published. An example of this is our own documentation site for the shared CI templates: https://project.pages.drupalcode.org/gitlab_templates. 

Most of these jobs will offer artifacts that can be downloaded by maintainers to fix the issues reported.

Customizations

Most of the above jobs can be disabled, if they are not wanted, with only a few lines of code (turn variables to 0). 

We can also test multiple versions of Drupal, like the next or previous minors or majors, again with a few lines of code (turn variables to 1).

We achieved this by extending base jobs that can be configured via variables, like this:

composer:
  extends: .composer-base
  variables:
    DRUPAL_CORE: $CORE_STABLE
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

composer (max PHP version):
  extends: .composer-base
  rules:
    - *opt-in-max-php-rule
    - *check-max-php-version-rule
    - when: always
  variables:
    PHP_VERSION: $CORE_PHP_MAX
    DRUPAL_CORE: $CORE_STABLE
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

composer (previous minor):
  extends: .composer-base
  rules:
    - *opt-in-previous-minor-rule
    - when: always
  variables:
    DRUPAL_CORE: $CORE_PREVIOUS_MINOR
    IGNORE_PROJECT_DRUPAL_CORE_VERSION: 1

We always keep up with the latest core releases, so maintainers don’t need to change anything to test the latest core versions. But if they want to “fix” the versions tested so these don’t change, they can pin the version of the templates that they are using with just one line of code.

They can choose with PHP version or database engine to run tests with.

External integrations

The contrib templates can be used in external instances. This is actually a five-line file (similar to the one mentioned above), but the integration remains the same. We have several community members using the templates in their own GitLab instances with their own company projects, and everything works the same.

The future

Ever since we made the switch, we have positively shaped the contribution to Drupal. Module standards are very much aligned with core standards. We get really quick in-browser feedback about what to fix; we no longer need to upload extra (test-only) patches, etc.

The possibilities are endless, and we continue looking at the future as well. We are always open to hearing about improvements. For example, only recently, thanks to suggestions from the community, we added Drupal CMS compatibility check and support for recipes.

We are also checking if we can convert some of the jobs to reusable GitLab CI components (they weren’t stable when we launched the templates).

All in all, the future looks bright, and we are really glad that we made this move as part of our broader GitLab initiative. 

How other open source projects can adopt a similar solution (aka "implementation details")

Whether you have an open source project and want to do something similar, or you are just curious, here are some of the details about how we implemented this for the Drupal Ecosystem.

We had several goals in mind, some of them as must-haves, some of them as nice-to-haves. The must-haves were that it needed to be easy to adopt, and that it should allow the same functionality as the previous system. The nice-to-haves were that it would be easy to iterate and push changes to all projects using it, without project interaction, and that we could easily add new features and turn them on/off from a central place.

At the time, GitLab components were still in the works and didn't have a timeline to be stable, so we needed to think which other options were available. GitLab has the include functionality, that allows including external YAML files in a project's CI configuration. This was our starting point.

Template inheritance

We control the templates centrally at the GitLab Templates project. In there, you can see a folder called "includes", and those are the files that projects include. That's it! To make this easier, we provide a default template that gets prepopulated in GitLab and that containsthe right "includes" in the right places. The six-line template is here.

You can create a ".gitlab-ci.yml" file in the repo and add these:

include:
  - project: $_GITLAB_TEMPLATES_REPO
    ref: $_GITLAB_TEMPLATES_REF
    file:
      - '/includes/include.drupalci.main.yml'
      - '/includes/include.drupalci.variables.yml'
      - '/includes/include.drupalci.workflows.yml'

From that moment on, the project "inherits" all the templates (that we control centrally) and will start running the above CI jobs automatically.

You can see that there are three main files: one with variables, one with global workflow rules, and one containing all the jobs.

That is just the base. Each project can deviate, configure, or override any part of the template as desired, giving them flexibility that we might not be able to accommodate centrally. 

We created extensive documentation and generated a GitLab Pages site to help with this: https://project.pages.drupalcode.org/gitlab_templates.

Should you want to include this in any other external GitLab instance, you just need to adapt the above to be fully qualified links as explained in our documentation page here.

As mentioned before, we can push a change (eg: bug fix, new feature) centrally, and as long as the projects make reference to our files, they will automatically receive the changes. This gives us great flexibility and extendibility, and best of all, maintainers don't need to worry about it as it is automatic for their projects.

We define variables that control the Drupal versions to tests against, the workflow rules that determine which jobs run and under which conditions, and most important of all, the logic for all the jobs ran in the pipelines.

We did it this way because it was the solution that would allow us to get all the must-haves and all the nice-to-haves. It allows literally thousands of projects to benefit instantly from shared CI checks and integration without barely writing code.

Versioning

We don't need a complex system for this, as the code is relatively small and straightforward compared to other projects, but we realised early that we needed a system because pushing the "latest" to everybody was risky, should a bug or unplanned issue arise.

We document our versioning system in the "Templates version" page. We use semver tagging, but we only maintain one branch. Depending on the changes introduced since the last tag, we increment X.Y.Z (X for breaking changes, Y for new features, Z for bug fixes), and we also generate a set of tags that will allow maintainers to pin specific versions, or moving-tags within the same major or minor. You can see the tagging script we use here.

Excerpt:

# Compute tags.
TAG="$1"
IFS=. read major minor micro <<<"${TAG}"
MINOR_TAG="${major}.${minor}.x-latest"
MAJOR_TAG="${major}.x-latest"

...
echo "Setting tag: $TAG"
git tag $TAG
git push origin $TAG

...
echo "Setting latest minor tag: $MINOR_TAG"
git tag -d $MINOR_TAG || TRUE
git push origin --delete $MINOR_TAG || TRUE
git tag $MINOR_TAG
git push origin $MINOR_TAG

...
echo "Setting latest major tag: $MAJOR_TAG"
git tag -d $MAJOR_TAG || TRUE
git push origin --delete $MAJOR_TAG || TRUE
git tag $MAJOR_TAG
git push origin $MAJOR_TAG

This process has been working well for us for around 2 years already.

Pushing changes to all contributed projects

Once the above versioning system was implemented, it was easier and quicker to iterate, and it also gave maintainers a chance to pin things. We normally push changes to the "main" branch, so all users wanting the latest changes can both benefit from them and also help us discover any possible regressions.

Once we are happy with the set of changes from the last tag, we can create new tags that maintainers can reference. Also, once we are happy that a tag is stable enough, we have a special tag named "default-ref" and all we need to do is change that tag to point to the specific stable version we want. Once we do it, that tag will automatically be pushed to all the contributed projects using the default setup.

The script that we use to set the default tag can be seen here.

Excerpt:

TAG="$1"
DEFAULT_TAG="default-ref"

echo "Setting default tag to be the same as: $TAG"

# Checkout the tag.
git checkout $TAG

# Override the default one.
git tag -d $DEFAULT_TAG || TRUE
git push origin --delete $DEFAULT_TAG || TRUE
git tag $DEFAULT_TAG
git push origin $DEFAULT_TAG

# Back to the main branch.
git checkout main

Implement it in your project

In the spirit of open source, we've documented the overarching strategy we used so that other teams fostering open source projects can adopt similar principles. We wanted to share how we did it, in case it helps any other project.

The key is to have a central place where you can control the default setup, and from there on, let projects decide what's best for their needs. They can stick to the default and recommended setup, but they could deviate from it should they need to.

On December 9th, 2025, the Drupal community gathered in Paris for a special AI summit.

As part of the larger apidays / FOST conference, we held the inaugural Drupal AI Summit designed specifically for end customers. Despite a compressed four-week organization window and a marketing campaign that ran for only three weeks, the event was oversubscribed with 170+ registered attendees.

We saw a standing-room-only crowd, peaking at around 120 people, with a sustained audience of 80-90 highly engaged delegates throughout the day. Crucially, many attendees spilled in from the wider conference, people who hadn't considered Drupal before but were drawn in by the energy and the promise of our open ecosystem.

Watch the highlights reel here! (Credit: Dan Lemon, Amazee.io)

Access all presentation slides here.

Why the World is Watching Drupal AI

The summit attracted a diverse mix of end users, agencies, and AI specialists from the UK, Switzerland, Germany, the Netherlands, Italy, and beyond. We saw heavy representation from Higher Education, Government, Manufacturing, and Enterprise sectors.

Why the sudden surge in interest? Because the Drupal AI Initiative is moving at incredible speed and momentum, leading to attracting many developers back into the community.

Want to be notified when the next Drupal AI events are coming? Follow us on LinkedIn.

One moment captured this velocity perfectly: a slide presented during the opening remarks claimed Drupal AI supported 50 AI providers, which was already outdated a week later, with another few providers being added to the list. This is the power of the open web.

While proprietary systems lock you in, the Drupal AI ecosystem expands daily, offering sovereignty, flexibility, and rapid innovation that closed platforms simply cannot match.

Showcasing the Ecosystem

The day featured eleven leading experts who demonstrated that Drupal is the most robust platform for building AI-driven digital experiences. The sessions proved that whether you need autonomous agents, secure enterprise data handling, or next-generation search, Drupal is ready today.

The Architecture of the Future

We explored the foundational power of Drupal as an orchestration layer. Alex Moreno (Pantheon) showcased how our modular architecture makes Drupal the ideal bridge between content, data, and intelligence. Giorgi Jibladze (Omedia) took this further by demonstrating Drupal as a Model Context Protocol (MCP) server, integrating seamlessly with tools like ChatGPT for interactive UI components.

Agents and Automation

The Summit highlighted that we are moving beyond simple chatbots. Marcus Johansson (FreelyGive) and Jamie Abrahams (FreelyGive) were standout voices here. Jamie introduced the Drupal AI Agent Framework, showing how we can build autonomous agents that create complex pages while keeping humans in the loop.

Marcus demonstrated the power of AI Automators, proving that complex, chained AI workflows can be built without writing a single line of code. Andrew Mallis (Kalamuna) showed how these agents can even revolutionize our workflows, using AI to "chat" with the migration process to speed up complex site upgrades.

Trust, Sovereignty, and UX

For our Enterprise and Government attendees, security was paramount. Dan Lemon (amazee.io) presented a privacy-first AI assistant that ensures data sovereignty when interacting with internal documents. Moritz Arendt (Open Social) discussed the ethics of AI in community platforms, focusing on maintaining trust. Emma Horrell (University of Edinburgh) proved that the success of these tools relies on people, sharing research on how AI-assisted editorial guidance can reshape web publishing in Higher Education.

Optimization and Search

We also looked at how content is consumed by machines. Christoph Breidert (1xINTERNET) introduced the concept of AIO (Artificial Intelligence Optimisation), teaching us how to prepare Drupal content for AI-generated search results. Artem Dmitriiev (1xINTERNET) showed how to build intelligent, semantic search tools without writing code, and Kristof Van Tomme (PRONOVIX) highlighted how AI automates documentation and "answer engine" optimization.

A Community Like No Other

This event was a huge success, not just in numbers, but in the connections made. It was a powerful way to promote Drupal to a non-Drupal audience, proving that our open-source ecosystem is the safest and most powerful bet for the future of AI.

After a day of high-speed innovation, we reconnected with our roots - human connection. We wrapped up the summit at the Paris Christmas market, sharing ideas over glühwein. It was a fitting end to a day about the future: high-tech solutions grounded in a warm, collaborative community.

Here's to wishing we all get an upgraded Drupal site with AI for Christmas!

Want to be notified when the next Drupal AI events are coming? Follow us on LinkedIn.

Presentation Slides

Below are links to the slides from presentations at Drupal AI Summit Paris.

On December 9th, 2025, the Drupal community gathered in Paris for a special AI summit.

As part of the larger apidays / FOST conference, we held the inaugural Drupal AI Summit designed specifically for end customers. Despite a compressed four-week organization window and a marketing campaign that ran for only three weeks, the event was oversubscribed with 170+ registered attendees.

We saw a standing-room-only crowd, peaking at around 120 people, with a sustained audience of 80-90 highly engaged delegates throughout the day. Crucially, many attendees spilled in from the wider conference, people who hadn't considered Drupal before but were drawn in by the energy and the promise of our open ecosystem.

Watch the highlights reel here! (Credit: Dan Lemon, Amazee.io)

Why the World is Watching Drupal AI

The summit attracted a diverse mix of end users, agencies, and AI specialists from the UK, Switzerland, Germany, the Netherlands, Italy, and beyond. We saw heavy representation from Higher Education, Government, Manufacturing, and Enterprise sectors.

Why the sudden surge in interest? Because the Drupal AI Initiative is moving at incredible speed and momentum, leading to attracting many developers back into the community.

Want to be notified when the next Drupal AI events are coming? Follow us on LinkedIn.

One moment captured this velocity perfectly: a slide presented during the opening remarks claimed Drupal AI supported 50 AI providers, which was already outdated a week later, with another few providers being added to the list. This is the power of the open web.

While proprietary systems lock you in, the Drupal AI ecosystem expands daily, offering sovereignty, flexibility, and rapid innovation that closed platforms simply cannot match.

Showcasing the Ecosystem

The day featured eleven leading experts who demonstrated that Drupal is the most robust platform for building AI-driven digital experiences. The sessions proved that whether you need autonomous agents, secure enterprise data handling, or next-generation search, Drupal is ready today.

The Architecture of the Future

We explored the foundational power of Drupal as an orchestration layer. Alex Moreno (Pantheon) showcased how our modular architecture makes Drupal the ideal bridge between content, data, and intelligence. Giorgi Jibladze (Omedia) took this further by demonstrating Drupal as a Model Context Protocol (MCP) server, integrating seamlessly with tools like ChatGPT for interactive UI components.

Agents and Automation

The Summit highlighted that we are moving beyond simple chatbots. Marcus Johansson (FreelyGive) and Jamie Abrahams (FreelyGive) were standout voices here. Jamie introduced the Drupal AI Agent Framework, showing how we can build autonomous agents that create complex pages while keeping humans in the loop.

Marcus demonstrated the power of AI Automators, proving that complex, chained AI workflows can be built without writing a single line of code. Andrew Mallis (Kalamuna) showed how these agents can even revolutionize our workflows, using AI to "chat" with the migration process to speed up complex site upgrades.

Trust, Sovereignty, and UX

For our Enterprise and Government attendees, security was paramount. Dan Lemon (amazee.io) presented a privacy-first AI assistant that ensures data sovereignty when interacting with internal documents. Moritz Arendt (Open Social) discussed the ethics of AI in community platforms, focusing on maintaining trust. Emma Horrell (University of Edinburgh) proved that the success of these tools relies on people, sharing research on how AI-assisted editorial guidance can reshape web publishing in Higher Education.

Optimization and Search

We also looked at how content is consumed by machines. Christoph Breidert (1xINTERNET) introduced the concept of AIO (Artificial Intelligence Optimisation), teaching us how to prepare Drupal content for AI-generated search results. Artem Dmitriiev (1xINTERNET) showed how to build intelligent, semantic search tools without writing code, and Kristof Van Tomme (PRONOVIX) highlighted how AI automates documentation and "answer engine" optimization.

A Community Like No Other

This event was a huge success, not just in numbers, but in the connections made. It was a powerful way to promote Drupal to a non-Drupal audience, proving that our open-source ecosystem is the safest and most powerful bet for the future of AI.

After a day of high-speed innovation, we reconnected with our roots - human connection. We wrapped up the summit at the Paris Christmas market, sharing ideas over glühwein. It was a fitting end to a day about the future: high-tech solutions grounded in a warm, collaborative community.

Here's to wishing we all get an upgraded Drupal site with AI for Christmas!

Want to be notified when the next Drupal AI events are coming? Follow us on LinkedIn.

DrupalCon Nara brought together the Drupal community in beautiful Japan a couple of weeks back, and the AI track delivered something valuable: practical sessions showing how teams are using AI to solve real problems right now. This post by Witze Van der Straeten highlights seven presentations well worth watching.

Photo: Karl Hepworth

If you're selling or managing: Stop losing deals to "AI-Powered" competitors

"Selling Drupal in the AI Age" with Niels Aers

You know the scenario: a client gets excited about some "AI-powered" platform, and suddenly your Drupal proposal seems old-fashioned. Or worse, they ask "doesn't AI make CMSs obsolete?"

Niels from Dropsolid flips this conversation with one simple truth: AI needs good data to work, and Drupal is exceptional at organizing data. While many platforms just store messy text and images, Drupal has always structured everything properly. Think of it like the difference between throwing papers in a drawer versus filing them in organized folders with labels. When AI needs to find information, organized folders win every time.

He shares a great example from a Belgian water company. They added AI search to help their customer service team answer questions faster. The team loved it so much, it saved them so much time, that the company decided to invest in AI across the whole organization. One small win created momentum for everything else.

The session gives you the actual words and examples you need when talking to clients or leadership. It shows real cost comparisons and explains why Drupal's approach is actually more reliable and affordable than those flashy alternatives.

Watch this if: You're tired of losing deals to buzzwords, or you need to convince someone that Drupal isn't outdated.

Watch Selling Drupal in the AI Age on YouTube

If you're managing a team: How to actually get people using AI

"Lessons from Integrating AI Into Real Marketing Teams" with Akansha Saxena

Akanksha tells it straight: after six months of trying to get her marketing team at Acquaia to use AI, she learned that nobody really knows what they're doing yet, and that's okay.

Here's the disconnect: you see headlines saying "88% of marketers already use AI!" But then Massachusetts Institute of Technology publishes a study showing 95% of AI projects fail. Akanksha lived in that gap and figured out what actually works.

Photo: Karl Hepworth

She discovered four real problems. First, people aren't scared of AI. They're confused by it. Her solution? "Marketing AI Office Hours" every two weeks where the team could learn together and ask questions without feeling stupid.

Second problem: everyone's too busy to learn complicated new tools. Her solution? Start so small it feels silly. They added one button to their image library that says "Generate with AI" for creating image descriptions. That's it. One button. But it solved a real annoyance, and suddenly people trusted that AI could actually help.

Third problem: AI-generated content often sounds robotic. Her solution? Mix different tools and always have humans review the final result. Never just publish what AI creates without checking it.

The best part? She shows the money. Translating 100,000 words used to cost $6,000 with traditional services. With AI translation: $2.70. That's not a typo. That's a 99.95% cost savings.

Drupal AI brought 99.95% cost savings when compared with traditional services.

She also demonstrates a workflow she built in 15 minutes that automatically creates social media posts when you publish content, sends them to Slack for approval, then publishes them. No more copying and pasting between ten different tabs.

Watch this if: You've tried getting your team to use AI and it didn't stick. Her playbook shows how to make it work without forcing people into tools they hate.

Watch Lessons from Integrating AI Into Real Marketing Teams on YouTube.

Worried about security: Building AI that respects permissions

"Smart Search, Safe Search: How Drupal + AI Work Together" with Sachiko Nitta

Here's a problem most companies building AI features ignore: what happens when different people should see different information?

Satanita demonstrates this beautifully with "Pillow Street," a fake company's internal website. When someone from the finance team asks the AI chatbot "What's our Q3 revenue?", the AI answers with the actual numbers. When a regular employee asks the same question, the AI says "I cannot access that information."

This works because Drupal's permission system filters what information reaches the AI before it generates any response. The AI never sees data the person asking isn't allowed to access. It's Drupal doing what it already does well, controlling who can see what, but now protecting your AI features too.

Most companies building AI chatbots or search features don't think about this until it's too late. Then someone uses a clever question to trick the AI into revealing confidential information. Satanita shows how to build it right from the start.

He walks through the actual setup using tools available today. It's not overly complicated. He built the demo in a reasonable amount of time using standard Drupal modules.

Watch this if: You're building any kind of AI feature where not everyone should see everything. This shows you how to do it without expensive custom security layers.

Watch Smart Search, Safe Search: How Drupal + AI Work Together on YouTube.

Want AI to actually do things: From simple tasks to complex workflows?

"AI Agents in Drupal CMS - Create your own agent" with Vincenzo Gambino

Most AI demos show it generating text. Vincenzo shows AI making decisions and taking actions across multiple systems. His demo builds an event manager. You tell it "Create an event for DrupalCon Rome on November 25th." The AI figures out it needs to do two things: create an event post on your Drupal site AND add an entry to Google Calendar. It extracts the information from your sentence, converts the date to the right format, creates both items, then tells you it's done.

The key word is "figures out." You didn't tell it to do both those steps. It understood what an event means and what tools it has available, then decided what to do.

Vincenzo explains the difference between two approaches. Workflows are like recipes: step 1, step 2, step 3. Agents are like giving someone a goal and letting them figure out how to reach it. Workflows are more predictable. Agents are more flexible. Each has its place.

Workflows are more predictable. Agents are more flexible. Each has its place.

He also mentions something fascinating that nobody talks about: if you're building AI features in multiple languages, Japanese text costs 40% more to process than English. French costs 15% more. These aren't tiny differences. They're real budget impacts if you're serving global audiences.

Watch this if: You want AI to do more than write text. This shows how to build systems where AI coordinates multiple actions across different tools.

Watch AI Agents in Drupal CMS - Create your own agent on Youtube

If you need proof: Real companies using Drupal AI today

"Epic things you built with Drupal AI" with Michael Schmid

If you're skeptical whether this AI stuff actually works in the real world, Michael rapid-fires through ten companies already using it in production.

• World Cancer Day uses AI to automatically filter spam from story submissions.
• A French telecom built an image search that verifies whether they own the rights to use photos (99% accuracy). 
• A UK council converted over 2,000 old PDF documents into accessible websites 240 times faster than doing it manually.
• A shipping company reduced problem resolution from weeks to minutes.
• A European train company processes 20,000 delay compensation claims per hour and actually improved customer satisfaction with the faster service.

The pattern? Most of these aren't flashy public features. They're internal tools that make teams more efficient. That's where AI has the biggest impact right now. Not replacing people, but giving them superpowers to handle volume they couldn't before.

Michael also announced that if you've built something with Drupal AI, even just an experiment, you can get help publishing a case study quickly by contacting the Drupal AI Initiative Marketing Team. They're actively collecting stories to show what's possible.

Watch this if: You need to convince someone this is real and not just hype. These are actual companies solving actual problems today.

Watch Epic things you built with Drupal AI on YouTube.

If you work globally: Respecting culture while moving fast

"The Future of Workflow Optimization with AI & Drupal Canvas" with Maggie Schroeder and Shumpei Kishi

This session includes a demo that's both entertaining and brilliant. The scenario: DrupalCon starts in two days, you need a Japanese landing page, leadership wants it today.

They use Drupal Canvas with AI to build a complete page with custom features in three minutes. But here's where it gets interesting. When they try to publish, someone says "Wait. This is for Japan. We need to do Nemawashi first."

Nemawashi is a Japanese business practice of informing key people before making announcements. Not asking permission, but showing respect by not surprising them. Normally this takes an hour: write an email summary, translate it to Japanese, figure out who should receive it, send it out.

Instead, they prompt the automation system with Drupal's ECA module: "Build a workflow when an article is published. Summarize the content in English and Japanese. Email the summary to the user named 'stakeholders'." The AI builds this workflow automatically. They publish the content, and the system handles the cultural protocol without manual work.

This demonstrates something important: AI can respect organizational and cultural requirements while still moving fast. It's not about eliminating processes. It's about automating the parts that slow you down.

The demo also shows Acquia Source Writing Assistant, which is trained specifically to write content that other AIs will cite and reference. It's not just about search engines anymore. It's about making sure ChatGPT and Claude mention your content when people ask questions.

Watch this if: You manage international teams or need to balance speed with proper organizational process.

Watch The Future of Workflow Optimization with AI & Drupal Canvas on YouTube.

If you're planning Drupal's future: Understanding the Strategic Vision

"Next steps for Drupal Canvas" with Lauri Timmanee

Most Canvas presentations show you how to build pages. Lauri shows you why Canvas exists and where it's going. Essential context if you're making strategic decisions about Drupal.

The mission is clear: make Drupal the gold standard for no-code website building. But AI has fundamentally changed what "gold standard" means. Three years ago, "easy but takes weeks" was acceptable. In 2025, when tools like Lovable can build functional prototypes in minutes, Drupal needs a different approach.

Lauri demonstrates this with a live comparison: building a tour listing page in Canvas takes about 7 minutes. The AI understands your existing components, content model, and field structure, then generates a working page using your design system. Not generic output that you have to rebuild. Actual production-ready components.

Here's what makes Canvas different from pure AI builders: it's built for scale. AI tools can create one page fast, but what happens when you have 1,000 pages and need to update the navigation? Canvas combines AI speed with CMS structure. The same reason CMSs replaced Dreamweaver 15 years ago.

AI tools can create one page fast, but what happens when you have 1,000 pages and need to update the navigation? Canvas combines AI speed with CMS structure.

The roadmap for 2026 includes features that directly address AI-era needs: integrated AI context control (so AI knows your brand voice), external AI tool support (use Cursor or PHPStorm with Drupal), translation support, and the ability to edit content directly inside Canvas layouts.

But the most interesting part? Lauri's honest about what they're still figuring out. How do you enable vertical markets? If Drupal wanted to dominate healthcare next year, what modules and improvements would make that happen? These questions are still open, which means this is the right time to influence the direction.

Watch this if: You're making long-term decisions about Drupal adoption, or you want to understand how Drupal is positioning itself against pure AI site builders.

Watch Next steps for Drupal Canvas on YouTube.

Why these sessions are different

Most AI presentations either promise magic that doesn't exist or show toy examples that don't translate to real work. DrupalCon Nara's sessions were different because they addressed real problems.

A pattern emerged across multiple sessions: AI gets you 80% of the way there, humans do the final 20%. This explains why so many AI projects fail. They aim for 100% automation when 80/20 is the sustainable approach. Keep humans involved for review, refinement, and final decisions.

Another theme: Drupal's permission system becomes your AI's security system. Whether it's search, content generation, or workflow automation, Drupal makes sure AI respects who should see what. Most AI vendors either skip this entirely or charge extra to build it custom.

Finally: everything is moving toward components. Think of components like LEGO blocks. Standardized pieces that fit together in predictable ways. AI is much better at understanding and using structured components than random layouts. Drupal is all-in on this approach.

The Bottom Line

The real story from DrupalCon Nara isn't about fancy features. It's about how Drupal is positioning itself for the AI era. Not by bolting on AI features, but by being the platform that combines AI's speed with the reliability, security, and structure that real organizations need.

Tools like Lovable can build things fast, but they can't manage thousands of pages, respect permissions, or handle complex organizational workflows. Traditional systems have those capabilities but can't match AI's speed. Drupal is finding the middle ground: fast enough to compete with AI tools, robust enough to actually run a business on.

These sessions are now live on the Drupal Association YouTube channel. Watch them because they show solutions to problems you're probably dealing with right now. Whether you're losing deals to trendier-sounding competitors, trying to get your team on board with AI, building systems that handle sensitive data, or just trying to automate the boring parts of your job, someone at DrupalCon Nara showed how they solved it.

And that's what makes these sessions valuable.
 

DrupalCon Nara brought together the Drupal community in beautiful Japan a couple of weeks back, and the AI track delivered something valuable: practical sessions showing how teams are using AI to solve real problems right now. This post by Witze Van der Straeten highlights seven presentations well worth watching.

Photo: Karl Hepworth

If you're selling or managing: Stop losing deals to "AI-Powered" competitors

"Selling Drupal in the AI Age" with Niels Aers

You know the scenario: a client gets excited about some "AI-powered" platform, and suddenly your Drupal proposal seems old-fashioned. Or worse, they ask "doesn't AI make CMSs obsolete?"

Niels from Dropsolid flips this conversation with one simple truth: AI needs good data to work, and Drupal is exceptional at organizing data. While many platforms just store messy text and images, Drupal has always structured everything properly. Think of it like the difference between throwing papers in a drawer versus filing them in organized folders with labels. When AI needs to find information, organized folders win every time.

He shares a great example from a Belgian water company. They added AI search to help their customer service team answer questions faster. The team loved it so much, it saved them so much time, that the company decided to invest in AI across the whole organization. One small win created momentum for everything else.

The session gives you the actual words and examples you need when talking to clients or leadership. It shows real cost comparisons and explains why Drupal's approach is actually more reliable and affordable than those flashy alternatives.

Watch this if: You're tired of losing deals to buzzwords, or you need to convince someone that Drupal isn't outdated.

Watch Selling Drupal in the AI Age on YouTube

If you're managing a team: How to actually get people using AI

"Lessons from Integrating AI Into Real Marketing Teams" with Akansha Saxena

Akanksha tells it straight: after six months of trying to get her marketing team at Acquaia to use AI, she learned that nobody really knows what they're doing yet, and that's okay.

Here's the disconnect: you see headlines saying "88% of marketers already use AI!" But then Massachusetts Institute of Technology publishes a study showing 95% of AI projects fail. Akanksha lived in that gap and figured out what actually works.

Photo: Karl Hepworth

She discovered four real problems. First, people aren't scared of AI. They're confused by it. Her solution? "Marketing AI Office Hours" every two weeks where the team could learn together and ask questions without feeling stupid.

Second problem: everyone's too busy to learn complicated new tools. Her solution? Start so small it feels silly. They added one button to their image library that says "Generate with AI" for creating image descriptions. That's it. One button. But it solved a real annoyance, and suddenly people trusted that AI could actually help.

Third problem: AI-generated content often sounds robotic. Her solution? Mix different tools and always have humans review the final result. Never just publish what AI creates without checking it.

The best part? She shows the money. Translating 100,000 words used to cost $6,000 with traditional services. With AI translation: $2.70. That's not a typo. That's a 99.95% cost savings.

Drupal AI brought 99.95% cost savings when compared with traditional services.

She also demonstrates a workflow she built in 15 minutes that automatically creates social media posts when you publish content, sends them to Slack for approval, then publishes them. No more copying and pasting between ten different tabs.

Watch this if: You've tried getting your team to use AI and it didn't stick. Her playbook shows how to make it work without forcing people into tools they hate.

Watch Lessons from Integrating AI Into Real Marketing Teams on YouTube.

Worried about security: Building AI that respects permissions

"Smart Search, Safe Search: How Drupal + AI Work Together" with Sachiko Nitta

Here's a problem most companies building AI features ignore: what happens when different people should see different information?

Satanita demonstrates this beautifully with "Pillow Street," a fake company's internal website. When someone from the finance team asks the AI chatbot "What's our Q3 revenue?", the AI answers with the actual numbers. When a regular employee asks the same question, the AI says "I cannot access that information."

This works because Drupal's permission system filters what information reaches the AI before it generates any response. The AI never sees data the person asking isn't allowed to access. It's Drupal doing what it already does well, controlling who can see what, but now protecting your AI features too.

Most companies building AI chatbots or search features don't think about this until it's too late. Then someone uses a clever question to trick the AI into revealing confidential information. Satanita shows how to build it right from the start.

He walks through the actual setup using tools available today. It's not overly complicated. He built the demo in a reasonable amount of time using standard Drupal modules.

Watch this if: You're building any kind of AI feature where not everyone should see everything. This shows you how to do it without expensive custom security layers.

Watch Smart Search, Safe Search: How Drupal + AI Work Together on YouTube.

Want AI to actually do things: From simple tasks to complex workflows?

"AI Agents in Drupal CMS - Create your own agent" with Vincenzo Gambino

Most AI demos show it generating text. Vincenzo shows AI making decisions and taking actions across multiple systems. His demo builds an event manager. You tell it "Create an event for DrupalCon Rome on November 25th." The AI figures out it needs to do two things: create an event post on your Drupal site AND add an entry to Google Calendar. It extracts the information from your sentence, converts the date to the right format, creates both items, then tells you it's done.

The key word is "figures out." You didn't tell it to do both those steps. It understood what an event means and what tools it has available, then decided what to do.

Vincenzo explains the difference between two approaches. Workflows are like recipes: step 1, step 2, step 3. Agents are like giving someone a goal and letting them figure out how to reach it. Workflows are more predictable. Agents are more flexible. Each has its place.

Workflows are more predictable. Agents are more flexible. Each has its place.

He also mentions something fascinating that nobody talks about: if you're building AI features in multiple languages, Japanese text costs 40% more to process than English. French costs 15% more. These aren't tiny differences. They're real budget impacts if you're serving global audiences.

Watch this if: You want AI to do more than write text. This shows how to build systems where AI coordinates multiple actions across different tools.

Watch AI Agents in Drupal CMS - Create your own agent on Youtube

If you need proof: Real companies using Drupal AI today

"Epic things you built with Drupal AI" with Michael Schmid

If you're skeptical whether this AI stuff actually works in the real world, Michael rapid-fires through ten companies already using it in production.

• World Cancer Day uses AI to automatically filter spam from story submissions.
• A French telecom built an image search that verifies whether they own the rights to use photos (99% accuracy). 
• A UK council converted over 2,000 old PDF documents into accessible websites 240 times faster than doing it manually.
• A shipping company reduced problem resolution from weeks to minutes.
• A European train company processes 20,000 delay compensation claims per hour and actually improved customer satisfaction with the faster service.

The pattern? Most of these aren't flashy public features. They're internal tools that make teams more efficient. That's where AI has the biggest impact right now. Not replacing people, but giving them superpowers to handle volume they couldn't before.

Michael also announced that if you've built something with Drupal AI, even just an experiment, you can get help publishing a case study quickly by contacting the Drupal AI Initiative Marketing Team. They're actively collecting stories to show what's possible.

Watch this if: You need to convince someone this is real and not just hype. These are actual companies solving actual problems today.

Watch Epic things you built with Drupal AI on YouTube.

If you work globally: Respecting culture while moving fast

"The Future of Workflow Optimization with AI & Drupal Canvas" with Maggie Schroeder and Shumpei Kishi

This session includes a demo that's both entertaining and brilliant. The scenario: DrupalCon starts in two days, you need a Japanese landing page, leadership wants it today.

They use Drupal Canvas with AI to build a complete page with custom features in three minutes. But here's where it gets interesting. When they try to publish, someone says "Wait. This is for Japan. We need to do Nemawashi first."

Nemawashi is a Japanese business practice of informing key people before making announcements. Not asking permission, but showing respect by not surprising them. Normally this takes an hour: write an email summary, translate it to Japanese, figure out who should receive it, send it out.

Instead, they prompt the automation system with Drupal's ECA module: "Build a workflow when an article is published. Summarize the content in English and Japanese. Email the summary to the user named 'stakeholders'." The AI builds this workflow automatically. They publish the content, and the system handles the cultural protocol without manual work.

This demonstrates something important: AI can respect organizational and cultural requirements while still moving fast. It's not about eliminating processes. It's about automating the parts that slow you down.

The demo also shows Acquia Source Writing Assistant, which is trained specifically to write content that other AIs will cite and reference. It's not just about search engines anymore. It's about making sure ChatGPT and Claude mention your content when people ask questions.

Watch this if: You manage international teams or need to balance speed with proper organizational process.

Watch The Future of Workflow Optimization with AI & Drupal Canvas on YouTube.

If you're planning Drupal's future: Understanding the Strategic Vision

"Next steps for Drupal Canvas" with Lauri Timmanee

Most Canvas presentations show you how to build pages. Lauri shows you why Canvas exists and where it's going. Essential context if you're making strategic decisions about Drupal.

The mission is clear: make Drupal the gold standard for no-code website building. But AI has fundamentally changed what "gold standard" means. Three years ago, "easy but takes weeks" was acceptable. In 2025, when tools like Lovable can build functional prototypes in minutes, Drupal needs a different approach.

Lauri demonstrates this with a live comparison: building a tour listing page in Canvas takes about 7 minutes. The AI understands your existing components, content model, and field structure, then generates a working page using your design system. Not generic output that you have to rebuild. Actual production-ready components.

Here's what makes Canvas different from pure AI builders: it's built for scale. AI tools can create one page fast, but what happens when you have 1,000 pages and need to update the navigation? Canvas combines AI speed with CMS structure. The same reason CMSs replaced Dreamweaver 15 years ago.

AI tools can create one page fast, but what happens when you have 1,000 pages and need to update the navigation? Canvas combines AI speed with CMS structure.

The roadmap for 2026 includes features that directly address AI-era needs: integrated AI context control (so AI knows your brand voice), external AI tool support (use Cursor or PHPStorm with Drupal), translation support, and the ability to edit content directly inside Canvas layouts.

But the most interesting part? Lauri's honest about what they're still figuring out. How do you enable vertical markets? If Drupal wanted to dominate healthcare next year, what modules and improvements would make that happen? These questions are still open, which means this is the right time to influence the direction.

Watch this if: You're making long-term decisions about Drupal adoption, or you want to understand how Drupal is positioning itself against pure AI site builders.

Watch Next steps for Drupal Canvas on YouTube.

Why these sessions are different

Most AI presentations either promise magic that doesn't exist or show toy examples that don't translate to real work. DrupalCon Nara's sessions were different because they addressed real problems.

A pattern emerged across multiple sessions: AI gets you 80% of the way there, humans do the final 20%. This explains why so many AI projects fail. They aim for 100% automation when 80/20 is the sustainable approach. Keep humans involved for review, refinement, and final decisions.

Another theme: Drupal's permission system becomes your AI's security system. Whether it's search, content generation, or workflow automation, Drupal makes sure AI respects who should see what. Most AI vendors either skip this entirely or charge extra to build it custom.

Finally: everything is moving toward components. Think of components like LEGO blocks. Standardized pieces that fit together in predictable ways. AI is much better at understanding and using structured components than random layouts. Drupal is all-in on this approach.

The Bottom Line

The real story from DrupalCon Nara isn't about fancy features. It's about how Drupal is positioning itself for the AI era. Not by bolting on AI features, but by being the platform that combines AI's speed with the reliability, security, and structure that real organizations need.

Tools like Lovable can build things fast, but they can't manage thousands of pages, respect permissions, or handle complex organizational workflows. Traditional systems have those capabilities but can't match AI's speed. Drupal is finding the middle ground: fast enough to compete with AI tools, robust enough to actually run a business on.

These sessions are now live on the Drupal Association YouTube channel. Watch them because they show solutions to problems you're probably dealing with right now. Whether you're losing deals to trendier-sounding competitors, trying to get your team on board with AI, building systems that handle sensitive data, or just trying to automate the boring parts of your job, someone at DrupalCon Nara showed how they solved it.

And that's what makes these sessions valuable.
 

Drupal is now in the OSV database, see some examples.

One of the key parts of keeping a website secure is making sure you have updated to incorporate security updates. Today, we're excited to share that Drupal's security information will be available in a new channel that has some benefits compared to existing tools. This is another large step forward in making it easier for Drupal sites to stay secure.

How can people get security data today?

Since 2005 people have been able to subscribe to emails or an RSS feed with security announcements. More recently those feeds were mirrored on social media sites as well. However, these feeds include a lot of "noise" - news about releases for software that are not installed on a specific site.

Since 2007, Drupal has provided a built-in mechanism for site maintainers to check if their site was out of date. Sites using the Update module could check if they needed updates and email that report to the site owner or show it inside the system or via a "drush" command on the command line. This report is focused on what the site needs: the administrator only learns about updates to the software running on the site, but it requires knowing a Drupal-specific tool.

Modern versions of Drupal leverage the composer package manager. Drupal has supported the composer audit command which was introduced in 2022. However, again, this is a tool that is mostly used in the php community and doesn't provide security data about other package types.

Drupal sites often include npm packages and other 3rd party libraries that might have their own update monitoring mechanism.

Staying aware of available releases is a subjective and personal question. What works well for one organization might not work well for another. Knowing these options and their shortcomings, can we make it easier for site owners to monitor their sites?

How is the OSV format better?

The OSV format and database provide several advantages. Perhaps the biggest one for Drupal sites is they provide support for a wide variety of packages. Publishing Drupal's security advisories in OSV.dev will enable the OSV-scanner automated scanning tool to create accurate reports for Drupal sites making it easier for organizations to adopt Drupal and help ensure it is up to date. It will also make it easier for other projects to support Drupal if they incorporate OSV.dev data.

Who made this happen?

For OSV.dev support, there was a collaboration across several teams and timezones: folks at Google, Ackama, the Drupal Association, and members of the Drupal Security Team have collaborated to automate osv support. In particular, Gold, Gareth Jones, Greg Knaddison, Dave Long, Peter Wolanin, and Neil Drumm worked to help get it launched or will help maintain it. The result will hopefully provide greater awareness, easier support, and minimal additional manual work to support this new channel.

Also, we should recognize efforts in this field that provided a great foundation. Derek Wright (dww) did a ton of work to help Drupal's infrastructure related to the Update module for many years. The integration of data that gets into osv.dev relies on an API from drupal.org that is provided with a lot of work from the Drupal Association. The content of the feed, of course, comes from project maintainers and the Drupal Security Team.

Guest Blog Post by Luke McCormick

BADCamp, the Bay Area Drupal Camp, has been a Drupal gathering in the Bay Area most years since 2007. This year’s BADCamp had a particular focus on artificial intelligence. There were many exciting things to see and hear about AI, and the overall programme reflected a blend of practical tooling, architecture, and community direction.

Drupal Core UX Manager Emma Horrell set the stage with the opening keynote, Turning Feelings into Features – Why UX Is an Innovation Catalyst for Drupal (video). While not framed as an AI talk specifically, the keynote grounded much of what followed. Emma emphasized UX as an active, user-centred practice rooted in trust, language, and real-world workflows, principles that are especially critical for the effective use of AI tools. Her keynote flowed directly into the next session in the same room, underscoring how closely UX and AI strategy are now intertwined in Drupal.

Immediately following the keynote, Drupal AI Initiative lead Kristen Pol presented Accelerating Innovation: The Drupal AI Initiative (video), outlining the current state and direction of Drupal’s AI efforts. Kristen described how the initiative is moving beyond isolated experiments toward coordinated work across providers, UX research, contributor experience, and shared infrastructure. Shortly thereafter, André Angelantoni’s Drupal CMS Late 2025 Update (video) highlighted how AI capabilities are becoming part of Drupal CMS planning itself, signalling a shift from AI as an add-on toward AI as expected infrastructure.

Building Drupal Sites with AI

The AI momentum continued with a wide range of additional sessions devoted to artificial intelligence at BADCamp. Several talks focused on hands-on, builder-friendly uses of AI in Drupal. J. Matthew Saunders led Getting Hands-On with Drupal AI: Build Smarter Sites with Zero Code (video), while Sal Lakhani presented 3 Ways to Use AI in Drupal (video), covering practical patterns such as chatbots, search, and code generation. Sal also delivered a second session, The #1 Drupal AI Demo, Development, and Learning Platform (DrupalForge) (video), demonstrating how hands-on experimentation and learning can be supported in a structured way.

Jordan Koplowicz explored the easy way and the hard way to create AI Chatbots in Drupal. The “easy” way requires no code, which he explains in Creating an AI Chatbot in Drupal: The Easy Way (video), which he followed up the next day with the “hard” way in AI on Headless Drupal (video), where he showed how to create a headless AI chatbot. Meta’s Prabhakar Singh rounded out this group with Building Smart Content Moderation for Drupal: AI-Powered Spam Detection and Community Safety (video), illustrating how AI can be used to increase trust, safety, and community health.

BADCamp also featured sessions that took a more strategic and forward-looking view of AI. Steve Carlson presented Preparing for the Future: AI, the Changing Consumption Landscape, and Combating AI Threats (video), focusing on how organizations must adapt to shifts in how content is created and consumed. Alongside this, James Sansbury presented Preparing Your Pipeline for the AI Revolution (video), addressing organizational readiness, governance, and workflow implications. Satish Kumar Nagireddy presented AI-Powered Content Intelligence: Multi-Modal Analysis for Drupal Media Management (video), demonstrating how AI can analyze and enrich media across formats while remaining compatible with Drupal’s content and editorial models.

Drupal Coding with AI

Developers were well represented in the AI programming as well. Mark Ferree’s session, AI Dev Tools: How Not to Get Lost in the Chaos (video), surveyed the rapidly evolving landscape of AI-assisted development tools from the perspective of someone with extensive engineering experience. In contrast, Luke McCormick focused on pragmatic techniques that can be used even by people who do not consider themselves full-time Drupal coders in Quick and Easy Migrations and Upgrades Using AI (video), which demonstrated how to use AI-enabled editors like Cursor to speed up common Drupal development, upgrade, and feature-building tasks.

The BADCamp AI Summit

Beyond individual sessions, BADCamp 2025 featured its first dedicated AI Summit, a deeper-dive gathering focused specifically on AI in Drupal. The summit brought together speakers and organizers from across the conference and included a live remote discussion with Jamie Abrahams, who joined from the UK to share an update on the broader Drupal AI landscape. Jamie emphasized that Drupal AI has moved beyond theory and proof-of-concept demos into the stage where real-world use cases and case studies are the next critical need. Rather than flashy demonstrations, the focus is now on reliable, high-value applications that build on Drupal’s strengths in UX, governance, trust, and longevity.

Taken together, the sessions and the AI Summit showed a Drupal community that has moved past speculation and into execution. The conversations at BADCamp reflected a shared understanding that AI’s impact will be shaped not just by what is technically possible, but by how thoughtfully it is designed, integrated, and governed. Across sessions, summits, and hallway conversations alike, the message was consistent: this is work the whole community can and should engage in, and BADCamp 2025 demonstrated that Drupal is actively rising to that challenge.

For years, Drupal has been the platform of choice for organizations that need serious digital capabilities—think universities managing millions of pages, government agencies with complex workflows, and Fortune 500 companies running mission-critical websites. The power is undeniable, but there's always been a catch: you needed technical expertise to unlock it.

That’s why one of the most exciting areas of Drupal’s journey has been the work underway on more intuitive, visual building experiences. The community has spent years exploring how to make Drupal feel more accessible to site builders and content teams without sacrificing the flexibility and robustness that define Drupal.

Drupal Canvas is the next step in that journey.

More than a “new feature drop,” Drupal Canvas represents an ongoing, community-driven effort to modernize how we build with Drupal. Canvas adds a more visual, flexible way to arrange and adjust page components, helping non-developers work more independently while providing developers space for deeper technical work.

No More Trade-offs 

As Lauri Timmanee, Drupal Canvas's product lead, explained: "There's a trade-off that exists in Drupal - either you're forced into building sort of a cookie cutter website...or you go into complex coding. We want to break that trade-off by providing better tools so that you can actually build websites that are custom to your brand without having to know complex code."

What's Included in Drupal Canvas 1.0

Drupal Canvas provides the foundation for a more intuitive page-building workflow in Drupal. Built with React on the frontend and integrated with Drupal's core APIs on the backend, it focuses on helping site builders arrange and adjust content more easily, with features such as:

• Component based visual page building with a drag-and-drop interface
• In-browser code components that allow you to add new building blocks
• Create and preview multiple pages before publication with multi-step undo

Try It Out and Get Involved

Drupal Canvas represents the Drupal community's collaborative innovation at its best—open and with a foundation of real-world use cases. As work continues, community feedback will continue to play a large role in shaping the next phases.

• Check out the Drupal Canvas demo with the Drupal brand. Local installation instructions at https://github.com/phenaproxima/canvas-demo
• Join the #drupal-canvas channel in Slack for active community discussion.

Your feedback and involvement will directly shape the future of content management in Drupal.