Introduction

Over the past few weeks, the Drupal community has been buzzing with discussions about the future of Drupal.

From Craftsmanship to Innovation: Why Drupal’s Future Lies in AI driven Open DXP

Just recently I read a really interesting blog post found in the Weekly Drop Newsletter called “Say No to Auto-Updates: Why Your Website Deserves Better Than Subscription Overhaul”. I appreciate articles that take a strong stance, and this one certainly does. However, I strongly disagree with its conclusions.

First, to get that out of the way. I actually do agree with two things 

• Updates should be tested (manually, automatically or both)
• An experienced developer carefully running the correct composer commands is always better than a bad automation

But that's where my agreement ends. Many of the points in the article are in what I would call the “general skepticism category”. This is fine, and at this point quite expected. While skepticism is healthy, data and real-world experience tell a different story. So instead of speculating (and me making counter arguments to the article), let’s look at some numbers shall we? I have some numbers. It’s these specific numbers: 3, 8, 58, 9768.

3: My personal and professional experience is with 3 services: Violinist.io, Renovate and Dependabot. For Drupal (and PHP / Composer) updates mentioned in the article I use violinist.io.  

8: I have been automating Drupal updates for 8 years.

58: Currently (at the time of writing) I have 58 personal and professional projects running Drupal (Composer) updates automatically. Most of these are automatically merged after passing tests.

9768: Over the last 8 years exactly 9768 commits have been added by an automatic updater to the 58 projects. 

Personally, I think the numbers speak for themselves. But let’s put it in perspective- try converting 9,768 commits into billable hours. Imagine the sheer amount of repetitive work automated away. You can speculate all you want - whether automation fails half the time (spoiler: it doesn’t) or if it’s actually a massive time-saver (it is). But at the end of the day, the results are undeniable.

So, while some debate the risks, I’ll be over here letting automation do what it does best - saving time and getting things done. Here is an animated gif from the days from long before all of these fancy package managers and automation tools.

I recently wrote about my experiences migrating this website from Drupal 7 to Drupal 10. In that post I said that I would write separately about my experiences theming the site. This is that post.

I was broadly happy with the look and feel of the Drupal 7 version of the site, so didn't want something vastly different. At the sametime, I wanted to make sure that I was using the most maintainable underlying code, behind what end-users see.

The Theming Spectrum: Base Themes

When it comes to theming a site, there is a spectrum. At one end of the spectrum, you build everything yourself. You write the HTML templates, using Twig from Drupal 8 onwards, that the site will use to render the content. You write all the CSS, laying things out, making sure they are responsive and designed for mobile devices first. At the other end of the spectrum, you pull an existing theme off the shelf, like the many excellent ones you can download from the Drupal website. (As I write, there are 3,190 themes on the Drupal website.)

In between those extremes, moving slightly more customised than starting with an off-the-peg theme, you can take an off-the-peg theme and create a subtheme where you tweak the things you want to change. CSS is easiest, allowing you to change fonts, margins, relative sizes, images, colours, and so on. But template tweaks are possible too.

But I'm most comfortable one level further of controlling things myself. I don't like to write everything myself — it's far too much work, and involves a lot of wheel re-invention. But I find customising someone else's theme constrains my ability to get things looking how I want. I've done that in the past, and end up changing colours and typeface but not a lot else; as soon as you want to move content around on the screen, things start to get messy.

So I like to start with a base theme. A base theme is one that does the heavy lifting for you by giving you lots of default HTML and sensible CSS, but that doesn't make assumptions about what you will want to do on your own site.

My dilemma was: Which base theme to use?

Use a stable theme, as far as you can.

Relatively few of the 260 actively maintained Drupal 10 themes are base themes.

Even fewer are stable.

One of the things I've learnt using earlier versions of Drupal is the importance of using themes that are actively maintained and will continue to be so. Too many times, I've customised a theme, only for the maintainer to wander off and stop updating it. I then have to choose a new base theme in order to keep moving through the versions of Drupal core. If I've customised a theme designed as a base theme, it means designing a new theme using that base theme as a starter. If I've tweaked a theme designed as a fully finished theme, it means swallowing the fact that the visual appearance of the site is going to have to change. Neither is great.

For example, in various previous versions of Drupal core, I've used:

