In today’s fast-paced digital economy, successful organizations must align their technical architecture with strategic business goals. DrupalCon Vienna 2025 isn’t just a gathering of developers, it's a dynamic intersection where business leaders, marketers, technical architects, and product managers come together to explore how Drupal drives innovation and delivers measurable impact.
Whether you're launching global digital platforms, scaling personalization, improving time to market, or enhancing user experience this year’s DrupalCon is where you’ll find the insights, tools, and partners to make it happen.
Modern digital strategies depend on a solid technical foundation. At DrupalCon Vienna, you’ll hear directly from digital leaders and enterprise teams who have successfully:
Case studies, panel discussions, and solution showcases will provide practical takeaways that go beyond buzzwords from project planning and governance to content strategy and performance optimization.
Drupal has evolved far beyond a CMS. It's a flexible, enterprise-ready digital experience platform (DXP) capable of powering everything from campaign websites to enterprise portals. At DrupalCon Vienna 2025, sessions will explore:
If you're leading digital transformation efforts, this is your opportunity to see how Drupal is enabling organizations to innovate with confidence.
DrupalCon Vienna provides unmatched opportunities for networking with people who share your challenges and ambitions from digital directors and CTOs to agency leaders and product strategists.
You’ll meet:
These conversations often spark partnerships, ideas, and collaborations that last long after the event ends.
For teams focused on long-term planning, DrupalCon offers curated content designed to guide your strategic roadmap. Attend workshops and sessions on:
Whether you're managing your first Drupal rollout or optimizing a mature platform, there’s content here for every stage of your digital journey.
DrupalCon Vienna 2025 is more than a conference, it's a catalyst for growth, innovation, and alignment. Join us to discover how forward-thinking organizations are leveraging Drupal to unlock digital success across departments and markets.
🗓️ Dates: October 14–17, 2025
📍 Location: Austria Center Vienna, Vienna, Austria
🌐 Official Website & Registration: https://events.drupal.org/vienna2025/registration-information
🐦 Follow the buzz: #DrupalConVienna #DrupalCon2025
This blog is just the beginning. Over the next few weeks, I’ll be sharing:
So bookmark this space, and get ready to experience DrupalCon Vienna 2025 like never before.
Are you coming? Let’s connect!
Technical Lead
WSO2
The second feature release of Drupal 11 improves backend and frontend performance and scalability, completes the introduction of OOP support of hooks, adds JSON Schema support, includes AVIF image format capability, supports SDC variants, and more.
Thanks to various optimizations to container rebuilding and the installer, installing Drupal itself or extensions is now three to four times as fast. There are similar improvements when using the user interface, but it is more apparent when using Drush. In this video, we show Drupal 11.2 installing 60 modules in 5.7 seconds while Drupal 11.1 takes four times as much to do the same:
Starting with Drupal 11.2, the last APIs that needed .module files can be implemented as object-oriented hooks too! Developers can make use of [#RemoveHook] attributes to remove hooks, [#ReOrderHook] to change hook ordering and #[Preprocess] attributes to declare object-oriented preprocess hooks. Now there is no need for a .module file if all of the hooks are on classes in the Hook namespace.
When working with Drupal entities over an API, it is important for developer experience to have a schema for the data structure of a particular entity. This allows clients to know, for instance, what acceptable values may be sent or received for the value and format properties of a formatted text field.
Drupal core can now generate JSON Schemas for content entity types. The typed data, serialization and field APIs have been enhanced to allow field-level schemas to be generated based on their storage configuration.
All field types shipped by core now provide JSON Schemas out of the box through their default normalizers. In addition, all the core typed data plugins provide JSON Schemas as well. This means that all core fields can generate JSON Schemas for their properties out of the box. Additionally, most field types provided by contributed projects or custom modules will generate JSON Schemas automatically so long as they do not provide a custom normalizer or depend on non-core typed data plugins.
In design systems, a variant allows grouping multiple component properties into a predefined set. The variant can then be used as a shortcut to render a component. Front-end developers could previously define a variant as a prop, but this approach did not support custom titles or descriptions to convey the variant’s purpose.
Now, you can use variants as a property at the root of your component declaration:
name: Card
variants:
primary:
title: Primary
description: ...
secondary:
title: Secondary
description: ...
props: {}
slots: {}
Drupal 11.2 now supports AVIF in our image toolkit. AVIF offers better compression and image quality than WebP, especially for high-resolution images and HDR content. However, not all servers support conversion to AVIF. For that reason, a fallback mechanism was added to convert to WebP when AVIF support is not available.
Drupal core has long supported component-based CSS organization and conditional loading that depends on page elements. Using this system, the default CSS added to every page by Drupal core has been reduced from around 7 KB to 1 KB. This will improve bandwidth requirements and page rendering times for all but the most highly customized sites running on 11.2.
The modern Navigation module now automatically enables the built-in top bar functionality as well. An "overview" link is now shown when a menu item is a container for child items, making it easier to find the right page. Numerous other blockers have also been resolved, and this experimental module is close to becoming stable in a future minor release.
Drupal recipes are special Composer packages designed to bootstrap Drupal projects with necessary dependencies. When a recipe is required, a new Composer plugin "unpacks" it by moving the recipe's dependencies directly into your project's root composer.json, and removes the recipe as a project dependency. This makes it possible to update those dependencies later and to not have the recipe as an active dependency of the site anymore.
Update Status now checks the status of uninstalled extensions, making your site even more secure.
Updating themes and modules in the Update Status module with authorize.php was not Composer-aware. This could cause various serious problems for sites and site deployment workflows. Therefore, this legacy feature has now been removed. Projects should generally be updated on the command line with Composer. The experimental Update Manager (Automatic Updates) will also be used for this in the future.
Significant improvements have been made to Drupal's render cache performance due to optimizations in placeholder processing and cache tag invalidation checks. This results in smaller cache entries with fewer cache dependencies in the dynamic page cache, leading to higher cache hit rates and reduced cache storage requirements. The reduction in cache tag lookups reduces round trips to persistent cache storage backends on every HTML response. This applies whether the cache tag backend is using database, memcache, or redis, and leads to slightly faster page rendering performance on both dynamic page cache hits and misses. There is also a significant reduction in queries per second (QPS) for high-traffic sites, which should allow caching servers to handle more traffic with lower hardware requirements.
PHPUnit 11 can now be used for testing. While the default version remains PHPUnit 10, it's possible to update to PHPUnit with the command composer update phpunit/phpunit --with-dependencies. Drupal core testing on PHP 8.4 requires PHPUnit 11 as a minimum.
Since Drupal 11.1, Emma Horrel and Cristina Chumillas were announced as UX Managers.
Griffyn Heels joined as a provisional Core Leadership Team Facilitator. Juraj Nemec and Drew Webber were added as general core committers, and Pierre Dureau was added as a provisional Frontend Framework Manager. Check out their announcement.
Six people stepped up to become subsystem maintainers! Nic Laflin became a maintainer of the Extension API, Lee Rowlands became a co-maintainer of the Form and Render APIs, Adam Bramley became maintainer of Node module, Jean Valverde became a co-maintainer of Single-Directory Components. Mark Conroy became the maintainer of the Stable 9 theme and Brad Jones became a co-maintainer of Serialization. Many of the improvements above are thanks to leadership from these new maintainers!
Three subsystem maintainers stepped back. We thank Claudiu Cristea, Christian Fritsch, and Daniel Wehner for their immense contributions.
Finally, there have also been changes in the mentoring coordinator team: James Shields joined, while Mauricio Dinarte, AmyJune Hineline and Tara King stepped back from the role. Many Drupal contributors are thankful to have been mentored by them!
The next maintenance minor release of Drupal 10 has also been released. Drupal 10 will be supported until December 9, 2026, after the release of Drupal 12. Long-term support for Drupal 10 is managed with a new maintenance minor release every 6 months that receives twelve months of support. This allows the maintenance minor to adapt to evolving dependencies. It also gives more flexibility for sites to move to Drupal 11 when they are ready.
This release schedule allows sites to move from one LTS 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.
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. Join us at DrupalCon Vienna in October 2025 or DrupalCon Nara in November 2025 to attend sessions, network, and enjoy mentorship for your first contributions.
This is part 2 of a series on having CI pipelines for your Drupal site, and building Drupal Deploy Confidence. In this part of our series, we’re looking at another low-hanging fruit: composer validate. It's quick to set up and can save your team from subtle but frustrating dependency issues.
According to the official Composer documentation, this command:
...checks if your composer.json is valid. If a composer.lock exists, it will also check if it is up to date with the composer.json.
That might sound trivial, but in practice it solves a common and annoying problem: when the lock file is out of sync with composer.json.
You’ve probably seen this warning:
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.
In a CI context, composer validate will fail with a non-zero exit code if this mismatch is found. That’s a good thing - it prevents developers from merging code that might lead to confusion, instability, or surprise dependency changes.
Here’s why we make composer validate a standard in CI pipelines:
1. It prevents outdated or unexpected dependencies
When the lock file is behind composer.json, your project might not actually install the packages you think it will. That’s a recipe for bugs that are hard to trace, especially in production.
Failing early in CI ensures that your dependencies are exactly what you committed to - nothing more, nothing less.
2. It avoids misleading advice
The warning suggests you can simply run composer update to fix the mismatch. But unless you're deliberately updating all your dependencies, this is often bad advice.
Running composer update without constraints may introduce unintended package upgrades, which might either break other parts of the system, introduce regressions or complicate debugging.
By enforcing a clean lock file, you avoid needing to deal with this situation altogether.
By default composer validate will also check things like requiring a name or description in your composer.json. This is particularly useful for packages intended for public reuse. For regular web projects, we usually skip these extra rules - they don’t add much value in a project context. In practice, that means the validate of our CI pipeline runs this command:
composer validate --no-check-version --no-check-publish
To make sure this is in fact literally the same on all platforms, we add a wrapper script to composer.json, so we can simply run
composer ci:validate
If you have followed the parts so far, you should now have 2 CI jobs in your pipeline. Please see the below links for both jobs in all 3 major version control providers:
Direct link to pipeline for Bitbucket: https://bitbucket.org/eirikmorland/drupal-confidence/src/part-2/bitbucket-pipelines.yml
Direct link to pipeline for GitLab: https://gitlab.com/eiriksm/drupal-confidence/-/blob/part-2/.gitlab-ci.yml?ref_type=heads
Direct link to pipeline for GitHub: https://github.com/eiriksm/drupal-confidence/blob/part-2/.github/workflows/test.yml
When I was writing documentation for Drupal CMS’s SEO Tools recommended add-on (aka “recipe”), I realized that not all Drupal site users may be up-to-date on the essentials of SEO and how Drupal can help you make your site discoverable by your target audiences.
While Drupal has long been a solid foundation for building search-friendly websites — that doesn’t mean every Drupal user knows where to start with SEO.
In this post, I’ll define essential SEO concepts and highlight best practices direct from the documentation I wrote about promoting your site with SEO for the Drupal CMS User Guide.
Whether you're configuring a custom Drupal 11 site or using Drupal CMS, these tips apply to you. All of the tools mentioned below may be installed on any Drupal 11 site or installed via the SEO Tools recommended add-on in Drupal CMS.
Amber Matz Wed, 06/18/2025 - 14:41A few years ago, I quietly adopted a small principle that has changed how I think about publishing on my website. It's a principle I've been practicing for a while now, though I don't think I've ever written about it publicly.
The principle is: If a note can be public, it should be.
It sounds simple, but this idea has quietly shaped how I treat my personal website.
I was inspired by three overlapping ideas: digital gardens, personal memexes, and "Today I Learned" entries.
Writers like Tom Critchlow, Maggie Appleton, and Andy Matuschak maintain what they call digital gardens. They showed me that a personal website does not have to be a collection of polished blog posts. It can be a living space where ideas can grow and evolve. Think of it more as an ever-evolving notebook than a finished publication, constantly edited and updated over time.
I also learned from Simon Willison, who publishes small, focused Today I Learned (TIL) entries. They are quick, practical notes that capture a moment of learning. They don't aim to be comprehensive; they simply aim to be useful.
And then there is Cory Doctorow. In 2021, he explained his writing and publishing workflow, which he describes as a kind of personal memex. A memex is a way to record your knowledge and ideas over time. While his memex is not public, I found his approach inspiring.
I try to take a lot of notes. For the past four years, my tool of choice has been Obsidian. It is where I jot things down, think things through, and keep track of what I am learning.
In Obsidian, I maintain a Zettelkasten system. It is a method for connecting ideas and building a network of linked thoughts. It is not just about storing information but about helping ideas grow over time.
At some point, I realized that many of my notes don't contain anything private. If they're useful to me, there is a good chance they might be useful to someone else too. That is when I adopted the principle: If a note can be public, it should be.
So a few years ago, I began publishing these kinds of notes on my site. You might have seen examples like Principles for life, PHPUnit tests for Drupal, Brewing coffee with a moka pot when camping or Setting up password-free SSH logins.
These pages on my website are not blog posts. They are living notes. I update them as I learn more or come back to the topic. To make that clear, each note begins with a short disclaimer that says what it is. Think of it as a digital notebook entry rather than a polished essay.
Now, I do my best to follow my principle, but I fall short more than I care to admit. I have plenty of notes in Obsidian that could have made it to my website but never did.
Often, it's simply inertia. Moving a note from Obsidian to my Drupal site involves a few steps. While not difficult, these steps consume time I don't always have. I tell myself I'll do it later, and then 'later' often never arrives.
Other times, I hold back because I feel insecure. I am often most excited to write when I am learning something new, but that is also when I know the least. What if I misunderstood something? The voice of doubt can be loud enough to keep a note trapped in Obsidian, never making it to my website.
But I keep pushing myself to share in public. I have been learning in the open and sharing in the open for 25 years, and some of the best things in my life have come from that. So I try to remember: if notes can be public, they should be.
In March, Metadrop continued its contributions to the Drupal ecosystem with a particular focus on privacy and content editorial experience. The team released new modules, updated existing ones, added integrations, and assisted clients with some internal issues not directly related to Drupal, while still having time do research on AI.
We developed a new module to manage IFrame consent, ensuring GDPR-compliant handling of embedded iframes by loading third-party content only after obtaining user consent. This effort enhances privacy in addition to existing modules like EXIF Removal and Youtube Cookies.
The release of version 1.0.6 added date filters, enabling users to generate reports from previous months and display log statistics for the last month — an…
In this episode of Talking Drupal, we delve into the International Drupal Federation Initiative with our guest Tim Doyle, CEO of the Drupal Association. We explore the goals, structure, and potential impact of this initiative on the global Drupal community. Additionally, we cover the Modeler API as our module of the week, discussing its functionalities and future potential. Joining the discussion are hosts John Picozzi, Norah Medlin, Nic Laflin, and Martin Anderson-Clutz, who bring their insights and perspectives to the table.
For show notes visit: https://www.talkingDrupal.com/507
TopicsInternational Drupal Federation Initiative Recent DA Video Feature on The Drop Times ASBL
GuestsTim Doyle - Drupal.org Tim D.
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Norah Medlin - tekNorah
Module of the Weekwith Martin Anderson-Clutz - mandclu.com mandclu
The Modeler API provides an API for modules like ECA - Events, Conditions, Actions, Migrate Visualize, AI Agents, and maybe others. The purpose is to allow those modules to utilize modelers like BPMN.iO, (and maybe others in the future) to build diagrams constructed of their components (e.g. plugins) and write them back into module-specific config entities.