I’ve been part of the Drupal community for nearly twenty years, contributing as a former Drupal Association Board member, founder and Chair of Drupal Colorado, organizer of DrupalCamp Colorado, speaker, mentor, volunteer, and advocate. Professionally, I work at the intersection of technology, strategy, and community. Today I’m AI Ambassador at amazee.io, where I help organizations explore responsible open source AI and contribute to the Drupal AI Strategic Initiative. Before that, I spent nearly a decade at Pfizer leading enterprise digital platforms, global web strategy, and AI initiatives. Beyond my professional work, I’m a passionate advocate for neuroinclusion, accessibility, and universal design. As someone who is autistic, has ADHD, and dyslexia, I believe our strongest communities are the ones that welcome different perspectives and different ways of thinking. Whether I’m organizing an event, mentoring a new contributor, speaking at a conference, or serving on a nonprofit board, my goal is always the same: leave Drupal stronger than I found it and help create opportunities for the next generation of contributors. If you’d like to learn more about my background and contributions, you’ll find additional details on my Drupal.org profile.
For me, Drupal started as software, but it evolved into community.
If Drupal disappeared tomorrow, I’d still have some of my closest friends, mentors, and confidants because of the relationships this project has created. That’s how I know community is the most enduring thing we’ve built together.
Building community isn’t just about attracting new people. It’s about creating an environment where they feel welcome, where they can learn, contribute, grow into leadership, and eventually help the next generation do the same.
Over the past twenty years, I’ve tried to contribute to that in whatever way I could: organizing DrupalCamp Colorado, helping found the Event Organizers Working Group, serving on the Drupal Association Board, mentoring first-time speakers, advocating for neuroinclusion, contributing to the Drupal AI Initiative, and simply making time for people who are looking for a place to belong.
Strong communities don’t happen by accident. They require stewardship, empathy, and a willingness to invest in people for the long term. When we build systems that help people succeed, we don’t just strengthen the community, we strengthen Drupal itself.
Advocating for Drupal means helping people see not only what Drupal is today, but what it can become.
Sometimes that means introducing someone to Drupal for the first time. Sometimes it means helping an organization adopt Drupal or contribute back to the project. Increasingly, it means representing Drupal in conversations far beyond our own community.
Over the past year, I’ve had the opportunity to speak about Drupal and open source in places where Drupal hasn’t traditionally had a voice, including AI conferences, international open source events, and United Nations Open Source Week. Those conversations reinforced something I’ve believed for a long time: Drupal has an important story to tell, but we need to be telling it more often and to more audiences.
Advocacy also means being honest. It means celebrating what makes Drupal exceptional while also recognizing that we face real challenges. The technology landscape is changing rapidly. Open source is evolving. Communities have new expectations. If we want Drupal to thrive for the next twenty years, we need to be willing to innovate while remaining true to the values that have always defined us: openness, collaboration, inclusion, and community.
For me, advocating for Drupal means showing up, listening carefully, building bridges, and helping ensure that Drupal continues to be a project the world looks to as a leader in open source.
I’m running because I believe Drupal is at one of the most important moments in its history.
We’re navigating enormous opportunities through AI, changing expectations around open source, and an increasingly challenging economic environment. At the same time, many members of our community are asking an important question: “Is anyone listening?”
I believe they deserve to be heard.
The Drupal Association exists to serve the project and its community. That means more than delivering programs and organizing events. It means listening carefully, communicating transparently, and ensuring that contributors feel they have a meaningful voice in the future of Drupal.
Over the past year I’ve worked to help move Drupal forward through the Drupal AI Initiative, advocacy, training, mentoring, and community building. Those experiences have reinforced something I’ve believed for a long time: our greatest strength isn’t our technology alone. It’s the people who choose to invest their time, talent, and trust in this project.
If elected, I’ll work to strengthen that trust by helping build a Drupal Association that is financially resilient, forward-looking, and deeply connected to the community it serves. I want contributors to know that their voices matter, that their concerns are heard, and that together we’re building a stronger future for Drupal.
That’s why I’m running.
I bring a combination of experience that I believe is particularly valuable for the Drupal Association at this point in its history.
I’ve served on the Drupal Association Board before, chaired its Governance Committee, and helped shape governance changes that continue to guide the organization today. Beyond Drupal, I’ve spent nearly two decades serving on nonprofit boards and understand both the strategic responsibilities and fiduciary duties that effective governance requires.
I’m also deeply engaged in Drupal’s future. Through the Drupal AI Strategic Initiative, my work as AI Ambassador at amazee.io, community training, speaking, and mentoring, I’ve been helping contributors understand and adopt new technologies while staying true to Drupal’s values of openness, transparency, and collaboration.
At the same time, I remain connected to the grassroots community. I’ve helped lead DrupalCamp Colorado for nineteen years, continue to mentor new contributors and speakers, and believe some of the best ideas for Drupal begin in our local communities.
Finally, I bring experience from outside our ecosystem. After nearly a decade leading enterprise digital platforms and AI initiatives at Pfizer, I understand the challenges and expectations of the organizations that choose Drupal. That perspective helps bridge the needs of enterprise users with the values that make Drupal unique.
Experience and vision matter. But leadership is ultimately measured by showing up, especially when the work is hard. I’ve tried to do that consistently for nearly twenty years: listening, building, mentoring, organizing, and helping leave this community stronger than I found it. If you choose to place your trust in me again, that’s exactly how I’ll serve on the Drupal Association Board.
My favourite Drupal memory goes all the way back to DrupalCon Barcelona in 2007.
I had just joined a Drupal agency, and my connection to the community was still very small. I’d been to a few local meetups when one of the founders asked, “Do you have a passport? Would you like to go to Barcelona?” My answer was an immediate, “Yes!”
There were only about 430 people at that DrupalCon, and for the first time I found myself surrounded by the people whose names I’d been seeing in the issue queues and documentation. I met Dries Buytaert, Moshe Weitzman, Karoly “chx” Negyesi, Morten Birch Heide-Jørgensen (MortenDK), Gábor Hojtsy, Jeff Eaton, Merlin of Chaos, Angie “webchick” Byron, and so many others who were shaping Drupal’s future.
What struck me wasn’t that they were influential. It was that they were approachable. They welcomed questions, shared ideas freely, and treated a newcomer like I belonged there.
That experience changed the trajectory of my career. It showed me that Drupal wasn’t just exceptional software. It was an exceptional community. Looking back, I think that’s the moment I stopped being someone who used Drupal and started becoming someone who wanted to help build Drupal.
Today, one of my favourite parts of every DrupalCon is welcoming someone who’s attending for the first time. Twenty years ago, the community made room for me. Ever since, I’ve tried to do the same for others.
I’ve been part of the Drupal community for nearly twenty years, contributing as a former Drupal Association Board member, founder and Chair of Drupal Colorado, organizer of DrupalCamp Colorado, speaker, mentor, volunteer, and advocate. Professionally, I work at the intersection of technology, strategy, and community. Today I’m AI Ambassador at amazee.io, where I help organizations explore responsible open source AI and contribute to the Drupal AI Strategic Initiative. Before that, I spent nearly a decade at Pfizer leading enterprise digital platforms, global web strategy, and AI initiatives. Beyond my professional work, I’m a passionate advocate for neuroinclusion, accessibility, and universal design. As someone who is autistic, has ADHD, and dyslexia, I believe our strongest communities are the ones that welcome different perspectives and different ways of thinking. Whether I’m organizing an event, mentoring a new contributor, speaking at a conference, or serving on a nonprofit board, my goal is always the same: leave Drupal stronger than I found it and help create opportunities for the next generation of contributors. If you’d like to learn more about my background and contributions, you’ll find additional details on my Drupal.org profile.
For me, Drupal started as software, but it evolved into community.
If Drupal disappeared tomorrow, I’d still have some of my closest friends, mentors, and confidants because of the relationships this project has created. That’s how I know community is the most enduring thing we’ve built together.
Building community isn’t just about attracting new people. It’s about creating an environment where they feel welcome, where they can learn, contribute, grow into leadership, and eventually help the next generation do the same.
Over the past twenty years, I’ve tried to contribute to that in whatever way I could: organizing DrupalCamp Colorado, helping found the Event Organizers Working Group, serving on the Drupal Association Board, mentoring first-time speakers, advocating for neuroinclusion, contributing to the Drupal AI Initiative, and simply making time for people who are looking for a place to belong.
Strong communities don’t happen by accident. They require stewardship, empathy, and a willingness to invest in people for the long term. When we build systems that help people succeed, we don’t just strengthen the community, we strengthen Drupal itself.
Advocating for Drupal means helping people see not only what Drupal is today, but what it can become.
Sometimes that means introducing someone to Drupal for the first time. Sometimes it means helping an organization adopt Drupal or contribute back to the project. Increasingly, it means representing Drupal in conversations far beyond our own community.
Over the past year, I’ve had the opportunity to speak about Drupal and open source in places where Drupal hasn’t traditionally had a voice, including AI conferences, international open source events, and United Nations Open Source Week. Those conversations reinforced something I’ve believed for a long time: Drupal has an important story to tell, but we need to be telling it more often and to more audiences.
Advocacy also means being honest. It means celebrating what makes Drupal exceptional while also recognizing that we face real challenges. The technology landscape is changing rapidly. Open source is evolving. Communities have new expectations. If we want Drupal to thrive for the next twenty years, we need to be willing to innovate while remaining true to the values that have always defined us: openness, collaboration, inclusion, and community.
For me, advocating for Drupal means showing up, listening carefully, building bridges, and helping ensure that Drupal continues to be a project the world looks to as a leader in open source.
I’m running because I believe Drupal is at one of the most important moments in its history.
We’re navigating enormous opportunities through AI, changing expectations around open source, and an increasingly challenging economic environment. At the same time, many members of our community are asking an important question: “Is anyone listening?”
I believe they deserve to be heard.
The Drupal Association exists to serve the project and its community. That means more than delivering programs and organizing events. It means listening carefully, communicating transparently, and ensuring that contributors feel they have a meaningful voice in the future of Drupal.
Over the past year I’ve worked to help move Drupal forward through the Drupal AI Initiative, advocacy, training, mentoring, and community building. Those experiences have reinforced something I’ve believed for a long time: our greatest strength isn’t our technology alone. It’s the people who choose to invest their time, talent, and trust in this project.
If elected, I’ll work to strengthen that trust by helping build a Drupal Association that is financially resilient, forward-looking, and deeply connected to the community it serves. I want contributors to know that their voices matter, that their concerns are heard, and that together we’re building a stronger future for Drupal.
That’s why I’m running.
I bring a combination of experience that I believe is particularly valuable for the Drupal Association at this point in its history.
I’ve served on the Drupal Association Board before, chaired its Governance Committee, and helped shape governance changes that continue to guide the organization today. Beyond Drupal, I’ve spent nearly two decades serving on nonprofit boards and understand both the strategic responsibilities and fiduciary duties that effective governance requires.
I’m also deeply engaged in Drupal’s future. Through the Drupal AI Strategic Initiative, my work as AI Ambassador at amazee.io, community training, speaking, and mentoring, I’ve been helping contributors understand and adopt new technologies while staying true to Drupal’s values of openness, transparency, and collaboration.
At the same time, I remain connected to the grassroots community. I’ve helped lead DrupalCamp Colorado for nineteen years, continue to mentor new contributors and speakers, and believe some of the best ideas for Drupal begin in our local communities.
Finally, I bring experience from outside our ecosystem. After nearly a decade leading enterprise digital platforms and AI initiatives at Pfizer, I understand the challenges and expectations of the organizations that choose Drupal. That perspective helps bridge the needs of enterprise users with the values that make Drupal unique.
Experience and vision matter. But leadership is ultimately measured by showing up, especially when the work is hard. I’ve tried to do that consistently for nearly twenty years: listening, building, mentoring, organizing, and helping leave this community stronger than I found it. If you choose to place your trust in me again, that’s exactly how I’ll serve on the Drupal Association Board.
My favourite Drupal memory goes all the way back to DrupalCon Barcelona in 2007.
I had just joined a Drupal agency, and my connection to the community was still very small. I’d been to a few local meetups when one of the founders asked, “Do you have a passport? Would you like to go to Barcelona?” My answer was an immediate, “Yes!”
There were only about 430 people at that DrupalCon, and for the first time I found myself surrounded by the people whose names I’d been seeing in the issue queues and documentation. I met Dries Buytaert, Moshe Weitzman, Karoly “chx” Negyesi, Morten Birch Heide-Jørgensen (MortenDK), Gábor Hojtsy, Jeff Eaton, Merlin of Chaos, Angie “webchick” Byron, and so many others who were shaping Drupal’s future.
What struck me wasn’t that they were influential. It was that they were approachable. They welcomed questions, shared ideas freely, and treated a newcomer like I belonged there.
That experience changed the trajectory of my career. It showed me that Drupal wasn’t just exceptional software. It was an exceptional community. Looking back, I think that’s the moment I stopped being someone who used Drupal and started becoming someone who wanted to help build Drupal.
Today, one of my favourite parts of every DrupalCon is welcoming someone who’s attending for the first time. Twenty years ago, the community made room for me. Ever since, I’ve tried to do the same for others.
I'm Helge, 50 years old, originally from northern Norway and now based in Bergen, Norway, married with one child. I've worked with Drupal for over 20 years as a user, developer, and project manager, and hold a degree in philosophy that shapes how I approach problem-solving and community work. Since 2017 I've organized the PHP Bergen / Drupal Bergen meetups, and since 2024 I've served on the board of Drupal Norway. Outside of Drupal, I enjoy cooking, 3D printing, and open source more broadly.
To me, building community means bringing people together around a shared goal and giving them a reason to keep showing up — including me. Over the years I've learned that it's really about building real relationships, not just connections of convenience: staying curious about new people, and making sure new faces feel just as welcome as familiar ones. Above all, it's about sharing knowledge. Even though I might not be the best programmer, I've both learned a lot from others and seen others grow through the knowledge we've shared
To me, advocating for Drupal means standing up for open source as a model that benefits everyone, not just those who can afford proprietary alternatives. It means helping keep the internet open — built on shared, transparent code rather than closed platforms controlled by a few. It also means taking security seriously, since trust in open source depends on the community's commitment to building and maintaining software responsibly. Advocating for Drupal isn't just about promoting a CMS; it's about promoting the values behind it — openness, collaboration, and shared responsibility for the tools we all depend on.
After more than 20 years working with Drupal — as a user, developer, and project manager — I want to take the next step and contribute more directly to the project's future, beyond what I've done locally through meetups and the Drupal Norway board. I believe Drupal needs to invest more in marketing and clearly communicating its strengths, especially as the CMS landscape becomes more crowded and competitive. I also think the community needs a balanced, thoughtful approach to AI — embracing the opportunities it offers while being deliberate about how it's integrated into the project and its workflows. Finally, I'm motivated by the need to bring in more junior developers and contributors; Drupal's long-term health depends on building a pipeline of new talent who can carry the project forward. Running for the board is my way of turning two decades of experience into a more active role in shaping where Drupal goes next.
I bring over 20 years of hands-on experience with Drupal, combined with a varied professional background spanning sales, marketing, development, and project management. That combination is exactly why I want to focus on two things I see as key drivers for Drupal's future: marketing Drupal more effectively toward large and public sector organizations, and making Drupal accessible to younger generations of developers and contributors. Since my time as a student at university, I've been involved in volunteer projects, and I've carried that same commitment into organizing the Bergen meetups and serving on the Drupal Norway board — experience that's taught me how to bring people together around a shared goal. I want to put that experience to work for the Drupal Association, helping the project grow both its institutional reach and its next generation of contributors.
One of my favorite memories is from an early Drupal Bergen meetup, where a group of shop employees showed up completely bewildered — they'd actually meant to go to an escape room and ended up with us instead. Once they were there, they stuck around, and ended up thoroughly impressed by what Drupal can do, even though they were probably about as far from our target audience as you could get.
I'm Helge, 50 years old, originally from northern Norway and now based in Bergen, Norway, married with one child. I've worked with Drupal for over 20 years as a user, developer, and project manager, and hold a degree in philosophy that shapes how I approach problem-solving and community work. Since 2017 I've organized the PHP Bergen / Drupal Bergen meetups, and since 2024 I've served on the board of Drupal Norway. Outside of Drupal, I enjoy cooking, 3D printing, and open source more broadly.
To me, building community means bringing people together around a shared goal and giving them a reason to keep showing up — including me. Over the years I've learned that it's really about building real relationships, not just connections of convenience: staying curious about new people, and making sure new faces feel just as welcome as familiar ones. Above all, it's about sharing knowledge. Even though I might not be the best programmer, I've both learned a lot from others and seen others grow through the knowledge we've shared
To me, advocating for Drupal means standing up for open source as a model that benefits everyone, not just those who can afford proprietary alternatives. It means helping keep the internet open — built on shared, transparent code rather than closed platforms controlled by a few. It also means taking security seriously, since trust in open source depends on the community's commitment to building and maintaining software responsibly. Advocating for Drupal isn't just about promoting a CMS; it's about promoting the values behind it — openness, collaboration, and shared responsibility for the tools we all depend on.
After more than 20 years working with Drupal — as a user, developer, and project manager — I want to take the next step and contribute more directly to the project's future, beyond what I've done locally through meetups and the Drupal Norway board. I believe Drupal needs to invest more in marketing and clearly communicating its strengths, especially as the CMS landscape becomes more crowded and competitive. I also think the community needs a balanced, thoughtful approach to AI — embracing the opportunities it offers while being deliberate about how it's integrated into the project and its workflows. Finally, I'm motivated by the need to bring in more junior developers and contributors; Drupal's long-term health depends on building a pipeline of new talent who can carry the project forward. Running for the board is my way of turning two decades of experience into a more active role in shaping where Drupal goes next.
I bring over 20 years of hands-on experience with Drupal, combined with a varied professional background spanning sales, marketing, development, and project management. That combination is exactly why I want to focus on two things I see as key drivers for Drupal's future: marketing Drupal more effectively toward large and public sector organizations, and making Drupal accessible to younger generations of developers and contributors. Since my time as a student at university, I've been involved in volunteer projects, and I've carried that same commitment into organizing the Bergen meetups and serving on the Drupal Norway board — experience that's taught me how to bring people together around a shared goal. I want to put that experience to work for the Drupal Association, helping the project grow both its institutional reach and its next generation of contributors.
One of my favorite memories is from an early Drupal Bergen meetup, where a group of shop employees showed up completely bewildered — they'd actually meant to go to an escape room and ended up with us instead. Once they were there, they stuck around, and ended up thoroughly impressed by what Drupal can do, even though they were probably about as far from our target audience as you could get.
Hi, I'm Janna. I’m a software engineer based in Australia, and day-to-day I wear a lot of hats—from team lead and developer to accessibility tester on all kinds of projects. I care a lot about open source, which is why you’ll usually find me co-organising local WordPress meetups, running Drupal code sprints, or helping out with DrupalSouth. I'm also out there speaking at various tech events such as AI engineer and DDD conferences; a couple of my recent presentations were “Secure By Design” and “Engineering for the Agentic Web When 50% of Your Traffic is Robots.” I’m contributing to Drupal code, updating documentation, and working on community initiatives every single week. After running for the board back in 2024, I’m excited to step up again to support our global community.
Building community means putting down the microphone and actually doing the work to bring people together. With the disconnect we’re all feeling post-COVID and in the rush toward AI, I believe we desperately need the human factor back. For me, it’s about creating physical spaces where one human being sits down and listens to the concerns of another. Whether that's organising local meetups, running conferences, or setting up monthly sprints, I focus on the logistics that get people into the same room so anyone, regardless of their skill level, feels included, heard, and welcomed.
Advocating for Drupal means earning back popularity among newcomers (student, teachers) and rebuilding the credibility with technical users who have moved on to other systems. Drupal needs to be a practical, go-to tool for small site builders, independent businesses, and universities. Real advocacy also means protecting how Drupal is discovered. In a world driven by LLMs and AI search engines, we have to ensure our documentation is clean, versioned, and accurate so these tools index modern Drupal correctly, rather than providing not so relevant or confusing documentation or outdated examples.
I am running to help the Association to focus back to three critical areas that are vital for Drupal's long-term future:
You should vote for me if you feel that Drupal leadership is turning conservative. I'm hands-on and I don't live on the island. Every single week, I am on the ground contributing to Drupal code, running local meetups, and organising conferences like DrupalSouth. But I also step outside our bubble to actively promote Drupal at other major tech events. Vote for me if you want a progressive, non-conservative voice on the board - someone focused, competitive, and relevant to the wider dev community.
Nothing beats the spark when people discover Drupal for the first time. Whether I’m working with clients, mentoring students, collaborating with fellow presenters, or bouncing ideas off colleagues, I love that exact moment when the lightbulb goes off. Seeing someone realise the sheer potential of what they can build with Drupal is incredibly rewarding, and it’s what keeps me energised to do this work.
Hi, I'm Janna. I’m a software engineer based in Australia, and day-to-day I wear a lot of hats—from team lead and developer to accessibility tester on all kinds of projects. I care a lot about open source, which is why you’ll usually find me co-organising local WordPress meetups, running Drupal code sprints, or helping out with DrupalSouth. I'm also out there speaking at various tech events such as AI engineer and DDD conferences; a couple of my recent presentations were “Secure By Design” and “Engineering for the Agentic Web When 50% of Your Traffic is Robots.” I’m contributing to Drupal code, updating documentation, and working on community initiatives every single week. After running for the board back in 2024, I’m excited to step up again to support our global community.
Building community means putting down the microphone and actually doing the work to bring people together. With the disconnect we’re all feeling post-COVID and in the rush toward AI, I believe we desperately need the human factor back. For me, it’s about creating physical spaces where one human being sits down and listens to the concerns of another. Whether that's organising local meetups, running conferences, or setting up monthly sprints, I focus on the logistics that get people into the same room so anyone, regardless of their skill level, feels included, heard, and welcomed.
Advocating for Drupal means earning back popularity among newcomers (student, teachers) and rebuilding the credibility with technical users who have moved on to other systems. Drupal needs to be a practical, go-to tool for small site builders, independent businesses, and universities. Real advocacy also means protecting how Drupal is discovered. In a world driven by LLMs and AI search engines, we have to ensure our documentation is clean, versioned, and accurate so these tools index modern Drupal correctly, rather than providing not so relevant or confusing documentation or outdated examples.
I am running to help the Association to focus back to three critical areas that are vital for Drupal's long-term future:
You should vote for me if you feel that Drupal leadership is turning conservative. I'm hands-on and I don't live on the island. Every single week, I am on the ground contributing to Drupal code, running local meetups, and organising conferences like DrupalSouth. But I also step outside our bubble to actively promote Drupal at other major tech events. Vote for me if you want a progressive, non-conservative voice on the board - someone focused, competitive, and relevant to the wider dev community.
Nothing beats the spark when people discover Drupal for the first time. Whether I’m working with clients, mentoring students, collaborating with fellow presenters, or bouncing ideas off colleagues, I love that exact moment when the lightbulb goes off. Seeing someone realise the sheer potential of what they can build with Drupal is incredibly rewarding, and it’s what keeps me energised to do this work.
Darren is the volunteer project lead for Drupal Forge. He joined the Drupal community in 2005 and has been an active contributor ever since. Until 2026, he maintained the Drupal platform for Estée Lauder Companies as a senior software engineer at Cognizant. Darren lives in Lakeland, Florida with his wife, three sons, and two cats.
Building community means two things:
We all own every Drupal project. We should continue to prioritize accessibility for people of all abilities in our products, tools, and events. We need to do a better job of responding to behavior that makes others feel unwelcome. We should not treat volunteers who maintain projects as if they were paid employees maintaining something we bought.
We need to improve our ability to work with people of different languages, skill levels, and time to contribute. Many issues have been ignored for years because a contributor did not provide a requested test or change notice. We need to establish a norm of assuming that whatever someone contributes is the best they can do; and, if more is needed, it’s up to the rest of us to move it forward.
To me, advocating for Drupal means spreading its value widely and making it easy to discover. Advocating for Drupal includes promoting the wider open source ecosystem and helping more vendors distribute ready made, fully customizable experiences to users. Everyone has a stake in Drupal; they just need to realize it.
I have a vision for making the value of Drupal easier to discover. In 2022 I took action to fulfill this vision by founding Drupal Forge as a community platform for zero-friction trial experiences. My vision includes developing ready-made kits for launching Drupal businesses. I want to ensure that Drupal experts like me always have work and that Drupal is used for projects that introduce it to a wider audience but are too small for big agencies.
I believe the Drupal Association is ready to lead us to this vision. After four years of leading from the outside, it is time for me to try leading from within.
I know the Drupal community from 20 years of contribution. I also know the challenges facing new members from volunteering as a mentor for Discover Drupal, the Open University Initiative, and Drupal events.
I understand the value of Drupal. Like many of you, I lost a secure, well-paid job when the large company I worked for decided to switch to a different platform. I am committed to regaining the ground we have lost. Drupal is not only more open but also ahead of other platforms in many ways. In many cases where Drupal is not the right solution, it is very close to being the right solution and just needs a push to get there.
I have proved my effectiveness by leading the Drupal Forge project.
If I have to choose a single favorite moment, it would be the first time I installed Drupal and learned how many features I could enable without writing code.
Darren is the volunteer project lead for Drupal Forge. He joined the Drupal community in 2005 and has been an active contributor ever since. Until 2026, he maintained the Drupal platform for Estée Lauder Companies as a senior software engineer at Cognizant. Darren lives in Lakeland, Florida with his wife, three sons, and two cats.
Building community means two things:
We all own every Drupal project. We should continue to prioritize accessibility for people of all abilities in our products, tools, and events. We need to do a better job of responding to behavior that makes others feel unwelcome. We should not treat volunteers who maintain projects as if they were paid employees maintaining something we bought.
We need to improve our ability to work with people of different languages, skill levels, and time to contribute. Many issues have been ignored for years because a contributor did not provide a requested test or change notice. We need to establish a norm of assuming that whatever someone contributes is the best they can do; and, if more is needed, it’s up to the rest of us to move it forward.
To me, advocating for Drupal means spreading its value widely and making it easy to discover. Advocating for Drupal includes promoting the wider open source ecosystem and helping more vendors distribute ready made, fully customizable experiences to users. Everyone has a stake in Drupal; they just need to realize it.
I have a vision for making the value of Drupal easier to discover. In 2022 I took action to fulfill this vision by founding Drupal Forge as a community platform for zero-friction trial experiences. My vision includes developing ready-made kits for launching Drupal businesses. I want to ensure that Drupal experts like me always have work and that Drupal is used for projects that introduce it to a wider audience but are too small for big agencies.
I believe the Drupal Association is ready to lead us to this vision. After four years of leading from the outside, it is time for me to try leading from within.
I know the Drupal community from 20 years of contribution. I also know the challenges facing new members from volunteering as a mentor for Discover Drupal, the Open University Initiative, and Drupal events.
I understand the value of Drupal. Like many of you, I lost a secure, well-paid job when the large company I worked for decided to switch to a different platform. I am committed to regaining the ground we have lost. Drupal is not only more open but also ahead of other platforms in many ways. In many cases where Drupal is not the right solution, it is very close to being the right solution and just needs a push to get there.
I have proved my effectiveness by leading the Drupal Forge project.
If I have to choose a single favorite moment, it would be the first time I installed Drupal and learned how many features I could enable without writing code.
I'm a software developer located in Los Angeles. I've contributed some modules and even a little code for D11.
It means expanding the community by reaching out to developers and users of other CMSes.
It means explaining to various audiences what Drupal can do for them. That starts with having a system that can be used by a wide range of people, not just experts.
I have three goals:
I'm already trying to make Drupal more usable by a wider range of people. For instance, I'm trying to make the permissions page easier to understand (drupal.org/node/3495351). I'm also the author of a wrapper for composer: drupal.org/project/sheephole_helper That lets users run composer commands without having to learn how to use the command line. Having to deal with composer, SSH, etc is one of the main reasons why many won't use Drupal. An insecure configuration where the web server can write to code directories is not the answer.
Although my contribution to D11 is small, it's one of my favorite memories of this project.
I'm a software developer located in Los Angeles. I've contributed some modules and even a little code for D11.
It means expanding the community by reaching out to developers and users of other CMSes.
It means explaining to various audiences what Drupal can do for them. That starts with having a system that can be used by a wide range of people, not just experts.
I have three goals:
I'm already trying to make Drupal more usable by a wider range of people. For instance, I'm trying to make the permissions page easier to understand (drupal.org/node/3495351). I'm also the author of a wrapper for composer: drupal.org/project/sheephole_helper That lets users run composer commands without having to learn how to use the command line. Having to deal with composer, SSH, etc is one of the main reasons why many won't use Drupal. An insecure configuration where the web server can write to code directories is not the answer.
Although my contribution to D11 is small, it's one of my favorite memories of this project.
I have been an active member of the Drupal community for more than 25 years. In the project's earliest days I registered the drupal.org domain and handed it over to Dries Buytaert, a small but formative moment in the history of what would become this community. Over the years I have tried to build durable infrastructure for that community rather than just participate in it. I founded and organized DrupalJam fifteen times, growing it into one of the most significant Drupal camps in the world. I co-founded Stichting Drupal Nederland and helped build it into one of the richest and most successful Drupal organizations in the Netherlands, later serving as its chairman for several years. I also founded the Splash Awards, ran them ten times, and grew the format into a genuinely global event, replicated across dozens of countries and culminating in an international edition. Earlier still, I served on the board of the Drupal Association when it operated as a Belgian non-profit, where I contributed to its foundational work. Professionally, my path has taken me deeper into open source as a business, rather than away from it. I work as [your exact title], leading sales and public-affairs efforts in commercial open source infrastructure, specifically enterprise Linux (SUSE Linux Enterprise Server) and Kubernetes management (the Rancher portfolio), including engagement at the level of the European Commission. This gives me a vantage point that is rare on most non-profit boards: I understand both the cultural and technical fabric of Drupal as a community, and the commercial and policy mechanics that determine whether open source projects survive and thrive at enterprise and governmental scale.
To me, building community means giving local colour the room to thrive, while making sure the Drupal Association functions as a strong umbrella above the many local foundations and user groups around the world. The Drupal ecosystem is not one audience, it is many: end users, large organizations running Drupal at scale, agencies delivering services on top of it, and the individual contributor who quietly keeps things running and is too often overlooked. A real community has to represent all of these roles, not just the loudest or most visible ones.
In practice, building community means activating people by setting examples and celebrating success. People rarely need to be convinced that contribution matters, they need to see it modelled, and they need their work recognized when it happens. That is the philosophy behind everything I have built in this space, from DrupalJam to Stichting Drupal Nederland to the Splash Awards: create the stage, show what good looks like, and then make sure credit reaches the people who earned it.
Advocacy is ultimately about making sure success gets seen, and celebrated, by the right audiences, through the right channels. That sounds simple, but it carries real depth: every act of advocacy is really an act of translation, taking what the community already does brilliantly and making it visible and meaningful to an audience that did not build it but needs to trust it.
For me, advocacy has to operate on multiple axes simultaneously. There is the axis we know well: developers as the audience, and earned media, conference talks, blog posts, word of mouth, as the medium. That path has served Drupal for two decades and it remains genuinely good. My instinct is not to abandon it but to make it stronger and more deliberate, more professional in its marketing, more consistent in celebrating wins rather than letting them pass quietly.
But that axis alone leaves real value untapped. The other axis that deserves far more deliberate attention is policy, reaching decision-makers, public administrations, and procurement officers who will never read a Drupal.org blog post but who decide whether an entire ministry standardizes on open source. And the other dimension that needs strengthening is the medium itself: moving beyond earned media into owned and, where it makes sense, paid media, genuine commercial-grade promotion of what this project and its ecosystem can do.
This matters financially as much as culturally. There is a long tail of potential sponsors who have never been properly approached, and a largely untapped landscape of subsidies and grants, government funding, but especially foundations, that fund digital public infrastructure and open source without yet knowing Drupal is a candidate. Advocacy done well is not just visibility for its own sake. It is the mechanism that turns recognition into resources, and resources into the next decade of the project.
I am running because I want to bring my network, my knowledge, and a fresh dose of energy to strengthening the Drupal Association, and because I want to do that on behalf of the whole world, not any single country, region, or continent.
My own roots are local. DrupalJam, Stichting Drupal Nederland, the Splash Awards, these were built from the Netherlands outward. But that experience taught me something that goes well beyond the Netherlands: every strong global community is, in fact, a federation of strong local ones. I believe deeply in couleur locale, in letting every region keep its own voice, its own language, its own way of celebrating its contributors. What I want is not to flatten that diversity, but to see every colour on the map grow stronger at the same time, with the Drupal Association acting as the umbrella that makes that possible everywhere, not just where the project has historically been strongest.
That is the energy and the network I want to bring to the board. Professionally, my work in commercial open source and enterprise Linux and Kubernetes has put me in conversation with organizations and policymakers well beyond the traditional Drupal heartlands, and I want to put those relationships to work for the entire ecosystem. A board seat is, for me, the opportunity to take 25 years of building locally and use it to help every local Drupal community in the world, wherever it is, become a little stronger.
Members should vote for me because I bring a rare combination of deep knowledge, a wide network, and a long, honourable track record of actually building things that lasted.
For 25 years I have put my name behind Drupal projects and delivered. DrupalJam ran fifteen times and grew into one of the most significant Drupal camps in the world. The Splash Awards ran ten times and became a genuinely global format, replicated across dozens of countries. Stichting Drupal Nederland became one of the richest and most successful Drupal organizations in the Netherlands under my chairmanship. None of these were one-off efforts. They were built, sustained, and grown year after year, which is the actual test of whether community work matters: not whether it launches, but whether it is still standing and still growing a decade later.
That same reliability defines how I work. I do not take on responsibilities lightly, and once I commit to something, I see it through with the people around me, openly and honestly. My professional life now adds another layer of knowledge and another network entirely, commercial open source, enterprise Linux, Kubernetes, and engagement at the policy level with the European Commission, which means I bring relationships and expertise to the board that extend well beyond the traditional Drupal world, while never having left it.
In short, I have a long record of taking on responsibility for this community and delivering measurable growth, with integrity, and I want to bring that same discipline and that same network to the Drupal Association at exactly the moment it needs to grow further.
My favorite memory is the second DrupalCon ever held, which I organized in Amsterdam in 2005. We deliberately rode the wave of the O'Reilly Open Source Convention happening next door, and used that proximity to pull some of the great minds of the open source world into the same room as us, people like David Axmark of MySQL and Rasmus Lerdorf, the creator of PHP.
What makes the memory so vivid is the scale, or rather the lack of it. We were a small group, just over thirty people, sitting together trying to figure out where this thing we were building was actually going. There was no sense yet that Drupal would become what it is today. And yet many of the people in that room went on to become legends of the open source world, each carving out their own significant path. It is a memory I come back to often, because it captures something essential about open source itself: the biggest futures are usually decided in the smallest rooms, by people who have no idea yet how far it will all go.
I have been an active member of the Drupal community for more than 25 years. In the project's earliest days I registered the drupal.org domain and handed it over to Dries Buytaert, a small but formative moment in the history of what would become this community. Over the years I have tried to build durable infrastructure for that community rather than just participate in it. I founded and organized DrupalJam fifteen times, growing it into one of the most significant Drupal camps in the world. I co-founded Stichting Drupal Nederland and helped build it into one of the richest and most successful Drupal organizations in the Netherlands, later serving as its chairman for several years. I also founded the Splash Awards, ran them ten times, and grew the format into a genuinely global event, replicated across dozens of countries and culminating in an international edition. Earlier still, I served on the board of the Drupal Association when it operated as a Belgian non-profit, where I contributed to its foundational work. Professionally, my path has taken me deeper into open source as a business, rather than away from it. I work as [your exact title], leading sales and public-affairs efforts in commercial open source infrastructure, specifically enterprise Linux (SUSE Linux Enterprise Server) and Kubernetes management (the Rancher portfolio), including engagement at the level of the European Commission. This gives me a vantage point that is rare on most non-profit boards: I understand both the cultural and technical fabric of Drupal as a community, and the commercial and policy mechanics that determine whether open source projects survive and thrive at enterprise and governmental scale.
To me, building community means giving local colour the room to thrive, while making sure the Drupal Association functions as a strong umbrella above the many local foundations and user groups around the world. The Drupal ecosystem is not one audience, it is many: end users, large organizations running Drupal at scale, agencies delivering services on top of it, and the individual contributor who quietly keeps things running and is too often overlooked. A real community has to represent all of these roles, not just the loudest or most visible ones.
In practice, building community means activating people by setting examples and celebrating success. People rarely need to be convinced that contribution matters, they need to see it modelled, and they need their work recognized when it happens. That is the philosophy behind everything I have built in this space, from DrupalJam to Stichting Drupal Nederland to the Splash Awards: create the stage, show what good looks like, and then make sure credit reaches the people who earned it.
Advocacy is ultimately about making sure success gets seen, and celebrated, by the right audiences, through the right channels. That sounds simple, but it carries real depth: every act of advocacy is really an act of translation, taking what the community already does brilliantly and making it visible and meaningful to an audience that did not build it but needs to trust it.
For me, advocacy has to operate on multiple axes simultaneously. There is the axis we know well: developers as the audience, and earned media, conference talks, blog posts, word of mouth, as the medium. That path has served Drupal for two decades and it remains genuinely good. My instinct is not to abandon it but to make it stronger and more deliberate, more professional in its marketing, more consistent in celebrating wins rather than letting them pass quietly.
But that axis alone leaves real value untapped. The other axis that deserves far more deliberate attention is policy, reaching decision-makers, public administrations, and procurement officers who will never read a Drupal.org blog post but who decide whether an entire ministry standardizes on open source. And the other dimension that needs strengthening is the medium itself: moving beyond earned media into owned and, where it makes sense, paid media, genuine commercial-grade promotion of what this project and its ecosystem can do.
This matters financially as much as culturally. There is a long tail of potential sponsors who have never been properly approached, and a largely untapped landscape of subsidies and grants, government funding, but especially foundations, that fund digital public infrastructure and open source without yet knowing Drupal is a candidate. Advocacy done well is not just visibility for its own sake. It is the mechanism that turns recognition into resources, and resources into the next decade of the project.
I am running because I want to bring my network, my knowledge, and a fresh dose of energy to strengthening the Drupal Association, and because I want to do that on behalf of the whole world, not any single country, region, or continent.
My own roots are local. DrupalJam, Stichting Drupal Nederland, the Splash Awards, these were built from the Netherlands outward. But that experience taught me something that goes well beyond the Netherlands: every strong global community is, in fact, a federation of strong local ones. I believe deeply in couleur locale, in letting every region keep its own voice, its own language, its own way of celebrating its contributors. What I want is not to flatten that diversity, but to see every colour on the map grow stronger at the same time, with the Drupal Association acting as the umbrella that makes that possible everywhere, not just where the project has historically been strongest.
That is the energy and the network I want to bring to the board. Professionally, my work in commercial open source and enterprise Linux and Kubernetes has put me in conversation with organizations and policymakers well beyond the traditional Drupal heartlands, and I want to put those relationships to work for the entire ecosystem. A board seat is, for me, the opportunity to take 25 years of building locally and use it to help every local Drupal community in the world, wherever it is, become a little stronger.
Members should vote for me because I bring a rare combination of deep knowledge, a wide network, and a long, honourable track record of actually building things that lasted.
For 25 years I have put my name behind Drupal projects and delivered. DrupalJam ran fifteen times and grew into one of the most significant Drupal camps in the world. The Splash Awards ran ten times and became a genuinely global format, replicated across dozens of countries. Stichting Drupal Nederland became one of the richest and most successful Drupal organizations in the Netherlands under my chairmanship. None of these were one-off efforts. They were built, sustained, and grown year after year, which is the actual test of whether community work matters: not whether it launches, but whether it is still standing and still growing a decade later.
That same reliability defines how I work. I do not take on responsibilities lightly, and once I commit to something, I see it through with the people around me, openly and honestly. My professional life now adds another layer of knowledge and another network entirely, commercial open source, enterprise Linux, Kubernetes, and engagement at the policy level with the European Commission, which means I bring relationships and expertise to the board that extend well beyond the traditional Drupal world, while never having left it.
In short, I have a long record of taking on responsibility for this community and delivering measurable growth, with integrity, and I want to bring that same discipline and that same network to the Drupal Association at exactly the moment it needs to grow further.
My favorite memory is the second DrupalCon ever held, which I organized in Amsterdam in 2005. We deliberately rode the wave of the O'Reilly Open Source Convention happening next door, and used that proximity to pull some of the great minds of the open source world into the same room as us, people like David Axmark of MySQL and Rasmus Lerdorf, the creator of PHP.
What makes the memory so vivid is the scale, or rather the lack of it. We were a small group, just over thirty people, sitting together trying to figure out where this thing we were building was actually going. There was no sense yet that Drupal would become what it is today. And yet many of the people in that room went on to become legends of the open source world, each carving out their own significant path. It is a memory I come back to often, because it captures something essential about open source itself: the biggest futures are usually decided in the smallest rooms, by people who have no idea yet how far it will all go.
A co-founder of FreelyGive Ltd. We are a company that has specialised in Native Drupal CRM but I've become obsessed with AI for the last few years. I've been heavily involved in spearheading the AI module and then the AI Initiative. We've built a team of people committed to radically pushing forwards both AI and Opensource AI. We believe strongly that Drupal is the best CMS for your agents to use and that a healthy truly opensource community around your AI applications is essential for freedom and sovereignty. I've been working outside the DA to do what I can to explore ways of the DA finding alternative and sustainable funding as I think it is essential to the long term success of Drupal not being owned by a single company like many open source software. Outside of Drupal I'm a somewhat recent father and avid video gamer.
Building community is about creating consensus amongst many different stakeholders so that everyone involves can feel that we are in win win win situations where our interests are aligned. I have spent a lot of time at events but also speaking to people and agencies on an individual basis to get to know the people, what they are passionate about and how they struggle in the Drupal community.
FreelyGive is in a unique situation given its size that we don't need to expand forever and grow wide. We want to grow tall and focus on the important issues we are best to solve and so we have found ourselves able to support, not compete with the Drupal ecosystem.
As a result building community and helping where we can is very ideologically important to us but also important for the bottom line.
We think building community means providing places for as many people as possible to achieve some kind of self actualisation, it needs to be fun to work together, rewarding but also financially sustainable.
I take this approach by creating maps of everyone, their goals and figuring out paths where working together is beneficial for everyone.
I've been involved in the Drupal community since 2011 and became radicalised around online communities and Opensource since a teenager.
I've loved the architecture of Drupal both the concept of the site builder (I'm not a programmer) but the unique truly opensource community of modules that you almost never see. Truly open, and interoperable with some level of security and maintenance guarantees compared to just throwing things on GitHub.
I love it! From the beginning with AI, we knew we could try and make FreelyGive single AI agency but felt that for Drupal to survive everyone will need to become an AI expert and every agency will need to have the expertise. So we set about focusing on leveling up all of Drupal.
I now spend as much time as possible getting out of the Drupal community and advocating for it. I've seen a real shift in the energy for Drupal and a renewed excitement across the community. I want to take that further!
I have been advocating for Drupal and specifically the Drupal Association for a while now. I've worked on creating a few new potential business models and helped with any lobbying and infrastructure or proof of concepts where I can. I have also been working on finding partners who can directly fund Drupal and the Drupal Association and some of those might be coming to fruition with real ongoing revenue for the DA. I think it is essential the DA is able to bring in funds sustainably to maintain what makes Drupal unique otherwise it may fall into the sea of projects across github. The Drupal AI Initiatives organisation has to some degree been a place to explore potential ideas that could scale into the Drupal Association.
I have been doing this already and whether or not I am on the board I can continue this mission with existing board members, staff in the DA and stakeholders across the community.
However I believe I may be able to help further by being part of the board itself.
AI isn't just about AI features itself. The world is fundamentally changing in many ways even if not directly touched by a specific LLM model. I want to help Drupal and the DA survive, reform where needed and thrive in this new world. I'll be here to help Drupal and the DA regardless and it's up to the community and board for whether or not people feel like I can help further by being directly part of it!
I bring a fresh perspective to the board as someone who is relatively new to the internal workings of Drupal and the Drupal association whilst still bringing a deep understanding of Drupal and it's community as I started my business half way through university spending a good 3 hours a day reading every critical issue for Drupal 7 and every new comment!
I run and own an agency and so have a good deal of autonomy and personal understanding for the issues many agencies will face whilst also having the autonomy to help where I need to without needing to answer to anyone specifically apart from my co-owners who are all very committed to Drupal.
I have spoken about Drupal and AI a great deal and I'm continuing to work on thought leadership, podcasts , hackathons etc.
I'm also out there in the community getting to know many of you!
I have a good deal of recent board experience via the AI Initiative but to some degree I am a rookie compared to others on the board and so I may be able to offer a fresh perspective and learn.
So why should members vote for me? Well I hope many members who have interacted with me in the community can answer that question and see how much I have been trying to help people where they are at and how much passion I have for this community to survive.
To some degree... Discovering Views! It changed everything! (and then more recently meeting earl miles! So many people in this community are heroes of mine from when I started as a teenager) Seeing the reaction at Drupalcon Barcelona to our Drupal CMS AI agents was pretty amazing too!
A co-founder of FreelyGive Ltd. We are a company that has specialised in Native Drupal CRM but I've become obsessed with AI for the last few years. I've been heavily involved in spearheading the AI module and then the AI Initiative. We've built a team of people committed to radically pushing forwards both AI and Opensource AI. We believe strongly that Drupal is the best CMS for your agents to use and that a healthy truly opensource community around your AI applications is essential for freedom and sovereignty. I've been working outside the DA to do what I can to explore ways of the DA finding alternative and sustainable funding as I think it is essential to the long term success of Drupal not being owned by a single company like many open source software. Outside of Drupal I'm a somewhat recent father and avid video gamer.
Building community is about creating consensus amongst many different stakeholders so that everyone involves can feel that we are in win win win situations where our interests are aligned. I have spent a lot of time at events but also speaking to people and agencies on an individual basis to get to know the people, what they are passionate about and how they struggle in the Drupal community.
FreelyGive is in a unique situation given its size that we don't need to expand forever and grow wide. We want to grow tall and focus on the important issues we are best to solve and so we have found ourselves able to support, not compete with the Drupal ecosystem.
As a result building community and helping where we can is very ideologically important to us but also important for the bottom line.
We think building community means providing places for as many people as possible to achieve some kind of self actualisation, it needs to be fun to work together, rewarding but also financially sustainable.
I take this approach by creating maps of everyone, their goals and figuring out paths where working together is beneficial for everyone.
I've been involved in the Drupal community since 2011 and became radicalised around online communities and Opensource since a teenager.
I've loved the architecture of Drupal both the concept of the site builder (I'm not a programmer) but the unique truly opensource community of modules that you almost never see. Truly open, and interoperable with some level of security and maintenance guarantees compared to just throwing things on GitHub.
I love it! From the beginning with AI, we knew we could try and make FreelyGive single AI agency but felt that for Drupal to survive everyone will need to become an AI expert and every agency will need to have the expertise. So we set about focusing on leveling up all of Drupal.
I now spend as much time as possible getting out of the Drupal community and advocating for it. I've seen a real shift in the energy for Drupal and a renewed excitement across the community. I want to take that further!
I have been advocating for Drupal and specifically the Drupal Association for a while now. I've worked on creating a few new potential business models and helped with any lobbying and infrastructure or proof of concepts where I can. I have also been working on finding partners who can directly fund Drupal and the Drupal Association and some of those might be coming to fruition with real ongoing revenue for the DA. I think it is essential the DA is able to bring in funds sustainably to maintain what makes Drupal unique otherwise it may fall into the sea of projects across github. The Drupal AI Initiatives organisation has to some degree been a place to explore potential ideas that could scale into the Drupal Association.
I have been doing this already and whether or not I am on the board I can continue this mission with existing board members, staff in the DA and stakeholders across the community.
However I believe I may be able to help further by being part of the board itself.
AI isn't just about AI features itself. The world is fundamentally changing in many ways even if not directly touched by a specific LLM model. I want to help Drupal and the DA survive, reform where needed and thrive in this new world. I'll be here to help Drupal and the DA regardless and it's up to the community and board for whether or not people feel like I can help further by being directly part of it!
I bring a fresh perspective to the board as someone who is relatively new to the internal workings of Drupal and the Drupal association whilst still bringing a deep understanding of Drupal and it's community as I started my business half way through university spending a good 3 hours a day reading every critical issue for Drupal 7 and every new comment!
I run and own an agency and so have a good deal of autonomy and personal understanding for the issues many agencies will face whilst also having the autonomy to help where I need to without needing to answer to anyone specifically apart from my co-owners who are all very committed to Drupal.
I have spoken about Drupal and AI a great deal and I'm continuing to work on thought leadership, podcasts , hackathons etc.
I'm also out there in the community getting to know many of you!
I have a good deal of recent board experience via the AI Initiative but to some degree I am a rookie compared to others on the board and so I may be able to offer a fresh perspective and learn.
So why should members vote for me? Well I hope many members who have interacted with me in the community can answer that question and see how much I have been trying to help people where they are at and how much passion I have for this community to survive.
To some degree... Discovering Views! It changed everything! (and then more recently meeting earl miles! So many people in this community are heroes of mine from when I started as a teenager) Seeing the reaction at Drupalcon Barcelona to our Drupal CMS AI agents was pretty amazing too!
I currently lead Drupal as an open-source product at Acquia, am on the Drupal AI Initiative team and have been a member of the Drupal community for 20+ years.
To me, Drupal is the community. Drupal is what it is because of two decades of community conversations, work, ideas, and collaboration pulling us towards well-though and proven capabilities based on real-world needs. Without the community none of what we do would be possible.
It's important that open, collaborative, community backed software is what the world chooses when they need a Content Management System. My goal is that when that need arises, Drupal is the #1 choice.
I value the Drupal community and the opportunities Drupal has given many of us over the years. As AI rapidly changes the nature of software and open-source itself it's important to me that Drupal retains it's identity, technical foundations, and community.
I've worked with Drupal for 20+ years, from small hobby sites to some of the largest digital properties in the world. As Technical Director of Acquia's Professional Services group, I worked alongside some of the top minds in the community. More recently, as product owner for Drupal as an open-source product at Acquia and a member of the Drupal AI Initiative leadership team, I've focused on ensuring Drupal is well positioned for the future.
When I started building with Drupal I had very little "real" programming knowledge, but the community was open, available, and willing to help. I owe much of my career trajectory and personal development to Drupal and the community.
I currently lead Drupal as an open-source product at Acquia, am on the Drupal AI Initiative team and have been a member of the Drupal community for 20+ years.
To me, Drupal is the community. Drupal is what it is because of two decades of community conversations, work, ideas, and collaboration pulling us towards well-though and proven capabilities based on real-world needs. Without the community none of what we do would be possible.
It's important that open, collaborative, community backed software is what the world chooses when they need a Content Management System. My goal is that when that need arises, Drupal is the #1 choice.
I value the Drupal community and the opportunities Drupal has given many of us over the years. As AI rapidly changes the nature of software and open-source itself it's important to me that Drupal retains it's identity, technical foundations, and community.
I've worked with Drupal for 20+ years, from small hobby sites to some of the largest digital properties in the world. As Technical Director of Acquia's Professional Services group, I worked alongside some of the top minds in the community. More recently, as product owner for Drupal as an open-source product at Acquia and a member of the Drupal AI Initiative leadership team, I've focused on ensuring Drupal is well positioned for the future.
When I started building with Drupal I had very little "real" programming knowledge, but the community was open, available, and willing to help. I owe much of my career trajectory and personal development to Drupal and the community.
DrupalCon Rotterdam is one of those events that naturally attracts attention across the Drupal ecosystem. Not only because it brings the community together, but because it creates a space where technology, strategy, contribution and real-world digital projects meet.
For anyone working with Drupal, open source or digital experience platforms, the question is not just “what happens at DrupalCon?”, but it might be:
“If you have never been before, why should this be the year to go?”
Photo by Joris Vercammen
Rotterdam feels like a strong fit for an event like DrupalCon. It is a city known for innovation, architecture, international connections and a forward-looking mindset — qualities that align naturally with the spirit of the Drupal community.
Bringing DrupalCon to Rotterdam creates an opportunity to connect the European Drupal community in a dynamic and accessible setting. It also gives professionals from different markets the chance to meet, exchange perspectives and discuss how Drupal continues to evolve in a fast-changing digital landscape.
One of the strongest reasons to attend DrupalCon is the quality of the knowledge shared by the community.
This is not only about product updates or technical presentations, It is about learning from people who are building, maintaining and improving digital platforms in real contexts, often with complex requirements, long-term governance needs and ambitious user experience goals.
From technical sessions to strategic case studies, DrupalCon gives attendees access to practical insight that is difficult to get from documentation alone.
Drupal has always been more than a content management system; It is an open-source project supported by a global network of contributors, companies and professionals.
For someone who has never attended before, this is one of the most compelling reasons to go: Online discussions, issue queues and documentation are valuable, but meeting people face to face adds a different layer to the experience.
Conversations during sessions, between talks or at community events can lead to new ideas, partnerships and a better understanding of how others approach similar challenges.
Photo by Matthew Saunders
DrupalCon is also a place to see what organisations are doing with Drupal today.
Real-world examples often show the platform’s value more clearly than feature lists. They reveal how Drupal is being used to support public sector platforms, media websites, higher education, enterprise ecosystems, multilingual content, accessibility requirements and complex editorial workflows.
That is why DrupalCon is relevant beyond development, project managers, designers, UX professionals, marketers, content teams and business leaders can all find useful perspectives on delivery, governance, accessibility, platform strategy and the role of open source in long-term digital transformation.
Attending DrupalCon for the first time is a way to move from observing the community to being part of it.
It is an opportunity to learn from experienced professionals, understand the direction of the platform, discover practical use cases and build connections that can continue long after the event ends.
DrupalCon Rotterdam represents more than another event in the digital calendar, It is a chance to understand Drupal through the people and projects that keep it moving forward.
For a first-time attendee, that may be the strongest reason to go.
Because sometimes the best way to understand the value of a community is not to read about it from the outside. It is to be in the room where that community comes together.
- Article by Daniela Moreira
Drupal Camps and Summits are a great way to keep up with new developments, gain ideas and fresh perspectives, and make new connections.
Upcoming events include:
A Drupal Camp or Summit is a great chance to learn something new, meet people doing interesting work, and pick up ideas you can take back to your own projects. Whether you're there for the sessions, the hallway conversations, or just to connect with the community, you'll leave with fresh inspiration and a few new contacts.
Drupal Camps are always looking for new speakers and sponsors. If you want to gain experience giving presentations, consider submitting a talk idea to a community event.
We've published an updated product strategy for Drupal CMS. Version 2.0 replaces the original Drupal Starshot strategy from August 2024, and it reflects where we are after nearly two years of building.
The updated strategy largely documents what we're already doing, and why, and makes some important clarifications.
The initial strategy framed content creators and marketers as the primary target audience. That made sense as a signal about our ambitions: Drupal already has a reputation for being developer-friendly, so we wanted to emphasize the focus on end users.
In practice, though, it created some confusion. Marketers are the end users of the sites built with Drupal CMS, but they're not the ones installing it, configuring it, or (in most cases) choosing it. That decision usually belongs to agencies and professional developers.
So the updated strategy is clearer: Content creators and marketers remain the target person for the product as end users, and the primary audience for the builder experience is agencies and professional developers. We can only reach marketers if developers can succeed with Drupal.
Rather than representing a change in what we're focused on, this now more accurately captures it.
The strategic frame has shifted to "making agencies and developers successful faster." The end goal of delivering great experiences for content teams is still central to the strategy, but we are explicit about doing that through agencies and developers.
A few other notable updates:
AI is now framed as infrastructure, rather than a feature. The original strategy positioned AI as one of several ways to win. Version 2.0 is more direct: every workflow in Drupal CMS should be operable by an AI agent. The goal is to be able to ship new AI-enabled workflows in days, not months.
Integrated hosting providers are now explicitly part of the strategy. These platforms are becoming real distribution channels for Drupal CMS, and the strategy names them as a priority. Making Drupal CMS excellent to provision and host is a prerequisite for those partnerships.
Vibe coding platforms are now named as a positioning opportunity. We're not competing with tools like Lovable or Bolt for prototyping. But we are positioning Drupal CMS as where those projects land when they need real content governance, multi-contributor workflows, and long-term maintainability.
The timeline has changed. Version 1.0 set a target of June 2027. Version 2.0 extends that to June 2028, acknowledging that the scope has grown and the strategy is more comprehensive.
We're still aiming to expand in the mid-market, with projects with total budgets in the $30,000–$120,000 USD range, and we're still explicitly not competing with entry-level website builders. We are also calling out that we will continue to maintain our leadership in the enterprise market.
And, of course, the differentiators against proprietary CMS solutions are the same: open source, no vendor lock-in, digital sovereignty.
The updated strategy is published on Drupal.org.
If you have questions or feedback on the direction, find us in #drupal-cms-development on Drupal Slack.
Recent Drupal developments point to a clearer direction for the project’s AI and developer-experience work. The immediate story is not only that Drupal is adding AI features.
Core performance, upgrade tooling, workflow orchestration, and AI governance are beginning to converge around a more controlled operating layer for modern web teams. That makes maintainability, auditability, and human review central to Drupal’s AI direction, not secondary safeguards.
Drupal 11.4.0, published on 1 July 2026, gives that direction a stronger core foundation. The release reduces database queries compared with Drupal 11.3, speeds up recipe-based site installation, improves translation file handling, and adds Brotli compression for aggregated CSS and JavaScript when ext-brotli is available. It also introduces an experimental extensible native command-line interface through ./vendor/bin/dr, improves password hashing with support for argon2id, and adds display-management changes intended to support tools such as Drupal Canvas.
The AI layer is moving in the same direction. Drupal AI 1.4.0 adds developer-focused drush generate commands for providers, automators, guardrails, operation types, API explorers, function calls, and related extension points. The release also introduces chat normalisation, Views Bulk Operations integration for AI Automators, failover foundations, and streaming guardrails.
Those additions support AI workflows that need clearer execution paths, safer handling, and extension points that contributed modules can build on. They also match the distinction now forming around Drupal’s Inside AI and Outside AI work. Inside AI covers cases where a person uses Drupal and Drupal uses AI to assist, while Outside AI covers cases where a person uses an external agent and the agent uses Drupal.
In that model, Drupal’s value is not just page rendering. It is the governed system of record for content structure, permissions, validation, moderation, revisions, and publishing workflows. Dries Buytaert’s recent writing on agentic workflows frames the same challenge around setup, connection, context, governed action, validation, recovery, and launch.
The same question appears in Drupal’s orchestration work. Recent discussions around ECA, FlowDrop, Maestro, and Drupal core focus on whether automation tools can share vocabulary and data-handoff contracts while keeping their different execution models. Randy Kolenko’s recent Nextide post adds the durable-state side of that discussion, positioning Maestro around long-running workflows, human approval steps, and audit trails that persist beyond a single request or cache cycle.
Upgrade tooling is also becoming part of the maintainability story. As of Rector 2.5, Composer-based sets support Drupal, allowing Rector to inspect composer.json, detect installed Drupal and dependency versions, and apply relevant refactoring sets without manually listing each Drupal version in rector.php. For site owners and maintainers, that reduces configuration work as Drupal 11.4, Drupal 12, and later releases move through the upgrade path.
The broader open-source context came through at UN Open Source Week 2026, held from 22 to 26 June 2026 at United Nations Headquarters in New York. The official programme focused on open source, artificial intelligence, Digital Public Infrastructure, Open Source Program Offices, sustainable public infrastructure, and digital cooperation. Matthew Saunders’ Drupal.org reflection connected those discussions to AI harnesses, orchestration, constraints, auditability, verification, and human-in-the-loop workflows.
For Drupal, the practical implication is clear. AI adoption depends less on isolated prompts and more on trusted systems that can govern what agents do, record what happened, and keep human responsibility visible.
Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication’s Drupal Slack channel at #thedroptimes.
(Allen Jason, junior sub-editor at The DropTimes, writes and curates this week’s Editor’s Pick.)
read moreIn early 2025 I noticed an odd behavior with how responsive images were rendering in my Drupal site. This was a Drupal 10.4 site and the configuration I set was being ignored causing images to render smaller than expected.
I have worked with responsive images for many years and have written a 7-part blog series about them, and have never run into this issue until now.
Note: The issues described in this post do not affect the <picture> element. They are only present when using the srcset and sizes attributes of the <img> tag.
After some debugging and testing, I noticed the image rendering issue was directly related to the fallback image style used in the responsive images UI. The original purpose of the fallback image is to be used in the event the browser does not support responsive images. As of the date of this post, the browser support for srcset, sizes, and <picture> is at about 97%, which pretty much means it is no longer an issue in almost all cases.
The responsive_image core module in Drupal started explicitly adding width and height attributes to the <img> tag from the fallback image's dimensions. This was a fix for an issue in Drupal core 10.1.x-dev, which was closed (fixed) on August 9, 2023.
Rendering image at 325 x 217px (fallback image dimensions), but the loaded image is 2600 x 1733px.
Additional research led me to Drupal.org issue #3377420 which seems to be where things may have changed and resulted in the bug I was experiencing. After reading through the comments in the issue page, issue #3359421 was referenced which was even older than #3377420, and goes back to Drupal 10.1. In either case, I see the main reason for the new changes was to address a well-known issue when loading images, Cumulative Layout Shift.
Cumulative Layout Shift, or CLS[1], has been a problem for many years when rendering images or other media content. CLS refers to the shifting of layouts or content as pages with images or other media content load. If your Drupal site is rendering images small and then "jumping" to full size, your real-world users are experiencing layout shifts. This is not only a bad user experience for your visitors, but it also affects accessibility and SEO[2] ranking.
While addressing CLS should be a priority, I don't think forcing the fallback image's dimensions into the rendered image is the way to go about it, but I do understand the community's intentions were in the right place. I just hoped this would have been a wider and more open process so developers had a better understanding of what was happening.
The original issue I referenced above gave me clues to correct the bug I was experiencing: revert the changes done in that issue by creating my own patch that I and others could use to resolve the issue and go back to the original state.
I created Issue #3516726, which removes the logic that was forcing the fallback image's width and height into the rendered image. Looking back I realize the problem was not the fact that the image's dimensions were those from the fallback image, but not having a better system for providing the rendered image with the correct dimensions during the page load process.
This is the real issue: A timing gap between the server and client when network requests for image information are triggered by the browser.
Whether you use Drupal or any other software stack, the data orchestration between the server and the browser experiences a delay. The server has the raw data (the image file), but the browser cannot access it when it needs it most (during initial page parsing).
The patch I wrote, while it prevented the fallback image dimensions from being used in my rendered images, didn't fix the issue. Instead, it directed it to the image style's dimensions I had configured as my responsive image styles bundle within Drupal's responsive image styles UI. You may be thinking: great, isn't that what the purpose of responsive image styles is? The answer is "yes", but there was a problem: The same "timing" issue described above. The browser still could not grab the proper image dimensions from the multiple image sources and pass it down to the rendered image, so Drupal again, trying to be helpful, this time was forcing the image dimensions from the last image style in my responsive image styles bundle (See the image below). The outcome is the same as the first issue because if the dimensions of the last image style are too small, the image renders smaller than the expected size.
Responsive images UI highlighting multiple image styles
In the image above, I have configured responsive images so when the viewport reaches 1040px or higher, the image should render at 1040px wide. However, since the dimensions of the last selected image style are 500px by 500px, that's the size in which my image will render. Same issue as before except now it originates from a different source.
Just like before, I filed Issue #3523451, which effectively updates Drupal's logic but this is simply another workaround that does not address the core issue of images rendering.
<picture> element: Not the recommended approach unless you are managing art direction.Understanding the server/client relationship and why image rendering is still an issue will allow you to proactively plan for a "solution" that works for your projects. Looking back, I don't need either of the patches I wrote because they are both doing the same thing Drupal core is already doing, assigning an arbitrary width and height to images in an effort to address CLS.
Knowing this gives me a better context to determine an approach that could work well in my project based on its requirements. In my case, I know I need to set my fallback images to a size that would satisfy the most common image rendering use cases. It's not ideal, but is there any other choice? Maybe. Read on.
In theory, the srcset and sizes attributes for the <img> tag were supposed to address our responsive images, but as you have learned in this post, they don't. However, don't throw them away just yet; they are still critical pieces of the equation and we need them because they offer many benefits.
If you get excited about responsive images like I do, sorry, something is not well in your head 😃. Actually, if you are a fan of responsive images, you may have heard of a brand new and promising solution that has surfaced in recent months: Using sizes="auto" in your image tag. It is new but all but one of the major browsers already support it (caniuse.com).
Google's Baseline still is still not providing correct data points, but give it some time and we should see these numbers improve.
For comparison, this is how a typical responsive image configuration may look at an image level:
<img
srcset="image-small.jpg 300w, image-medium.jpg 800w, image-large.jpg 1200w"
sizes="(min-width: 1200px) 1200px, (min-width: 760px) 800px, 100vw"
src="image-medium.jpg"
alt="A description of the image">Notice the srcset attribute contains multiple image options/sources to satisfy any use case in this example. Also notice how each source includes a width (w) descriptor: 300w, 800w, etc. The w descriptor's job is to inform the browser how wide each image is. This is extremely important information for the browser.
Also important is the sizes attribute. The value of sizes can be as simple as 100vw which means 100% the viewport width, full width, or a more complex formula using a media query as shown in our example above to query the width of the viewport and conditionally serve the right image for the job.
The following technique is a new attempt at addressing the gap between the server/client requests when rendering images. It is probably the most promising technique I've seen in years, and several articles about it have been recently published including one from Matt Marquis, one of the founding members of the Responsive Images Community Group or RICG[3]. I have been following and learning from Matt since the days when he first introduced the <picture> element, a ground-breaking development to manage responsive images.
Rather than repeating what Matt so perfectly has explained, I'd encourage you to read his article along with others I've shared in the resources section at the end of this post, for a complete description of the sizes="auto" approach.
As a teaser, I have updated the previous code snippet by adding auto as a value to the sizes attribute along with the previous value as a fallback. Take a look:
<img
srcset="image-small.jpg 300w, image-medium.jpg 800w, image-large.jpg 1200w"
sizes="auto, (min-width: 1200px) 1200px, (min-width: 760px) 800px, 100vw"
src="image-medium.jpg"
alt="A description of the image">As Matt Marquis perfectly puts it regarding the server/client latency issue:
the central issue with srcset/sizes was one of timing...
and he continues by explaining why previous attempts to address this issue were put in place:
...a browser makes decisions about image requests long before it has any information about the page’s layout, so we had to provide it with that layout information.
To be clear, although this is still the default behavior: If your markup includes an <img> tag, it will trigger a request long before any page layout information can be known - that is, unless the image uses the loading="lazy" attribute, a well-known standard for any image that appears outside of the user's viewport at the time the page first loads.
By using loading="lazy", the image is now requested at the point the user interacts with it (user scrolls to display the image within the viewport), long after the browser has all the information it needs about the sizes of the rendered image thereby ensuring it meets the layout requirements and avoiding CLS.
You can use sizes="auto" now as shown in the previous snippet and browsers that support it will use it, while browsers that don't yet support it will ignore it and use the traditional media query shown in the snippet. Win-win 🙌
I feel we are at a point in time when we finally have a good handle on serving images the right way. I for one will be diving deep into sizes="auto" to see for myself the effects of this technique and whether this would address the bugs this post was written about. I shall report back.
CLS is a confirmed, direct ranking factor for Google, November 19, 2025. ↩︎
Matt Marquis, The end of responsive images, April 23, 2026. ↩︎
We're announcing DDEV v1.25.3: faster ddev start and ddev stop, built-in Docker Compose, stable Podman and Docker Rootless support, MariaDB 12.3 LTS support, Node.js improvements, XDG_CONFIG_HOME changes, and more.
This release represents 131 PRs from the entire DDEV community: your suggestions, bug reports, code, and financial support made it possible.
ddev start, ddev stop, and ddev restartddev start in v1.25.3 (bottom) is faster than in v1.25.2 (top), including a faster warm start:
ddev stop in v1.25.3 (bottom) is significantly faster than in v1.25.2 (top), and the same improvement also applies to ddev poweroff and ddev delete, since all three share the same code path:
ddev restart in v1.25.3 (bottom) is significantly faster than in v1.25.2 (top), since it stops and starts a project and benefits from both improvements:
Post-healthcheck tasks now run concurrently instead of one after another, reducing overall ddev start time, thanks to @jonesrussell.
A bug in the web server startup script also added a ~10-second delay to ddev stop. That delay is now gone.
We benchmarked ddev start from a stopped state on both macOS and Linux, and v1.25.3 is faster on both. Numbers vary by machine, but you can reproduce it with scripts/compare-start-perf.sh:
git clone https://github.com/ddev/ddev ddev-upstream
cd ddev-upstream
bash scripts/compare-start-perf.sh v1.25.2 v1.25.3
On macOS, v1.25.3 is about 28% faster than v1.25.2 (benchmarked by @rfay):
Summary (ddev start from stopped state)
-------------------------------------------------------------------
A (v1.25.2): median=11.03s trimmed-mean=10.49s
B (v1.25.3): median=7.91s trimmed-mean=7.84s
B is FASTER than A by 3.12s (-28.3%) on median
On Linux, it's about 21% faster (benchmarked by @stasadev):
Summary (ddev start from stopped state)
-------------------------------------------------------------------
A (v1.25.2): median=18.03s trimmed-mean=18.25s
B (v1.25.3): median=14.18s trimmed-mean=14.96s
B is FASTER than A by 3.85s (-21.4%) on median
DDEV now uses the Docker Compose SDK directly instead of shelling out to a separate docker-compose binary. The $HOME/.ddev/bin/docker-compose binary DDEV used to download and manage can be removed. This switch was made possible by the Docker Compose maintainers, who exposed the SDK as a reusable library in Compose v5.0.0. Thank you very much!
Driving Compose through the SDK is also what gives you the cleaner output and live per-step timer in the GIFs above: DDEV now controls how progress is displayed instead of passing through whatever the external binary printed.
This is the same underlying change that added the optional ddev config global --docker-buildx-version setting in this release. See Docker Buildx Requirement in DDEV for the full background on Buildx and the Compose SDK switch.
DDEV now supports MariaDB 12.3, the latest LTS release. For new projects, set it with:
ddev config --database=mariadb:12.3
To migrate an existing project's database, use:
ddev utility migrate-database mariadb:12.3
Both Podman rootless and Docker rootless are now stable. We introduced this support as experimental in v1.25.0. See Podman and Docker Rootless in DDEV for the background, trade-offs, and the work behind it. Setup instructions:
ddev start. Previously the build phase always used DDEV's default version, which could cause problems when a project specified a different one (see ddev-pnpm#14).npm packages in post-start hooks, move them to extra Dockerfiles instead, since those now run against the correct Node.js version.nodejs_version is now preserved in .ddev/config.yaml even when it matches DDEV's default (previously it was removed in that case).nodejs_version: "" in .ddev/config.yaml always uses the default Node.js version bundled with DDEV, currently Node.js 24.ddev exec n install <version> inside the web container. This used to be a reason to use nvm, which was moved to the ddev-nvm add-on in v1.25.0; with n built-in, you no longer need nvm for it.N_PREFIX moved from /usr/local to /usr/local/n.nodejs_version documentation for more details.XDG_CONFIG_HOME Is No Longer Respected, but DDEV_XDG_CONFIG_HOME Is AvailableWe received several reports of DDEV recreating $HOME/.ddev repeatedly:
Warning: multiple global DDEV configurations found, /home/stas/.config/ddev is used, /home/stas/.ddev is not used, delete one of them to avoid confusion
IDEs such as PhpStorm don't always see XDG_CONFIG_HOME from the terminal, so DDEV fell back to and recreated $HOME/.ddev repeatedly. See the upstream issue IJPL-1055 for details.
To avoid this problem, DDEV now reads its own environment variable, DDEV_XDG_CONFIG_HOME, and no longer respects XDG_CONFIG_HOME. If you had set XDG_CONFIG_HOME to something other than its default of $HOME/.config, set DDEV_XDG_CONFIG_HOME to that same value instead.
Support for using $HOME/.config/ddev as the global configuration directory on Linux is unchanged.
This release includes many more features and bugfixes. See the full release notes for the complete list.
From the entire team, thanks for using, promoting, contributing, and supporting DDEV!
If you have questions, reach out in any of the support channels.
Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
This article was edited and refined with assistance from Claude Code.
read moreIt's often useful to let the machines do the work, and output something that's dynamically computed on an entity. By that I mean something that can't be hardcoded as a fixed value for all entities of a particular type, but that varies for each entity, in a way that allows it to be generated in code rather than laboriously entered into each entity form by humans.
For example, you might want a backlink for an entity reference, or a link to a view that has an argument for the entity's ID, or something that depends on field values on the entity.
There are several ways in Drupal of putting something dynamic on the entity's display output. You can of course add something to the build array yourself, in either the entity's view handler or hook_entity_view(). The extra fields system lets you then declare your additional build array item with hook_entity_extra_field_info() which allows it to be rearranged among normal fields in the field admin UI.
This is okay, but the extra fields system is Drupal 5-era stuff. Your piece of build array is just that, some render stuff; it can't participate in any data structures and nothing else will recognise it and work with it.
A better approach is a computed field. This involves a little more boilerplate code than the extra fields technique, but there are several benefits.
The first is that you are defining a field value, not a render array, and you get access to all the field formatters that apply to your type of data. So for example, if your computed data is a URL, you get all of the link field formatters at your disposal, in core and contrib.
The second is that anything that works with fields will be aware of your computed field. So you can add it to a view as a field (though not a sort or filter of course, since it has nothing in the database). You can add it to a SearchAPI index (and there, you actually can filter on it, because SearchAPI will index the computed value into its backend).
Here's what you need to do. You need two things:
Unlike declaring code fields, you don't need to declare a field storage: that's because a computed field doesn't store anything!
Create a subclass of \Drupal\Core\Field\FieldItemList that uses
\Drupal\Core\TypedData\ComputedItemListTrait. In this class, all you need to do
is implement computeValue() to return your data.
<?php
// The namespace doesn't matter, but I like to put it under \Field.
namespace Drupal\my_module\Field;
use Drupal\Core\Field\FieldItemList;
use Drupal\Core\TypedData\ComputedItemListTrait;
use Drupal\Core\Url;
/**
* Field item list class for my computed field.
*/
class MyFieldFieldItemList extends FieldItemList {
use ComputedItemListTrait;
/**
* {@inheritdoc}
*/
protected function computeValue() {
// You have access to the complete entity, so you can use other field
// values.
$entity = $this->parent->getValue();
// Create a field item for your data. You can create more than one for a
// multi-valued field.
$this->list[] = $this->createItem(0, [
'value' => 'cake',
]);
}
}
?>
For most field types, the key to use in the item array is 'value', but some more specialised fields
use something else. You can find this by looking in the field item class for the
field type. For example, in \Drupal\link\Plugin\Field\FieldType\LinkItem::propertyDefinitions()
you can see that for a link field, you need these array keys:
$this->list[] = $this->createItem(0, [
'title' => $this->t('My link title'),
'uri' => $some_url_that_we-compute->toUriString(),
]);
For the field definition, there are two things to consider:
If it's your own entity type, you define the field in the entity class, in either the baseFieldDefinitions() or bundleFieldDefinitions() method. If it's an existing entity type, you need to use hook_entity_base_field_info() or hook_entity_bundle_field_info().
In all cases, the code is broadly similar. For a base field, it looks like this:
/**
* Implements hook_entity_base_field_info().
*/
#[Hook('entity_base_field_info')]
function entityBaseFieldInfo(EntityTypeInterface $entity_type) {
if ($entity_type->id() == 'node') {
$fields = [];
$fields['my_computed_field'] = BaseFieldDefinition::create('link')
->setLabel($this->t('My computed field'))
->setDescription($this->t('My field is amazing.'))
// This declares it as a computed field.
->setComputed(TRUE)
// This is the class you created earlier, which provides the values.
->setClass(MyFieldFieldItemList::class)
// Optional default view display options, which can be overriden in the admin UI.
->setDisplayOptions('view', [
'label' => 'above',
'type' => 'link',
'weight' => '0',
]);
return $fields;
}
}
For a bundle field, you need the Drupal\entity\BundleFieldDefinition class from Entity module, and a few extra
things need to be explicitly set on the definition because the field system doesn't handle them for you:
$fields['my_computed_field'] = BundleFieldDefinition::create('link')
->setName('my_computed_field')
->setTargetEntityTypeId($entity_type_id)
->setTargetBundle($bundle)
// Rest of the definition as above.
See my earlier blog post on bundle fields for more about their uses and their quirks.
If you want to do it all with less boilerplate, or your computed field is something that's reusable across different entity types, consider the Computed Field module as an alternative to the code examples above. Instead of a Field class, the computational code does in a plugin, which the module then makes available in an admin UI where you can create and edit computed fields alongside the usual stored fields.
And if your computed field is purely a render array rather than data, the Computed Field module
also provides a computed_render_array field type for that, with an accompanying field formatter.
Do you need help with data structures, and their integration with Views or SearchAPI? I'm available for hire - contact me!
Drupal has been working to add a JSON data type since 2023, but that has not landed yet. Drupal Canvas jumps ahead of that in its inputs for a component tree item with
'inputs' => [
'description' => 'The input for this component instance in the component tree.',
'type' => 'json',
'pgsql_type' => 'jsonb',
'mysql_type' => 'json',
'sqlite_type' => 'json',
'not null' => FALSE,
],Recently some of our tests started failing for MySQL and Postgres on CI, but passed in SQLite and MariaDB, which is what most of us use locally.
The problem was that the sorting of the keys of that field was not deterministic, and we used assertSame in our tests to see if operations added/removed the inputs as expected when components evolved.
For MySQL, there's a native data type. Quoting their docs:
To make lookups more efficient, MySQL also sorts the keys of a JSON object. You should be aware that the result of this ordering is subject to change and not guaranteed to be consistent across releases.
For PostgreSQL, the engine offers two different data types: json and jsonb, with the second being the option we (and core) opted for because of its efficiency. But that's key, as the docs explain:
In general, most applications should prefer to store JSON data as
jsonb, unless there are quite specialized needs, such as legacy assumptions about ordering of object keys.
That's exactly what our problem was.
For MariaDB, the JSON type is just an alias. See their docs:
JSON is an alias for
LONGTEXT COLLATE utf8mb4_binintroduced for compatibility reasons with MySQL'sJSONdata type. MariaDB implements this as aLONGTEXTrather, as the JSON data type contradicts the SQL:2016 standard, and MariaDB's benchmarks indicate that performance is at least equivalent.
And the last one, SQLite, has support for a jsonb format since 3.45, but the work in progress for introducing this in Core uses json, which, like MariaDB, is ordinary text and sorting of the keys is respected.
The actual sorting of the inputs in the database is, as of today, irrelevant to us. So we ended up with:
assertSameInputs, which sorts the keys before comparison. assertEqualsCanonicalizing is not an option, as that sorts by value.assertSame with these inputs, and suggests using assertSameInputs instead. This is just one of the many show-stoppers that we faced while working on the much-anticipated symmetric translation support for Drupal Canvas. If you want to test this experimental feature, check the release notes in Canvas 1.7.0, but please only on test sites for now!
Every Drupal developer eventually hits this wall: a client or editor requests that a standard text field (like a headline or subheadline) be expanded from 255 to 512 characters. You change the value in the field configuration YAML or try to update it programmatically via the Entity API, only to be hit with a fatal exception.
read more
Randy Kolenko, partner and senior architect at Nextide, recently joined the Drupal Orchestration Initiative with Jurgen Haas, Shibin Das and Dries Buytaert. The Orchestration Initiative is still in its infancy, however, the discussions and (dis)agreements will continue until the vision of what Orchestration means to Drupal is sharpened.
read moreAs of Rector 2.5, Composer-based sets now support Drupal! This allows you to automate version-specific custom code upgrades seamlessly.
Instead of manually adding dozens of configuration sets and keeping your list up to date as you upgrade to new Drupal releases, you can enable the new feature in your rector.php file. Rector will automatically inspect your composer.json, detect your exact installed versions of Drupal and its dependencies, and run the relevant refactoring sets. This means as you upgrade to newer versions of Drupal in the future, Rector will dynamically adapt and apply the correct upgrade rules without any manual config updates.
Install Drupal Rector with Composer:
composer require --dev palantirnet/drupal-rector:^1.0That pulls in Rector 2.5 or newer, which is where the interesting part lives. Then create a rector.php in your project root:
<?php
declare(strict_types=1);
use DrupalRector\Set\DrupalSetProvider;
use Rector\Config\RectorConfig;
return RectorConfig::configure()
->withPaths([
__DIR__ . '/web/modules/custom',
__DIR__ . '/web/themes/custom',
])
->withSetProviders(DrupalSetProvider::class)
->withComposerBased(twig: TRUE, phpunit: TRUE, symfony: TRUE, drupal: TRUE);And run it:
vendor/bin/rector processTwo lines of configuration does the work: withSetProviders registers the Drupal rules, and withComposerBased(drupal: true) tells Rector to select them based on what's actually installed. No version numbers need to be in your config.
The feature is backed by recent Drupal Rector 1.0.0 beta releases. Although we are still running a beta for Drupal Rector, the composer-based sets landed in Rector 2.5.0. Run it on your custom code, read the diff, and tell us where it's wrong.
Rector reads the installed drupal/core version and loads every set up to and including that minor. A site on 11.4 loads the 11.0 → 11.4 rules. A site on 11.2 loads 11.0 → 11.2. When you upgrade core, the set selection moves with you. You don't need to change rector.php again.
That's the same mechanism Rector already uses for Symfony, Doctrine, Twig, and PHPUnit. Drupal is now a first-class citizen.
But the config was never the hardest part. The hard part was coverage. Automatic version selection is only worth anything if the rules behind it are good and preferably complete. That changed a lot when the Project Update Bot was refreshed for Drupal 12 readiness, pushing automated deprecation coverage past 80%. The bot and drupal-rector draw from the same well. Better coverage there is what made shipping this as the default setup defensible. The fact we also run all these rules against almost 10.000 contrib modules makes for some very good testing.
Even less work maintaing your Drupal site
Drupal rules will also appear on getrector.com/find-rule at a later date. That's the searchable catalogue of every rule Rector ships. Having Drupal in it means a maintainer can look up exactly which transformation handles a given deprecation, the same way they can for any other framework today.
Drupal 12 readiness isn't a one-time push, every new minor brings deprecations, and we will keep on adding any missing coverage. Because your setup selects rules by installed version, the rules you get tomorrow are the rules for the core you're running tomorrow. No migration step. You upgrade core, you run Rector, you're up-to-date.
Add it to a project this week. Point it at your custom modules, run vendor/bin/rector process, and open an issue when something doesn't transform the way it should. It's a beta because we want exactly that. Two lines of config, the correct rules for your version, automatically.
Also posted on Rector’s blog, big thanks to the author of Rector, Tomas Votruba for the collaboration on making this happen.
Digital sovereignty often sounds abstract but, in practice, it comes down to technical decisions: where data is stored, who controls the platform, how systems are maintained over time, and how much privacy, transparency, and independence is built in from the start.
These choices directly affect how digital services are designed and delivered. That is why digital sovereignty is a key theme at DrupalCon Rotterdam 2026. The event’s Digital Sovereignty & Open Web track connects platform strategy with architecture, governance, accessibility, regulation, and the long-term future of open digital ecosystems.
Photo by Matthew Saunders
This is not only a policy discussion, it is also a practical one. Privacy-first architecture, public code, digital identity, accessibility, open-source infrastructure, and responsible AI all shape how organisations think about control and trust today. In that context, digital sovereignty is no longer a side topic, it's becoming part of how teams approach procurement, hosting, compliance, and long-term platform resilience.
That is what makes this conversation especially relevant in Rotterdam. Developers can connect values to implementation, digital leaders can look at governance and long-term control and public sector teams, accessibility advocates, and open-source contributors can all bring important perspectives to the same discussion.
Drupal has long been part of the open web story. At DrupalCon Rotterdam, digital sovereignty becomes a practical question: how do we build systems that remain open, secure, adaptable, and worthy of trust.
- Article by Daniela Moreira.
Continue the conversation at DrupalCon Rotterdam 2026, where the Digital Sovereignty & Open Web track explores the technologies, strategies, and decisions shaping open digital ecosystems.
👉 Register for DrupalCon Rotterdam 2026
Drupal 11.4 is here. Several features landing in this cycle, and across the broader 11.x series, trace back to ideas we explored in contrib first. Worth noting too: Drupal major releases don't introduce new features. The real architectural work happens in the minors, and by the time 12.0 arrives, much of it will already be available, paving the way for the next series of improvements in 12.x.
Here's what we've been working on, and what else is worth knowing about.
dr - a proper Drupal CLI (11.4)The dr CLI entry point lands in Drupal 11.4, and @dpi played a key role in getting it there. His Dex proposal explored what a proper extensible entry point for Drupal CLI commands should look like, and that thinking carried through into the final implementation.
Previously, core/scripts/drupal was limited to running commands defined in core itself. With dr, available at vendor/bin/dr, any module can now register Symfony Console commands via the #[AsCommand] attribute and have them automatically discovered.
use Symfony\Component\Console\Attribute\AsCommand;
use Symfony\Component\Console\Command\Command;
#[AsCommand(name: 'mymodule:do-thing')]
class DoThingCommand extends Command {
// ...
}
It's a small change with a big quality-of-life payoff. Drush has long filled this gap in contrib, but having an extensible CLI built into core is a meaningful step.
Drupal 11.4 adds support for registering entity bundle classes via a PHP attribute, as covered in the change record and original issue. @mstrelan had already proven out the idea in the Bundle Classes Attribute (BCA) contrib module, which lets you do exactly this, rather than going through hook_entity_bundle_info_alter().
Now, instead of wiring up a bundle class via a hook, you annotate the class itself:
use Drupal\Core\Entity\Attribute\Bundle;
use Drupal\node\Entity\Node;
#[Bundle(
entity_type: 'node',
bundle: 'article',
)]
class ArticleNode extends Node {
// Bundle-specific methods here.
}
It's consistent with how plugins and hooks are registered elsewhere in Drupal 11, and it removes the boilerplate that was previously required via a hook in a separate file.
@dpi built Hux in 2022 as a proof of concept: what if Drupal hooks could be implemented in proper PHP classes with dependency injection, instead of procedural .module files? Read the original blog post introducing Hux. It resonated with the community, and became part of the thinking that led to the core OOP hooks initiative that landed in Drupal 11.1.
The core effort has been primarily led by community member @nicxvan, and each release in the 11.x series has pushed the initiative further:
#[Hook] attribute support, autowired services, automatic discovery in src/Hook/Order::First, Order::Last, OrderBefore, OrderAfter), replacing the long-standing hook_module_implements_alter(); preprocess hooks now supportedsrc/Hook/ classes just like modules; Drupal core itself is progressively converting its own hook implementationsThe end state this is heading toward is clear: .module and .theme files will be deprecated. Hooks become services. Drupal-specific patterns that have long been a barrier to onboarding are being replaced with standard PHP and Symfony conventions. It's one of the most significant shifts in developer experience since Drupal 8.
Much of the remaining work, and the path into Drupal 12, involves completing the conversion of core's own hooks, closing edge cases (install hooks are still being worked through), and ensuring contrib has a smooth migration path.
drupalGet() in kernel tests (11.4)Kernel tests are fast, much faster than full functional browser tests, but they've historically been unable to make real HTTP requests. That meant any test involving a route response required a heavier functional test.
The change record introduced drupalGet() to kernel tests, letting them fire actual HTTP requests against a lightweight kernel stack. Most of the underlying work (#3390193) was led by @joachim, allowing us and others to start putting it to use: @mstrelan has been busy converting tests into modules, including help, navigation, and system, and contributing improvements to the trait itself along the way.
If you write Drupal tests, this is worth knowing about. The testing pyramid gets a little more usable.
Claro has been the default admin theme in Drupal core for a while now, but it's showing its age. Gin, which is used by Drupal CMS, is much closer to what you'd expect from a modern CMS admin interface. The answer is to bring Gin into core as the new default_admin theme, replacing Claro as the default for new installations. Claro will remain available for existing sites, but is planned for removal in Drupal 12.
The new theme brings dark mode, accent colour configuration, layout density controls, and the modern feel that Drupal CMS users are already used to. If you've been running Gin in contrib (and many of us have), this is welcome news.
Drupal 11.4 adopts symfony/runtime, which separates the bootstrap process from the entry point. For most sites, this is invisible, but the potential here is significant. symfony/runtime opens the door to running Drupal in new contexts, such as a worker process, serverless, or alongside other Symfony applications, without the bootstrap being tied to a specific entry point. It's an architectural shift that makes Drupal more composable, and one that contrib and hosting tooling can start building on. If you have a custom index.php or non-standard front controller, check the change record before upgrading.
Worth a mention even though it landed in 11.3: HTMX is a tiny, dependency-free JavaScript library that lets you build dynamic, server-driven UIs from HTML attributes rather than custom JavaScript. It was added as a dependency in 11.2, became fully featured in 11.3, and the initiative is still going.
The 11.3 milestone was significant: Drupal's BigPipe streaming was updated to use HTMX, cutting the JavaScript footprint for browser-server interactions by up to 71%, and developers got a Htmx factory class for generating HTMX attributes programmatically alongside extended FormBuilder support for HTMX-driven form rebuilds. But like OOP hooks, this is a multi-release effort. The goal is to progressively replace Drupal's aging, home-grown AJAX and form interaction patterns with something lighter and more standard. Expect the initiative to continue through 11.4 and into Drupal 12.
With Drupal 12 due later this year, thousands of contributed modules and themes will need updating for breaking changes. Doing that by hand across all of contrib would cost the community an enormous number of hours. The Project Update Bot exists to do that automatically: it scans contributed projects, identifies deprecated API uses, and opens issues with ready-to-apply patches. It now covers over 80% of the deprecated APIs being removed in Drupal 12.
If you maintain a contrib module or theme, it's worth checking your issue queue - there may already be a merge request waiting for you.
None of this happens in a vacuum. PreviousNext is Australia's only Top Tier Drupal Certified Partner, and consistently one of the top three global contributors to Drupal core. We invest a significant portion of our time directly into the codebase our clients depend on.
The pattern across our contributions reflects how open source works at its best: we build something in contrib to solve a real problem, the community tests it, refines it, and if it holds up, it finds a home - whether that's core, Drupal CMS, or a well-maintained contrib project. That's how Hux, BCA and Dex all made their way into core
As Drupal 12 takes shape, we'll keep contributing. If you're a developer or agency looking to get more involved, the Drupal issue queue is always open. The best contributions come from people solving real problems, and that's as true today as it's ever been.
