Drupal effectively has two default administration themes: Claro for core, and Gin for Drupal CMS. This causes difficulty for UX designers and product managers, because new features must work well with both themes.
Gin is no longer an experimental fork of Claro to experiment with new ideas. It has matured into a state-of-the-art admin theme, while Claro has fallen behind, as evident by the decision to use Gin as the admin theme for Drupal CMS. As a result, we feel it is time for Gin to become the default theme for Drupal core.
We are aspiring to have this work completed by November 2025 in order to get Gin into core for the release of 11.3 in December.
A core-ready version of Gin will be developed outside of core in a 6.x branch of Gin. Our goal is for the Gin maintainers to collaborate with the Drupal Core Product, UX, Release, and Frontend Framework Managers to identify which issues are blockers for Gin in core.
Once the identified blockers are completed, the result would be merged into core for Drupal 11.3 by the beta deadline in November 2025. The most important step for including Gin in core is to remove its dependency on Claro, since Gin will replace Claro as the default admin theme.
Other work will include removing features that are not needed for core; simplifying the code now that Gin only needs to support the version of core that includes it; and other tasks like adding necessary test coverage to ensure a smooth transition from contrib to core.
Although Claro will not be the default theme anymore for new sites, it will remain in Drupal 11 for use on existing sites. Claro is planned to be removed from core in Drupal 12, at which point it may become available as a contributed theme outside of core.
This is a big job with an ambitious timeline, so we will need many contributors to meet it. For contribution, you can get started with the two meta issues (#3530849 Gin 6.x and #3530852: Admin theme modernisation) to track this work, one for core tasks and one for Gin tasks. These will be updated and many new tasks created as the scope of work is clarified.
The Gin maintainers are also seeking sponsors for their time, which is a great way to contribute to this effort if you want to see this happen but are not able to work on tasks directly.
All those interested, please join us in the #admin-ui Drupal Slack channel for collaboration.
I’m resharing my recent interview with The Drop Times about my platform for the Drupal Association 2025 Board Election because I want to give our community a clear look at where I stand, what I believe Drupal needs next, and how I’d approach my role if elected to the Drupal Association Board. From making events and contribution pathways more inclusive to strengthening Drupal’s brand while reaching new audiences, I hope these ideas spark conversation and reflect the practical, community-first mindset I’d bring to the board.
Voting is now open and will be until July 11 23:59 UTC. You need to have been a Drupal Association Ripple Maker 24 hours before voting opened on June 18 in order to be eligible to vote. Ripple Makers be sure to look out for the email from the Drupal Association with your voter id, password and instructions.
Below you will find my interview with Ben Beter of the DropTimes and my vision for the future of Drupal:
1. You’ve welcomed 40% of attendees from outside Drupal at EvolveDrupal—what concrete steps would you take as a board member to ensure that those first-time or non-technical participants feel empowered to contribute beyond in-person events?
What we’ve seen at EvolveDrupal is that getting someone through the door is only step one. A good event might spark someone’s interest—but what they really need afterward are clear, approachable next steps.
If I were on the board, I’d push for things like regular beginner-friendly webinars, ideally led by agency folks who can break things down in a way that’s not intimidating. I’d also love to see more storytelling—hearing from people who work in marketing, UX, content, etc., who are already using Drupal, so newcomers can actually see themselves in this space.
On the practical side, we could build out a non-technical contributor guide on drupal.org. Right now, the site is very developer-focused, and it’s not always easy for someone from a design or communications background to know where they fit in.
I’d also like to see a post-event “what’s next” guide—a simple follow-up email with curated links, a breakdown of contribution options, and how to join the community or a working group. And at events like Digital Collegium or Educause, the DA should absolutely have a presence. These are the types of places where we can reach non-technical people who are using—or could use—Drupal every day.
2. Running events in six North American cities post-pandemic showed incredible momentum. How would you advise the Drupal Association to scale that model globally, balancing centralized strategy and local autonomy, without diluting what makes each gathering unique?
I think the key is to support, not control. What made EvolveDrupal work is that we kept things lightweight, flexible, and community-focused. The DA could definitely help other organizers by offering a basic playbook—just something that outlines what’s worked for us, especially around getting non-Drupal folks in the door, and tips for outreach and sponsorship.
Templates, branding assets, or just having a shared doc of what speakers or formats worked well—that would go a long way. But at the end of the day, each region should have the freedom to do what fits their audience. What works in Ottawa might not land in Lagos or São Paulo—and that’s okay.
Also, the DA could make a real difference by offering even small sponsorships or in-kind support—like signal boosts, intros to speakers, or even just showing up. And there’s already an event organizer group—I'd love to connect more with that crew and share what we’ve learned.
Lastly, I think it would be really helpful to build a community of practice—just a way for organizers around the world to share ideas, speakers, and lessons learned. That way, we keep the energy up without trying to clone the same event everywhere.
3. You aim to be a voice for marketers, designers, and communicators. What is one current board decision or policy that you believe doesn’t adequately engage non-technical contributors, and how would you address that imbalance if elected?
Honestly, I think a lot of DA programs are still geared toward developers. Even something like the "Ripple Maker" term—it’s clever, but it doesn’t really speak to folks in marketing or comms. And while I do think the Drupal.org rebrand was a great step forward, we’re still missing content that’s actually tailored to non-technical people.
For example, Supporting Partner benefits mostly focus on things like commit credits and developer recognition. If I were on the board, I’d push to also highlight contributions in areas like accessibility, UX, design systems, and community outreach.
We also need to be more present in non-Drupal spaces—but not just with a booth. Booths are fine, but what matters is what happens at them. If we show up to conferences like Educause or HighEdWeb, we should be doing live demos, sharing case studies, and talking to people on their terms. That part is often missing.
Another thing: we should ask agencies to help spread the word. I know GDPR limits how we share contact info, but we can still create referral-friendly content, like newsletter templates or event invites that agencies and end-user organizations—like universities—can pass on internally.
I also think DrupalCon could do more to intentionally invite marketers. Maybe a marketing track, or something like a dedicated Marketing & Comms Summit, just like we do for government or higher ed. And, of course, keeping event prices low is key to getting more diverse voices in the room.
4. Your growth of EvolveDrupal into EvolveDigital signals openness beyond Drupal. In the context of the Promote Drupal initiative, how would you ensure Drupal maintains brand identity and technical depth while engaging broader audiences and digital disciplines?
EvolveDigital isn’t about stepping away from Drupal—it’s about making space for the broader ecosystem around it. The reality is, Drupal doesn’t exist in a vacuum. It’s always used alongside other tools and strategies. So rather than trying to wall it off, we should lean into that and show how Drupal fits into modern digital teams.
I think Promote Drupal can support this with a two-track approach:
We should also make sure that people from these roles are involved early in the process—not just reviewing messaging, but helping shape it.
At the end of the day, I don’t think widening the conversation weakens Drupal’s brand. If anything, it shows how versatile and future-proof it is. We just need to get better at telling that story to all the right people.
ConclusionIf I were on the board, I’d focus on helping Drupal grow beyond its current edges—by making the project more welcoming to non-technical contributors, easier to access for new users, and more visible to sectors that don’t yet realize how much Drupal can offer. My experience organizing EvolveDrupal (now EvolveDigital) has shown me what’s possible when we create spaces that are inclusive, cross-functional, and community-powered. I’d bring that same mindset to the DA—supporting meaningful events, clearer contribution pathways, and smarter communication that reflects the full diversity of our ecosystem.
In short, if elected, I would:
I’m excited about what’s ahead for Drupal—and I’d love to help shape that future from a place of inclusion, energy, and practical momentum.
If my vision resonates with you, I’d be honoured to have your support in this election.
+ more awesome articles by Evolving WebIn 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.