• Omega. It was a very versatile base theme that was slightly further down the spectrum of doing things for you, but very capable with some great customisation tools. The maintainers started work on a Drupal 8 version of the theme, but never got one released. So, today, there are no releases available with current versions of Drupal core (Drupal 10 or 11). They got as far as 8.x-5.0-alpha7, and the project page says: “The current list of features for Omega Five is only a small sampling of the features available. This section will be updated with additional features and descriptions as it nears a stable release for Drupal 8.” Great in its day, but no more.
• Zen. Another very versatile theme. You have to do your customisations in code, rather than with the kind of UI you got with Omega, but I see that as a strength. Again, a workhorse of a base theme for me in Drupal 7. However the project page tells you the extra features you get with 7.x-6.x compared to 7.x-5.x, but no mention of the Drupal 8+ version. The most recent commit was in February 2021 (to help with getting things ready for Drupal 9), and the one before that was 3 years earlier. Sadly (because it was a great theme) it's also run out of steam.
• Pixture Reloaded. I loved this theme. It was more of a complete theme that you can recolour and adjust as you wish, but it was responsive and worked well. It was built on a base theme called Adaptive Theme. Back in the day, there were a good half dozen Adaptive Theme subthemes on the Drupal site. There was a website for Adaptive Themes where you could download any of them, or buy premium ones too. They offered a service to build a custom theme for your site. Sadly, none of this saw any releases beyond Drupal 7, and the Adaptive Themes website now just contains a domain-parking page.

You get the idea. Even since Drupal 8, there's been a whittling down. Just looking at themes that say they are actively maintained, and that have security team coverage, there are currently 210 themes that support Drupal 8, 181 that support Drupal 9, 162 that support Drupal 10, and 81 that support Drupal 11. So users of 129 of the 210 themes that support Drupal 8 are not able to move to Drupal 11, and nearly 50 of them can't use Drupal 10 either giving them no supported options. You'll recall that I'm using Drupal 10, not Drupal 11, because there are modules that haven't released Drupal 11 versions yet.

So as far as you can, try to find a base theme that is still being actively maintained. Look to see if code is still being committed. Look for two things in the issue queues. 1. Do the maintainers respond reasonably promptly? 2. Are there issues that have been stuck at "reviewed and tested by the community" for some time? If improvements / bug fixes have been tested, they should either be committed or moved to "won't fix" with a clear reason. Code stuck on RTBC is an amber flag in my book.

I also look for themes that are old. I don't want one that has just had its first release. I look for ones that have been around for several major versions of Drupal core, to demonstrate a maintainer who is active in moving it through the release cycles.

Bootstrap Barrio

My first attempt was a theme ecosystem named Barrio Bootstrap.

This is a really strong base theme. As the name suggests, it rewrites all of the Drupal templates to work within the Bootstrap framework. It is intended as a base theme. However, as you develop a sub-theme, it will help greatly if you can write your CSS using Sass; you get the benefits of the Sass mixins, you can use variables, and you can nest rules. There is a subtheme of Barrio Bootstrap called the Bootstrap 5 Sass Starter Kit. The maintainers recommend you extend that, rather than Barrio Bootstrap directly.

As I worked on site structure, I used the Sass Starter Kit unaltered. I think it was this that slightly put me off in the end. The fact I was able to use it out of the box means it made a lot of assumptions I'd want things coloured and laid out. As I came to start making the site look how I wanted it, it was harder work because I was editing to change inbuilt assumptions rather than working from scratch. I'm sure it can be quite intimidating to load an unaltered subtheme of a base theme, and to see just black text on white with no margins or borders between elements. However, if you're going to be using Chrome or Firefox developer tools to lay things out just how you want them, that is actually the best way to start and is going to be less work overall.

I was also slightly nervous that Barrio Bootstrap came with some colour editing tools in the UI. It wasn't immediately obvious where the theme saved the resulting CSS, or how that interfaced with the CSS that I had compiled myself from Sass. I found myself wishing all the configuration was in one place. If I was going to design a site myself, I don't want code potentially overwriting the CSS I've written; it could be hard to find where problems are coming from.

My final hesitation was the way it generates two CSS files, one with source links and one fully optimised. Shipping both, and changing which one is loaded in the theme's info file, felt clumsy. I'm sure to other people it feels really intuitive, but it didn't work for me.

So I looked to see what else was out there.

Radix

