Typography isn’t just a visual asset — it’s a language of its own. Are you ready to allow beautiful fonts to tell their tale and give your website the typographic personality it deserves?
Can AI actually help with real Drupal development? I wanted to find out.
This morning, I fired up Claude Code and pointed it at my personal Drupal site. In a 30-minute session, I asked it to help me build new features and modernize some of my code. I expected mixed results but was surprised by how useful it proved to be.
I didn't touch my IDE once or write a single line of code myself. Claude handled everything from creating a custom Drush command to refactoring constructors and converting Drupal annotations to PHP attributes.
If you're curious what AI-assisted Drupal development actually feels like, the video captures the experience.
While I didn’t speak at any formal sessions this year, I had the chance to lead several Birds-of-a-Feather (BoF) discussions:
php or phpstan or phpunit properly inside a Docker container (like the DDEV web container), so it's hard to use the nice VS Code integration with those tools. DDEV Community member Mike Anello was present and talked about his favorite usage, which involves the Remote Explorer extension. In his long-form Drupal trainings at DrupalEasy he teaches folks to use Remote Explorer with DDEV and work inside the web container all the time, and that solves the problem, but it is different from what DDEV users normally do. (PhpStorm knows how to use tools and interpreters inside the container, so doesn't have this problem.) Mike has presented his technique many times as Maximizing Visual Studio Code with DDEV.git bisect technique went well and we all had a good time. It was based on the Florida Drupal Camp presentation. Here's the git-bisect-example repository. This was a shorter version of the Florida Drupal Camp presentation.The highlight of every DrupalCon is helping new contributors on Contribution Day, a whole day where folks get help contributing for the first time to code, documentation, or marketing. I was able to help a few people, and of course, was the resident DDEV and DrupalPod expert.
I published an invitation to meet one-on-one and a few people took advantage of meeting in person to look at their DDEV issues. It was great to meet them!
Bernardo Martinez shared a room and a DrupalCon ticket, making this whole thing possible.
Platform.sh was kind enough to fund the airline ticket to Atlanta.
Thanks to both of you! I wouldn't have made it without both those things.
This blog has been re-posted and edited with permission from Dries Buytaert's blog.
Three months ago, we launched Drupal CMS 1.0, our biggest step forward in years. Our goal is ambitious: to reimagine Drupal as both radically easier to use and a platform for faster innovation.
In my DrupalCon Atlanta keynote last week, I reflected on the journey so far, but mostly talked about the work ahead. If you missed the keynote, you can watch the video below, or download my slides (56 MB).
If you want to try Drupal CMS, you can explore the trial experience, use the new desktop launcher, or install it with DDEV. If you're curious about what we're working on next, keep reading.
Some of the most common requests from Drupal users and digital agencies is a better page-building experience, simpler theming, and high-quality themes out of the box.
At DrupalCon Atlanta, I shared our progress on Experience Builder. The keynote recording includes two demos: one highlighting new site building features, and another showing how to create and design components directly in the browser.
I also demonstrated how Drupal's AI agents can generate Experience Builder components. While this was an early design experiment, it offered a glimpse into how AI could make site building faster and more intuitive. You can watch that demo in the keynote video as well.
We still have work to do, but we're aiming to release Experience Builder 1.0, the first stable version, by DrupalCon Vienna. In the meantime, try our demo release.
One of the biggest opportunities for Drupal CMS is making it faster and easier to launch a complete website. The introduction of Recipes was a big step forward. I covered Recipes in detail in my DrupalCon Barcelona 2024 keynote. But there is still more we can do.
Imagine quickly creating a campaign or fundraising site for a nonprofit, a departmental website for a university, a portfolio site for a creative agency, or even a travel-focused ecommerce site selling tours, like the one Sarah needed in the DrupalCon Barcelona demo.
This is why we are introducing Site Templates: ready-made starting points for common use cases. They help users go from a fresh install to a fully functional site with minimal setup or configuration.
Site Templates are made possible by Recipes and Experience Builder. Recipes provide higher-level building blocks, while Experience Builder introduces a new way to design and create themes. Site Templates will bring everything together into more complete, ready-to-use solutions.
If successful, Site Templates could replace Drupal distributions, a concept that has been part of Drupal for nearly 20 years. The key advantage is that Site Templates are much easier to build and maintain.
The first Site Templates may be included directly in Drupal CMS 2.0 itself. Over time, we hope to offer hundreds of site templates through a marketplace on Drupal.org.
At DrupalCon Atlanta, I announced that we'll be exploring a marketplace for Site Templates, including the option for Commercial Site Templates. We believe it's an idea worth evaluating because it could bring several benefits to the Drupal project:
You can watch the keynote recording to learn more. I also plan to publish a detailed blog post in the next few days. If you're interested, consider subscribing to my blog.
Drupal CMS has brought a lot of fresh momentum to the Drupal project, but we're not done yet! The rest of this year, we'll keep building on this foundation with a clear set of priorities:
If you have time and interest, please consider getting involved. Every contribution makes a difference. Not sure where to begin? Join us on Drupal Slack. We're always happy to welcome new faces. Key channels include #drupal-cms-development, #ai, #experience-builder, #drupal-cms-templates, and #drupal-cms-marketplace.
As I said in the keynote: "We have all the pieces, now we just need to bring them together!"
This blog has been re-posted and edited with permission from Dries Buytaert's blog.
This post looks at the idea of a Drupal Site Template marketplace and whether it should support both open source and commercial templates.
This is an unusual post for my blog, but I'm sharing it to start a broader conversation about an idea we're exploring: a marketplace for Drupal Site Templates. Both the Drupal CMS Leadership Team and the Drupal Association have discussed this concept, but no decision has been made. I'm posting to share our current thinking and invite feedback as we shape this together.
This post is being cross-posted here, and the comments are open. You're also welcome to join the conversation in the #drupal-cms-marketplace channel on Drupal Slack.
In my DrupalCon Atlanta keynote, I introduced the concept of Site Templates for Drupal. These templates provide pre-configured website starting points that combine Drupal recipes, themes, and default content.
If you haven't seen my keynote yet, I recommend watching it first. It provides helpful context for the rest of this post.
While Site Templates will help users launch websites faster, I also posed a bigger question: should we create a marketplace where users can discover and download or install these templates? And if so, should that marketplace offer only open source Site Templates, or should we also allow commercial templates?
Site Templates combine Drupal recipes, a theme, design elements, and default content to give users a fully functional website right from the start. They solve one of Drupal's biggest challenges: the time it takes to build a site from scratch.
Unlike a bare Drupal installation, a Site Template provides all the components needed for a specific use case. A restaurant template might include menu management, reservation systems, and food photography. A nonprofit template could feature donation processing, event management, and impact reporting tools.
A Drupal marketplace for Site Templates would:
Fully open source Site Templates align naturally with Drupal's values. They could function much like community-contributed modules and themes, and we hope that many contributors will take this approach.
A marketplace requires ongoing investment. The Drupal Association would need to maintain the platform, review submissions, provide support, and ensure templates meet high standards. Without dedicated resources, quality and sustainability would suffer.
This is why supporting both open source and commercial templates makes sense. Paid templates can create a sustainable revenue stream to fund infrastructure, quality control, and support.
Commercial incentives also give creators a reason to invest in polished, well-documented, and well-supported templates.
First, rest assured: Drupal modules will always be open source.
Drupal is licensed under the GNU General Public License, or GPL. We've always taken a conservative approach to interpreting the GPL. In practice, this means we treat any code that builds on or interacts closely with Drupal as subject to the GPL. This includes PHP, Twig templates, etc. If it relies on Drupal's APIs or is executed by Drupal, it must be GPL-licensed.
Some parts of a site template fall into a gray area. JavaScript is an example. If JavaScript code is integrated with Drupal, we treat it as GPL-covered. If JavaScript code is standalone, such as a self-contained React component, it may not be considered a derivative work. The same may apply to CSS or configuration files not tightly coupled with Drupal APIs. These cases aren't always clear, but our stance has been to treat all code that ships with and interacts with Drupal as GPL. This keeps things simple.
Other parts of a Site Template are likely not subject to the GPL. Assets like images, fonts and icons are not code and are not derived from Drupal. The same applies to demo content, such as placeholder text or sample articles. These elements are not integrated with Drupal in a technical sense and can use other licenses, including commercial ones.
So when we talk about a commercial Site Template, we mean one that combines open source code with separately licensed assets or is sold alongside value-added services like documentation, support, or updates.
While the legal distinction clarifies which parts of a Site Template can be licensed commercially, it's only part of the picture. The real question is the value proposition: what are users actually paying for when they choose a commercial template?
When purchasing a commercial template, users wouldn't just be paying for code. They're potentially paying for:
This approach aligns with the Free Software Foundation's stance (the organization that created the GPL), which has always supported commercial distribution of free software. Creating a commercial template means balancing open source code with separately licensed assets. However, the real commercial value often extends beyond just the files you can license differently.
A sustainable commercial strategy combines proper licensing with controlled distribution channels and value-added services, like support. This approach ensures the value of a site template isn't limited to easily copied assets, but includes expertise that can't be simply downloaded. This is how a template can be commercial while staying true to Drupal's open source values.
A marketplace filled with low-quality or abandoned templates would damage Drupal's reputation. To ensure quality we probably need:
These quality assurance measures require ongoing time, effort, and funding. This is why including a commercial component makes sense. A revenue-sharing model with template creators could help fund platform maintenance, reviews, support, and other efforts needed to keep the marketplace high quality and trustworthy.
We don't know yet, but we've heard many good suggestions from the community.
Ideas include one-time purchases for unlimited use, annual subscriptions with ongoing updates, and a marketplace membership model for template creators.
The marketplace could support multiple approaches, giving creators flexibility to choose what works best for their offerings.
When a site template is sold commercially, it raises an important question. What about the maintainers of the modules included in the template? The template builder receives payment. The Drupal Association may collect a revenue share. But the individual contributors who created the modules or core functionality do not receive direct compensation, even though their work is essential to the Site Template.
This may feel frustrating or unfair. Contributors often donate their time to improve Drupal for everyone. Seeing others earn money by building on that work without recognition can be disheartening, and could even discourage future contributions. It's an important concern, and one we plan to take seriously as we evaluate the marketplace model.
At the same time, this dynamic is not new. Agencies and developers already build paid Drupal sites using contributed modules without directly compensating the people who made the underlying code possible. This is both legal, expected, and common in open source.
A marketplace would not create this reality, but it would make it more visible. That visibility gives us a chance to confront a long-standing tension in open source: the gap between those who contribute foundational work and those who profit from it. As I wrote in Makers and Takers, sustaining open source requires a better balance between contribution and benefit. A marketplace could give us a way to explore new approaches to recognize, support, and sustain the people who make Drupal possible. Transparency alone won't solve the issue, but it opens the door to progress and experimentation.
When commercial activity happens off Drupal.org, there is no way to recognize the contributors who made it possible. When it happens on Drupal.org, we have an opportunity to do better. We can explore models for financial support, community recognition, and long-term sustainability.
Others could build marketplaces for Drupal templates, but these would likely focus on profit rather than community support. An official Drupal Association marketplace allows us to reinvest in the project and the people behind it. It keeps value within our ecosystem, and gives us a platform to explore more equitable ways to sustain open source contribution.
Many organizations pay thousands of dollars to digital agencies as part of a custom Drupal build. If Site Templates are available at a much lower cost, will that undercut agencies?
I don't believe it will.
Organizations investing in a Drupal website are not paying for a theme alone. Agencies provide strategy, consulting, design, customization, user testing, performance optimization, and long-term support. A template offers a starting point, but doesn't replace tailored work or a trusted partnership.
A template marketplace could expand the Drupal ecosystem by lowering the barrier to entry, making Drupal accessible to smaller organizations. Some of these will grow and require custom solutions, creating more opportunities for agencies in the long run.
Templates can also serve as powerful demonstrations of an agency's capabilities, attracting clients who want similar but customized solutions. For agencies, templates become both a product and a marketing tool.
A template marketplace offers two revenue streams for Drupal agencies and freelancers.
First, agencies would earn direct income from template sales through revenue-sharing with the Drupal Association. While this income might be modest, it could provide recurring revenue as the marketplace grows.
Second, templates could serve as a foundation for more comprehensive service packages, including hosting, maintenance, and customization services.
A marketplace could connect end users directly with service providers. With proper consent, contact details from template purchases could be shared with creators, opening the door to professional service opportunities. Template listings could also include a built-in contact form, making it easy for users to request customization or support.
This lead generation benefits both sides. Users access trusted professionals who understand their implementation, while agencies connect with qualified prospects who have already invested in their work. A marketplace becomes a matchmaking platform connecting those who need Drupal expertise with those who provide it.
With Drupal CMS, we're focused on growth. To succeed, we need to address two long-standing challenges: the lack of ready-made themes and a steep learning curve. Some of our new tools (Recipes, Experience Builder, and Site Templates) allow us to address these longstanding issues.
The result? We can take Drupal's flexibility and make it more available across different markets and use cases.
The day after my keynote, we organized a Birds of a Feather (BoF) session to discuss the marketplace concept. Approximately 75 people attended, representing a cross-section of our community.
The discussion was lively and constructive. Participants raised thoughtful concerns about quality control, licensing, and impact on module contributors. They also offered suggestions for implementation, pricing, and sustainability models.
At the session's conclusion, we informally polled the audience. We asked people to raise their hand showing 1 finger if they thought a marketplace was a terrible idea, and 5 if they considered it a very impactful idea. Most responses were 4, with some 5s. Very few people indicated less than 3.
This initial reaction is encouraging, though we recognize that much work remains to address the questions raised during the session.
We also opened the #drupal-cms-marketplace channel in Drupal Slack to continue the conversation with the wider community.
The Drupal CMS Leadership Team and the Drupal Association Innovation Working Group have been exploring this idea the past month.
We believe it could be one of our strongest opportunities to grow Drupal adoption, support our Maker community, and strengthen the Drupal Association. (As a disclaimer: I serve on both the Drupal CMS Leadership Team and the Drupal Association Board of Directors.)
To be clear, no decision has been made. We recognize this initiative would have a substantial impact on our community and ecosystem. Before moving forward, we need to assess:
We cannot and should not make these assessments in isolation. We need the Drupal community's involvement through:
Our goal is to make a decision by DrupalCon Vienna, 6 months from now, or sooner if clarity emerges. We want that decision to reflect input from the CMS Leadership Team, the Drupal Association Board, Certified Drupal Partners, and the wider Drupal community.
We're chartering a Marketplace Working Group with stakeholders from across the Drupal ecosystem. I'm pleased to announce that Tiffany Farriss (Drupal Association Board Member) has agreed to lead this effort. Please join the #drupal-cms-marketplace channel on Drupal Slack to share your thoughts and follow the conversation.
Drupal's greatest strength has always been its community and adaptability. I believe that by thoughtfully exploring new ideas together, we can make Drupal more accessible and widely adopted while staying true to our core values.
Thank you to everyone on the Drupal Association Innovation Working Group and the Drupal CMS Leadership Team who took the time to review this post and share thoughtful feedback. I really appreciate your input.
This is an unusual post for my blog, but I'm sharing it to start a broader conversation about an idea we're exploring: a marketplace for Drupal Site Templates. Both the Drupal CMS Leadership Team and the Drupal Association have discussed this concept, but no decision has been made. I'm posting to share our current thinking and invite feedback as we shape this together.
This post will also be cross-posted to Drupal.org, where comments are open. You're also welcome to join the conversation in the #drupal-cms-marketplace channel on Drupal Slack.
In my DrupalCon Atlanta keynote, I introduced the concept of Site Templates for Drupal. If you haven't seen my keynote yet, I recommend watching it first. It provides helpful context for the rest of this post.
Site Templates provide pre-configured website starting points that combine Drupal recipes, themes, and default content. While Site Templates will help users launch websites faster, I also posed a bigger question: should we create a marketplace where users can discover and download or install these templates? And if so, should that marketplace offer only open source Site Templates, or should we also allow commercial templates?
Site Templates combine Drupal recipes, a theme, design elements, and default content to give users a fully functional website right from the start. They solve one of Drupal's biggest challenges: the time it takes to build a site from scratch.
Unlike a bare Drupal installation, a Site Template provides all the components needed for a specific use case. A restaurant template might include menu management, reservation systems, and food photography. A nonprofit template could feature donation processing, event management, and impact reporting tools.
A Drupal marketplace for Site Templates would:
Fully open source Site Templates align naturally with Drupal's values. They could function much like community-contributed modules and themes, and we hope that many contributors will take this approach.
A marketplace requires ongoing investment. The Drupal Association would need to maintain the platform, review submissions, provide support, and ensure templates meet high standards. Without dedicated resources, quality and sustainability would suffer.
This is why supporting both open source and commercial templates makes sense. Paid templates can create a sustainable revenue stream to fund infrastructure, quality control, and support.
Commercial incentives also give creators a reason to invest in polished, well-documented, and well-supported templates.
First, rest assured: Drupal modules will always be open source.
Drupal is licensed under the GNU General Public License, or GPL. We've always taken a conservative approach to interpreting the GPL. In practice, this means we treat any code that builds on or interacts closely with Drupal as subject to the GPL. This includes PHP, Twig templates, etc. If it relies on Drupal's APIs or is executed by Drupal, it must be GPL-licensed.
Some parts of a site template fall into a gray area. JavaScript is an example. If JavaScript code is integrated with Drupal, we treat it as GPL-covered. If JavaScript code is standalone, such as a self-contained React component, it may not be considered a derivative work. The same may apply to CSS or configuration files not tightly coupled with Drupal APIs. These cases aren't always clear, but our stance has been to treat all code that ships with and interacts with Drupal as GPL. This keeps things simple.
Other parts of a Site Template are likely not subject to the GPL. Assets like images, fonts and icons are not code and are not derived from Drupal. The same applies to demo content, such as placeholder text or sample articles. These elements are not integrated with Drupal in a technical sense and can use other licenses, including commercial ones.
So when we talk about a commercial Site Template, we mean one that combines open source code with separately licensed assets or is sold alongside value-added services like documentation, support, or updates.
While the legal distinction clarifies which parts of a Site Template can be licensed commercially, it's only part of the picture. The real question is the value proposition: what are users actually paying for when they choose a commercial template?
When purchasing a commercial template, users wouldn't just be paying for code. They're potentially paying for:
This approach aligns with the Free Software Foundation's stance (the organization that created the GPL), which has always supported commercial distribution of free software. Creating a commercial template means balancing open source code with separately licensed assets. However, the real commercial value often extends beyond just the files you can license differently.
A sustainable commercial strategy combines proper licensing with controlled distribution channels and value-added services, like support. This approach ensures the value of a site template isn't limited to easily copied assets, but includes expertise that can't be simply downloaded. This is how a template can be commercial while staying true to Drupal's open source values.
A marketplace filled with low-quality or abandoned templates would damage Drupal's reputation. To ensure quality we probably need:
These quality assurance measures require ongoing time, effort, and funding. This is why including a commercial component makes sense. A revenue-sharing model with template creators could help fund platform maintenance, reviews, support, and other efforts needed to keep the marketplace high quality and trustworthy.
We don't know yet, but we've heard many good suggestions from the community.
Ideas include one-time purchases for unlimited use, annual subscriptions with ongoing updates, and a marketplace membership model for template creators.
The marketplace could support multiple approaches, giving creators flexibility to choose what works best for their offerings.
When a site template is sold commercially, it raises an important question. What about the maintainers of the modules included in the template? The template builder receives payment. The Drupal Association may collect a revenue share. But the individual contributors who created the modules or core functionality do not receive direct compensation, even though their work is essential to the Site Template.
This may feel frustrating or unfair. Contributors often donate their time to improve Drupal for everyone. Seeing others earn money by building on that work without recognition can be disheartening, and could even discourage future contributions. It's an important concern, and one we plan to take seriously as we evaluate the marketplace model.
At the same time, this dynamic is not new. Agencies and developers already build paid Drupal sites using contributed modules without directly compensating the people who made the underlying code possible. This is both legal, expected, and common in open source.
A marketplace would not create this reality, but it would make it more visible. That visibility gives us a chance to confront a long-standing tension in open source: the gap between those who contribute foundational work and those who profit from it. As I wrote in Makers and Takers, sustaining open source requires a better balance between contribution and benefit. A marketplace could give us a way to explore new approaches to recognize, support, and sustain the people who make Drupal possible. Transparency alone won't solve the issue, but it opens the door to progress and experimentation.
When commercial activity happens off Drupal.org, there is no way to recognize the contributors who made it possible. When it happens on Drupal.org, we have an opportunity to do better. We can explore models for financial support, community recognition, and long-term sustainability.
Others could build marketplaces for Drupal templates, but these would likely focus on profit rather than community support. An official Drupal Association marketplace allows us to reinvest in the project and the people behind it. It keeps value within our ecosystem, and gives us a platform to explore more equitable ways to sustain open source contribution.
Many organizations pay thousands of dollars to digital agencies as part of a custom Drupal build. If Site Templates are available at a much lower cost, will that undercut agencies?
I don't believe it will.
Organizations investing in a Drupal website are not paying for a theme alone. Agencies provide strategy, consulting, design, customization, user testing, performance optimization, and long-term support. A template offers a starting point, but doesn't replace tailored work or a trusted partnership.
A template marketplace could expand the Drupal ecosystem by lowering the barrier to entry, making Drupal accessible to smaller organizations. Some of these will grow and require custom solutions, creating more opportunities for agencies in the long run.
Templates can also serve as powerful demonstrations of an agency's capabilities, attracting clients who want similar but customized solutions. For agencies, templates become both a product and a marketing tool.
A template marketplace offers two revenue streams for Drupal agencies and freelancers.
First, agencies would earn direct income from template sales through revenue-sharing with the Drupal Association. While this income might be modest, it could provide recurring revenue as the marketplace grows.
Second, templates could serve as a foundation for more comprehensive service packages, including hosting, maintenance, and customization services.
A marketplace could connect end users directly with service providers. With proper consent, contact details from template purchases could be shared with creators, opening the door to professional service opportunities. Template listings could also include a built-in contact form, making it easy for users to request customization or support.
This lead generation benefits both sides. Users access trusted professionals who understand their implementation, while agencies connect with qualified prospects who have already invested in their work. A marketplace becomes a matchmaking platform connecting those who need Drupal expertise with those who provide it.
With Drupal CMS, we're focused on growth. To succeed, we need to address two long-standing challenges: the lack of ready-made themes and a steep learning curve. Some of our new tools (Recipes, Experience Builder, and Site Templates) allow us to address these longstanding issues.
The result? We can take Drupal's flexibility and make it more available across different markets and use cases.
The day after my keynote, we organized a Birds of a Feather (BoF) session to discuss the marketplace concept. Approximately 75 people attended, representing a cross-section of our community.
The discussion was lively and constructive. Participants raised thoughtful concerns about quality control, licensing, and impact on module contributors. They also offered suggestions for implementation, pricing, and sustainability models.
At the session's conclusion, we informally polled the audience. We asked people to raise their hand showing 1 finger if they thought a marketplace was a terrible idea, and 5 if they considered it a very impactful idea. Most responses were 4, with some 5s. Very few people indicated less than 3.
This initial reaction is encouraging, though we recognize that much work remains to address the questions raised during the session.
We also opened the #drupal-cms-marketplace channel in Drupal Slack to continue the conversation with the wider community.
The Drupal CMS Leadership Team and the Drupal Association Innovation Working Group have been exploring this idea the past month.
We believe it could be one of our strongest opportunities to grow Drupal adoption, support our Maker community, and strengthen the Drupal Association. (As a disclaimer: I serve on both the Drupal CMS Leadership Team and the Drupal Association Board of Directors.)
To be clear, no decision has been made. We recognize this initiative would have a substantial impact on our community and ecosystem. Before moving forward, we need to assess:
We cannot and should not make these assessments in isolation. We need the Drupal community's involvement through:
Our goal is to make a decision by DrupalCon Vienna, 6 months from now, or sooner if clarity emerges. We want that decision to reflect input from the CMS Leadership Team, the Drupal Association Board, Certified Drupal Partners, and the wider Drupal community.
We're chartering a Marketplace Working Group with stakeholders from across the Drupal ecosystem. I'm pleased to announce that Tiffany Farriss (Drupal Association Board Member) has agreed to lead this effort. Please join the #drupal-cms-marketplace channel on Drupal Slack to share your thoughts and follow the conversation.
Drupal's greatest strength has always been its community and adaptability. I believe that by thoughtfully exploring new ideas together, we can make Drupal more accessible and widely adopted while staying true to our core values.
Thank you to everyone on the Drupal Association Innovation Working Group and the Drupal CMS Leadership Team who took the time to review this post and share thoughtful feedback. I really appreciate your input.
demet
Wed, 04/02/2025 - 08:50
What I learned and how you can get the most out of the DrupalCon experience
After nearly a decade at Palantir.net, and even longer in the world of Drupal, I finally took the plunge and attended my first DrupalCon! I’d previously attended a few other community events like MidCamp and Texas Camp, but DrupalCon always felt like a more intimidating undertaking. Between project deadlines and a desire to be mindful of my professional development budget, it never seemed to align. With all of the innovation happening in the AI and Experience Builder space, I decided to take the plunge this year and attend. I’m really glad I did!
The experience was extremely valuable, and here are my key takeaways for others looking to attend their first DrupalCon:
My first lesson was learned the hard way. I walked into my initial session just a few minutes before it started, only to find a packed room where I was forced to stand in the back behind a support pillar. This isn’t a college lecture — seats and space aren’t guaranteed! I made a mental note to attend other sessions that I thought would be popular a few minutes early.
Despite a lot of attendees, everyone I met was incredibly friendly and approachable. I’m pretty introverted by nature, but small talk proved to be a fantastic way to connect with fellow Drupalers. I found myself waiting for a fresh supply of hot water to make a cup of tea with some fellow attendees. It turned out to be an opportune time to pick their brains about a dashboard initiative I’ve been looking into. If you need help, use my favorite way to break the ice — a deprecating joke about Drupal.
I was pleasantly surprised by the number of familiar faces I encountered. Former colleagues, individuals I’d heard about in the Drupal space, and even online acquaintances were all there. It was a fantastic opportunity to connect in person and put faces to names. For example, I ran into Bálint in the expo hall after attending a session he hosted the day before and got to pick his brain with some questions I had about Experience Builder.
The often repeated phrase, "come for the code, stay for the community," really resonated with me. The energy and passion within the Drupal community is real. I left feeling inspired and motivated to contribute back to this incredible open-source project. It left a salient reminder that this project is successful because a bunch of people like me contribute their time and talent. If I want Drupal to be successful, it takes my contributions, too.
Both spending some time at the Palantir booth talking to passers by and taking a few laps around the exhibit hall was well worth it. I had a lot of great and insightful conversations with vendors, partners, and even competitors. It’s nice to get on-the-ground insight into the latest trends within the Drupal ecosystem. And yes, the swag and snacks were a nice bonus! My favorite souvenir was a retro-styled Atlanta poster that I brought home to commemorate my first DrupalCon.
For years, I've been hesitant to propose a session at DrupalCon. This experience helped break down that intimidation. I realized that it's not as daunting as I imagined, and I'm determined to submit a proposal for a future DrupalCon. The Drupal space is large, and we’re all working on really cool stuff. I’m determined to capture learnings from my projects and share them out with the larger community.
All in all, my first DrupalCon was an unforgettable experience. I highly recommend it to anyone involved in the Drupal community, and I'm already looking forward to attending DrupalCon Chicago in 2026!
Thanks to sponsorship from the TYPO3 Community Budget Ideas, DDEV now includes XHGui support for its XHProf profiling. This brings a much-improved experience with a consistent, browser-based interface.
DDEV has had XHProf profiling for some time, and many in the community have loved it, but it had a few flaws; the list of profiling runs was ugly and uncoordinated, and the list was lost on ddev restart.
However, the longstanding XHGui project was out there for years, and it made much more sense.
With XHGui, you can now track performance bottlenecks with a clean interface, persistent data, and detailed breakdowns of CPU and memory usage.
In DDEV v1.24.4+ you can switch to the XHGui profiling mode (permanently) with
ddev config global --xhprof-mode=xhgui && ddev restart
Start profiling with
ddev xhgui on
Visit a few pages in your app to collect profiling data, then
ddev xhgui launch
In general, click one of the GET or POST links and follow it in to explore detailed CPU and memory usage breakdowns.
If you have questions, join us in one of the DDEV support venues, especially Discord and we'll work it through with you.
The DDEV Docs on XHProf have some good starters, but your suggestions are welcome!
Here's a quick demonstration of using XHGui with a TYPO3 site in DDEV.
Serious thanks are due to:
Try it out today and let us know how it goes — your feedback helps shape the future of DDEV! Join us in the DDEV support venues if you want to talk about XHGui and profiling.