And I found the Radix base theme. The theme has a Drupal project page and a really good documentation site of their own. I am unclear what connection, if any, the Drupal theme Radix has with the wider Radix UI project. I suspect they're unrelated.

Unlike the Barrio family, this theme really is not designed to work on its own. In fact, it won't work properly. The theme ships with a starterkit for a subtheme, and sites will only render correctly if you have the elements from both a subtheme and the base theme in place. So your first step has to be to create your subtheme. Happily there are really good instructions for this on their website. I followed them, and everything just worked.

The more I use Radix, the more I like it as a base theme, and I can see this being my default base theme for future projects. Here are some of the things I like:

• It's well maintained. Development started in 2012, and the first non-beta release was for Drupal 7 in February 2014. That means it's an 11-year old project, with some continuity in the maintainers. The project has not one but three commercial organisations sponsoring development time, which is a great way to make sure things continue. (To give link-credit where it's due, those are Ramsalt Lab, Chapter Three, and O8). In February 2025 (last month), there were 10 commits to the 6.0.x branch. The latest release works with Drupal 10.3 and higher, and Drupal 11; it's current. The maintainers are really responsive in the issue queue. I've found a couple of (small) bugs or ways to improve, and they've been really proactive picking up merge requests and helping me improve what I was proposing so they can commit the changes. That's a really refreshing experience that encourages collaboration.
• It uses single-directory components. Once you get the hang of it, it's a great way to maintain a theme's code. There is a component directory for everything: headers, menus, nodes, pages, comments, and so on. The theme simply inherits the twig and CSS from the base theme unless you decide you want to override a specific component. It makes it easy to find any code you've changed; as long as you've used the component directory structure consistently, those changes will be exactly where you'd expect.
• There's a great CLI tool for creating components, called drupal-radix-cli. It can bring across a component from the base theme and create the directory in your subtheme for you, and it can also create a brand new component if you want it to.
• It uses Sass, and you can easily compile your CSS in either development or release mode. The former is ideal for seeing where particular lines of CSS come from so you can fix things; the latter is fully minimised and ready for production. I develop in development mode (npm run watch), then compile in release mode (npm run production) before I commit a series of changes to git. That keeps the git commit noise down, and means staging and production environments only ever pull the production-ready styling.
• It works with BrowserSync. Now, in fairness, Barrio Bootstrap can do something similar, but Radix does it out of the box. If you run npm run watch, a web server starts running on a port in the 3000s that will render a copy of your site showing the most current layouts. Any time you make a change to the source .scss or template files, the CSS is automatically recompiled and a signal sent to your browser to reload. So you can tweak things like margins and colours and watch the effects in near real-time. I don't develop on my local machine, so I had to open the requisite ports through my development server firewall, but other than that this is a really easy way to work on a site's appearance.
• It also uses Bootstrap; Barrio isn't the only way to get access to Bootstrap. Because this really is a base theme, you don't get a site that shouts visually "I was built with Bootstrap" unless you want that. But you get all the access to HTML classes to adjust things like margins, grid layouts and forms. You also get an easy way to make many adjustments using Bootstrap variables, as I'll discuss below. It means a really well-planned framework is behind the theme, so you get all those benefits, whilst giving you genuine freedom to control what your site looks like.

Tips for Working with Radix

As I've built a theme with Radix, I've learnt a few lessons along the way that are worth sharing.

• Keep track of changes.
  • Your subtheme contains a copy of all the templates from the base theme, so the subtheme/templates folder contains a mixture of original and altered templates.
  • Your subtheme contains only those components that you've chosen to override (or create), so the subtheme/components folder contains only your alterations.
  • When you update the Radix base theme to a new version, you'll want to know what changes affect components or templates you've altered.
  • Having created my subtheme, I create copies of the components and templates folders of the base theme at the time I created my subtheme.
    cp -ar ../../config/radix/src/kits/radix_starterkit/templates ./.templates.orig
cp -ar ../../config/radix/components ./.components.orig
  • Then you can use diff -urq to compare templates / components in the new Radix version with .templates.orig / .components.orig in your subtheme.
  • You can then carefully test bringing those changes across to the subtheme before updating your .templates.orig / .components.orig folders so they're ready as reference points for the next base theme update.
• Link to components from templates.
  • When you create a component (deriving from a base template one, or generating a new one), your webpage won't automatically pick it up. That's possible to forget if your template uses custom twig, but very easy to forget if your template just contains CSS.
  • Your subtheme will use the templates in the templates folder to work out what HTML to render. The templates folder in the Radix theme is intentionally thin; most of the templates simply insert the HTML generated by a component, and let the components folder do the heavy-lifting. This helps keep your theme maintainable. Throughout the templates folder, you'll see code like this: {% include "radix:page-title" %}. That tells the theme engine to include the output from the page-title component within the radix theme.
  • The key thing is that all the templates embed the output of the radix components. Your custom component will not be included unless you change the template that calls it from {% include "radix:page-title" %} to {% include "your_subtheme:page-title" %}. As I say, it's easy to forget.
• Whenever you change a template, you should clear the caches on your site.
  • Drupal will often cache templates.
  • If your working on theme development, you should always go to Home > Administration > Configuration > Development and check the box labelled "Do not cache markup".
  • However I've found that can still cache templates themselves, so running drush cr after a template change can help ensure those changes appear on the site.
• Whenever you introduce new components that mean you have new CSS files appearing, you need to restart your laravel mix process.
  • When you first run npm run watch, the process seems to read all the files that need watching for changes.
  • If you change those files, the CSS will rebuild and the page will reload.
  • If you add a custom component that means an extra CSS file should be included in the page, this won't be picked up. You need to Ctrl+C, and run npm run watch again.
• Use Bootstrap variables wherever possible.
  • As you start tweaking your site, you'll want to adjust margins, colours, font sizes and so on.
  • It's really tempting to write lines of scss in the components to do this for you, and that is often the right thing to do.
  • But don't forget that Bootstrap is a really powerful framework. It has a lot of variables set to sensible defaults for these things.
  • Sometimes, instead of writing custom CSS to adjust how things look, it's far better to set one Bootstrap variable to a new value, and the change is made for you in a way that is consistent.
  • Within your subtheme folder is a folder named node_modules, within that is a folder named bootstrap/scss, within that is a file named _variables.scss. At this point grep is your friend. Find the variable you want to change, and go to src/scss/base/_variables.scss within your subtheme. Set the variable you want.
  • For example, I wanted to stop <a> tags from underlining. Rather than writing a { text-decoration: none; } in the scss of a component, all I needed to do was enter $link-decoration: none; in my _variables.scss file

Sidebars

One thing I noticed straight away was that Radix doesn't give you sidebar regions for placing blocks.

I was tempted to feel grumpy and move on to look for another base theme, but then I realised this is deliberate and a good thing. Not every site uses sidebars. So let those sites that want them add them, and let those that don't have leaner mark-up.

It turns out it's easy to add sidebars. Given this isn't a requirement for everyone, but because it will be quite a common wish, I'll write that up in a separate post. Watch this space!

Imagine waking up to discover that overnight, AI agents rewrote 500 product descriptions, reorganized 300 pages for SEO, and updated 9,000 alt-text descriptions on your website.

As you review the changes over coffee, you find three product descriptions featuring nonexistent features. If published, customers will order based on false expectations. Then you notice another problem: AI rewrote hundreds of alt-text descriptions, erasing the ones your team crafted for accessibility.

AI-driven content management isn't a distant scenario. Soon, Content Management Systems (CMS) may deploy hundreds of AI agents making bulk edits across thousands of pages.

The challenge? Traditional CMS workflows weren't designed for AI-powered editing at scale. What features should an AI-first CMS include? What safeguards would prevent errors? What workflows would balance efficiency with quality control? I'm outlining some rough ideas to start a conversation and inspire Drupal contributors to help build this future.

1. Smart review queues: scaling human oversight

AI-generated content needs different quality checks than human work. Current editorial workflows aren't optimized to handle its output volume.

I envision "AI review queues" with specialized tools like:

• Spot-checking: Instead of manually reviewing everything, editors can sample AI content strategically. They focus on key areas, like top-selling products or pages flagged by anomaly detection. Reviewing just 5% of the changes could provide confidence; good samples suggest the broader set works well. If issues are found, it signals the need for deeper review.
• Rolled-up approvals: Instead of approving AI edits one by one, CMS platforms could summarize large-scale AI changes into a single reviewable batch.

2. Git-like content versioning: selective control over AI changes

Say an AI translated your site into Spanish with mixed results. Meanwhile, editors updated the English content. Without sophisticated versioning, you face a tough choice: keep poor translations or roll everything back, losing days of human work.

CMS platforms need Git-like branch-based versioning for content. AI contributions should exist in separate branches that teams can merge, modify, or reject independently.

3. Configuration versioning: keeping AI from breaking your CMS

AI isn't just generating content. It is also modifying site configurations, permissions, content models and more. Many CMS platforms don't handle "configuration versioning" well. Changes to settings and site structures are often harder to track and undo.

CMS platforms also need Git-like versioning for configuration changes, allowing humans to track, review, and roll back AI-driven modifications just as easily as content edits. This ensures AI can assist with complex site management tasks without introducing silent, irreversible changes.

4. Enhanced audit trails: understanding AI decisions

Standard CMS audit logs track who made changes and when, but AI operations demand deeper insights. When multiple AI agents modify your site, we need to know which agent made each change, why it acted, and what data influenced its decision. Without these explanations, tracking down and fixing AI errors becomes nearly impossible.

AI audit trails should record confidence scores showing how certain an agent was about its changes (60% vs 95% certainty makes a difference). They need to document reasoning paths explaining how each agent reached its conclusion, track which model versions and parameters were used, and preserve the prompt contexts that guided the AI's decisions. This comprehensive tracking creates accountability in multi-agent environments where dozens of specialized AIs might collaborate on content.

This transparency also supports compliance requirements, ensuring organizations can demonstrate responsible AI oversight.

5. AI guardrails: enforcing governance and quality control

AI needs a governance layer to ensure reliability and compliance. Imagine a healthcare system where AI-generated medical claims must reference approved clinical studies, or a financial institution where AI cannot make investment recommendations without regulatory review.

Without these guardrails, AI could generate misleading or non-compliant content, leading to legal risks, financial penalties, or loss of trust.

Instead of just blocking AI from certain tasks, AI-generated content should be checked for missing citations, regulatory violations, and factual inconsistencies before publication.

Implementing these safeguards likely requires a "rules engine" that intercepts and reviews AI outputs. This could involve pattern matching to detect incorrect content, as well as fact verification against approved databases and trusted sources. For example, a healthcare CMS could automatically verify AI-generated medical claims against clinical research databases. A financial platform might flag investment advice containing unapproved claims for compliance review.

Strategic priorities for modern CMS platforms

I can't predict exactly how these ideas will take shape, but I believe their core principles address real needs in AI-integrated content management. As AI takes on a bigger role in how we manage content, building the right foundation now will pay off regardless of specific implementations. Two key investment areas stand out:

1. Improved version control – AI and human editors will increasingly work in parallel, requiring more sophisticated versioning for both content and configuration. Traditional CMS platforms must evolve to support Git-like branching, precise rollback controls, and configuration tracking, ensuring both content stability and site integrity.
2. AI oversight infrastructure – As AI generates and modifies content at scale, CMS platforms will need structured oversight systems. This includes specialized review queues, audit logs, and governance frameworks.

Taking your first steps with Drupal? No matter your professional role, your journey with Drupal will be full of exciting discoveries. One of them is an outstanding community of passionate, fun, and brilliant people who love sharing their expertise. Once you experience how it feels to be part of it, you’ll never want to seek a different platform.  

This community is gathering soon for the biggest Drupal event of the year. Mark your calendar for 24-27 March and prepare to immerse yourself in the vibrant Drupal universe in Atlanta, Georgia. You’ll make new friends, hear about the latest Drupal trends from top Drupal creators, and find answers to your questions. With beginner-friendly sessions, hands-on workshops, and a welcoming atmosphere, you’ll gain the needed confidence and knowledge. 

Need some tips for preparing for the event and maximizing your experience? Check out “A First Time Attendees Guide to DrupalCon Atlanta 2025” which includes plenty of them. Once you’ve got the essentials covered, it’s time to plan your schedule. DrupalCon’s program is packed with insightful sessions. In this article, we’ll spotlight the best ones to help you kick off your Drupal experience.

Top sessions for newcomers at DrupalCon Atlanta 2025

New Member + Local Drupal Community Meetups and Meeting Spaces

It’s no surprise that the open and welcoming Drupal community offers special events for new members. They serve two key purposes: bringing in new people and strengthening local Drupal communities.

• New Member + Local Drupal Community Meeting Space is designed for new Drupal community members (that’s you) to meet their local Drupal camps, associations, and community groups. With designated ambassadors leading the way, this creates a welcoming and collaborative environment. The space is open 8.00-17.00 Monday through Thursday. Meet new friends and enjoy DrupalCon together!
• New Member + Local Drupal Community Meet Up is a casual and friendly gathering, meant to break the ice before the Welcome Party and other sessions. Several instances of these meetups are already in the schedule, and there may be more to come.

By attending, you get a fantastic chance to ease into the experience, meet new people, and build relationships that will make your time at the conference especially enjoyable. What’s more, these connections could extend beyond the event itself.

Getting to know your local Drupal community offers yet another fantastic benefit: it may motivate you to attend local events in the future. While smaller than DrupalCon, these gatherings are still incredibly valuable for both learning and networking.

“Finding Your Path to Drupal: How Three Unique Journeys Led to Meaningful Careers in Web Development” — by Nagat Ahmed, Lynda Santiago, Amani Mansour

It’s amazing how different paths can all lead to Drupal. Want to discover some inspiring stories about people from diverse backgrounds finding their way into the Drupal world? Then the following panel discussion by Nagat Ahmed (nagatahmed), Lynda Santiago (lyndasantiago), and Amani Mansour (amani.mansour92) is for you.

It brings together three developers who took very different roads into web development — one started as a stay-at-home parent, another worked in the conflict resolution sphere, and the third attended a coding bootcamp. Despite their different starting points, they all built successful careers in Drupal.

The speakers will cover the obstacles they faced, the skills they developed along the way, and how Drupal opened doors to exciting opportunities. But it’s not just about learning to code — each panelist will also share how their previous experiences gave them unique perspectives and non-technical skills that made them successful developers on their teams.

This session will show you that there’s no single path to success in web development. No matter where you come from, there’s a place for you in Drupal. And if you’ve ever struggled with self-doubt or imposter syndrome, this talk may help you overcome those barriers and take the next step in your Drupal journey.

Networking Area for Drupal Attendees

Networking is a key component of every Drupal event, and it’s especially valuable for new members. That’s why DrupalCon offers so many opportunities to connect. The Networking Area for Drupal Attendees is the perfect space to meet and engage with fellow Drupal enthusiasts.

This space is designed to help you participate in meaningful conversations in a relaxed setting. Chat with developers, project managers, designers, and community leaders, share your experiences, and maybe even find your next collaboration opportunity or a mentor to support you as you grow in Drupal.

The Drupal community thrives on connection and knowledge-sharing. Don’t hesitate to stop by, introduce yourself, expand your network, and who knows — this might be the start of something great.

“Drupal CMS now and beyond” — by Pamela Barone and Cristina Chumillas

If you’re new to the Drupal world, you absolutely need to learn about one topic you’ll hear a lot about: Drupal CMS (also known as Starshot). This exciting new version of Drupal is changing the way websites are built and managed, making it easier for non-technical users to create powerful website functionalities without needing to write any code. It is built on top of traditional Drupal core and exists alongside it.

Drupal CMS 1.0 made its debut on January 15, Drupal’s 24th birthday, and the community is now buzzing with excitement about what’s next. Here is a session to discover the details. It will be led by Pamela Barone (pameeela) and Cristina Chumillas (ckrina), top Drupal contributors and part of the amazing team of Drupal CMS creators.

The speakers will dive into the ongoing development of Drupal CMS. You’ll be introduced to the plans for future versions, the features currently in progress, what has been built so far, what lessons have been learned, and how the strategy defines the roadmap.

This session will also offer you a chance to appreciate the strength of the Drupal community, as the speakers share how it united to build Drupal CMS. You’ll get to know how anyone, including newcomers, can contribute, as all types of contributions are welcome.

“Recipes: It's About Time!” — by Martin Anderson-Clutz

Another exciting Drupal innovation that makes website creation faster and more efficient is Recipes. With Recipes, even non-technical users can add feature sets — like blog functionality, event management, and SEO capabilities — simply by clicking a button. For developers, Recipes offer a way to package features following best practices.

In this session by Martin Anderson-Clutz (mandclu), a leading Drupal contributor, will demonstrate how Recipes work, focusing on the Events recipe. This pre-packaged solution allows you to instantly add event functionality to your site. It includes everything you need: a content type for events, fields for start and end dates, duration, location with integrated Google Maps, and more. You’ll see the Events recipe and its add-ons in action during the session.

Recipes are one of the key building blocks of the earlier-mentioned Drupal CMS (Starshot). Martin will show the built-in capabilities and the options to extend them. However, Recipes are not limited to Drupal CMS but are also available in traditional Drupal core, so Martin will explain how to add the same features to “classic” Drupal websites as well.

If you're a fan of live demos, this session is for you — by the end, you'll know exactly how to enhance your website with features from the Events recipe or other Recipes.

“Experience Builder is coming. Are you ready?” — by Lauri Timmanee

Be sure to catch a session on yet another gem in Drupal’s growing collection of innovations. While Drupal has seen many page layout tools over the years, a next-generation page builder is now in the works — one that promises to redefine the process.

Experience Builder is designed to bring together best practices while introducing game-changing capabilities. It will make creating and customizing pages easier and more efficient than ever before.

With Experience Builder, marketing teams can design and theme entire websites directly in their browser, without needing advanced technical skills beyond basic HTML, CSS, and templating markup. Content creators will have more freedom, too — they’ll be able to compose and edit content anywhere on the page, without waiting for developer support.

In this session, initiative leader Lauri Timmanee (lauriii) will walk you through how Experience Builder works. You’ll see this exciting tool in action with a live demo, with a step-by-step walkthrough of how websites will be built with it. Plus, you’ll also get a sneak peek at what’s coming next, beyond the initial release. 

Driesnote by Dries Buytaert

While there are so many sessions around exciting features and great practices, there is one you absolutely cannot miss. In just one keynote, you’ll get a front-row seat to the best of Drupal — its core values, the latest developments like Experience Builder, Recipes, and AI-powered tools, and an exclusive look at what’s ahead. Driesnote often unveils game-changing innovations and future plans before they’re shared anywhere else.

But Driesnote is more than just a session packed with insights — it’s where you truly feel the heartbeat of Drupal. Dries Buytaert, the founder of Drupal, has a unique way of inspiring the audience, making everyone proud of Drupal’s progress and excited to be part of its thriving community. He’ll likely highlight the people driving Drupal forward.

You’ll leave with a deeper understanding of how Drupal is evolving and how you can be part of its future, no matter your background or experience level.

Contribution workshops for beginners

One of the greatest strengths of open-source communities is that anyone can contribute to the platform. In Drupal, contributions are not only rewarding but also recognized — contributors earn credits on drupal.org and respect from the community.

Even if you're new to Drupal, you can make an impact alongside seasoned experts. No contribution is too small, and there’s a wide range of tasks for every skill level. Plus, contribution isn’t just about coding — there are plenty of ways to get involved as a designer, QA specialist, marketer, content editor, and so on.

At DrupalCon, you’ll have the perfect opportunity to kick off your contribution experience in a welcoming and supportive environment. Special sessions are designed to guide you through the process:

• 1st Time Contribution Workshop is ideal for those who have never contributed to Drupal before. You’ll get a step-by-step introduction to the contribution process, including how to navigate drupal.org, find beginner-friendly tasks, and collaborate with the community. There are several instances of this workshop.
• Mentored Contribution session is open to everyone — whether you’re brand new or already a little familiar with contributing. You’ll join experienced contributors and maintainers to work on real issues, ask questions, and gain hands-on experience while making a meaningful contribution to Drupal.

Final thoughts

Let DrupalCon 2025 give a great start to your exciting path in the Drupal world — one where learning, growth, and opportunity await at every turn. The warm embrace of the Drupal community, paired with beginner-oriented sessions, will give you the foundation you need to feel confident, supported, inspired, and energized. Who knows — one day, you might find yourself on stage at the biggest Drupal event, inspiring others!

Ecommerce businesses require a robust, scalable, and customizable solution to meet evolving customer needs. Many struggle with rigid platforms, high operational costs, and security concerns, limiting their growth potential. Drupal Commerce provides an open source, flexible, and feature-rich solution that empowers companies to create tailored ecommerce experiences with full control over functionality and scalability.

As a Champion sponsor, we’re proud to support the Drupal community and contribute to the success of this event. Our team is ready to share insights, and help shape the future of Drupal.