2026 Plans and Notes

Every year we try to lay out a bit of a plan for the coming year.

One of DDEV's primary strengths is our connection to a wonderful community, so each year turns out a bit different than expected. As we listen to people's actual experience, we try to adjust. And of course as upstream changes bring new features and bugs, we get lots of fun things to work on that we could never have anticipated. The items listed here are notes about what we think we understand at this point, but the year ahead and user experience and requests will affect what really happens.

We look forward to your input as the year goes forward.

Community

Community is core to our strength and growth. We are committed to maintaining the outstanding support that we offer for free and keeping that communication line open. And we want to continue to grow the amazing corps of contributors who offer improvements to the DDEV ecosystem.

Board of Directors

In 2025 we established Board of Directors, but now we have to learn what that means. The Board will have to establish itself, begin helping to determine priorities, and find its way to a strong oversight role. Here are a few issues to toss to the board early:

• Governance strategy and technique. Meetings? Voting?
• Overall Marketing/Fundraising strategy, including Fundraising drive
• Consider spending more on AI (Higher level of Claude Code plans)
• Discuss and create AI strategy, including policy, guidelines, tools, etc.
• How many conferences to attend (and what conferences) and spending priorities
• Should we move toward a Freemium model with "premium" features? What infrastructure and code would be required?

Features and Initiatives

• Consider a general AI strategy for DDEV users. How can we support the community in its use of AI for web development? Many platforms (like Laravel) have explicit MCPs; people want to know how to use them with DDEV.
• Update macOS install blog + Xdebug usage blog (carried forward from 2025)
• AI Sandboxing as key DDEV feature (from issue)
• Consider MCP (for projects) as key DDEV feature
• Consider MCP for DDEV (experimental PR)
• Integration of mkcert CA without use of external mkcert tool
• Start a project without ddev config, Consider offering ddev config --auto or ddev config when ddev start in a directory without config (issue)
• Explore using real certificates instead of mkcert CA
• Subdomains for extra ports/services instead of separate ports. (Prereq for some web-based setups like coder). See the blog on this approach.
• Coder support for subdomains. Could codespaces use some proxy/redirect technique to route subdomains to main item, but have a header that determined how traefik would route it?
• Use a DDEV proxy on the host to allow commands like ddev list and ddev describe and ddev launch to work from inside the web container.
• Explore moving Mutagen completely into container (syncing between volume and bind-mount)
• Improved management of .ddev/.env* files, marking DDEV-owned lines, etc.
• More work on web-based setups like Coder and Codespaces and Dev Containers in general.
• Explore environment adjustments that might let users work "inside the web container" as if they were on a real host (use composer instead of ddev composer, etc). People can already do this with ddev ssh, but that isn't directly compatible with VS Code or PhpStorm.
• Serialize concurrent runs of ddev start and similar commands.
• Move the DDEV IntelliJ/PhpStorm plugin to the DDEV organization.

Procedures

• Randy and Stas have always done timekeeping and timesheet reporting, but will improve their reporting a bit with categories/projects in 2026. discussion.
• Explore additional benefits of being open source and 501(c)(3) nonprofit. We have a number of benefits already, including GitHub nonprofit status, etc. But we can probably get additional benefits from AWS, etc. (JetBrains and Docker also provide us open source benefits.)

2026 Planning Additional Notes

Recognized Risks

We are a very small organization, so we try to pay careful attention to the risks as we go forward. In many ways, these are the same as the 2025 noted risks.

• Key maintainer Stas lives in a very volatile situation in Ukraine, and none of us knows how to predict the future. Physical risks, communication risks, and financial transfer risks are always possible.
• Randy is not young and can always face new risks.
• The financial outlook for discretionary funding from agencies and hosting companies (and perhaps individuals) remains horrible.
• Any of our maintainers can become overworked or discouraged or can burn out. We take the risk of burnout and overwork very seriously and are careful to talk about them and try to prevent them.
• Mutagen maintenance and future: Mutagen is a critical part of DDEV, and it's in maintenance-only mode since Jacob went to work for Docker. It's outstanding in quality, so should last, and Jacob has been responsive when there are problems. Its future is not clear.
• Scope expansion could be unsustainable. We support so many different environments, and our testing is so enormous. Without the current expertise, we couldn't maintain the existing scope.

Minor Notes

Past Plans and Reviews

Previous plans and reviews have obviously framed this year's plans: 2025 Plans and 2024 review, 2024 plans

In preparing for this, we have been discussing these things in regular advisory group meetings and a specific brainstorming meeting.

We always want to hear from you about your experiences with DDEV as the year goes along!

Want to keep up as the month goes along? Follow us on:

• Monthly Newsletter
• blog
• LinkedIn
• Mastodon
• Bluesky
• and join our community on Discord

Drupal turns 25 today. A quarter of a century.

What started as a hobby became a community, and then, somehow, a pillar of the web's infrastructure.

Looking back, the most important things I learned weren't really about software. They were about people, scale, and what it takes to build something that lasts.

Twenty-five years, twenty-five lessons.

1. You can do well and do good

I used to think I had to choose: build a sustainable business or build something generous. Drupal taught me that is a false choice. Growth and generosity can reinforce each other. The real challenge is making sure one does not crowd out the other.

2. You can architect for community

Community doesn't just happen. You have to design for it. Drupal's modular system created clear places to contribute, our open logo invited people to make their own variants, and our light governance made it easy for people to step into responsibility. You cannot force a community to exist, but you can create the conditions for one to grow.

3. A few decisions define everything

Most choices don't matter much in hindsight, but a few end up shaping a project's entire trajectory. For Drupal, that included licensing under the GPL, the hook system, the node system, starting the Drupal Association, and even the credit system. You never know which decisions those are when you're making them.

4. Coordination is the product

In the early days, coordination was easy: you knew most people by name and you could fix things in a single late night IRC conversation. Then Drupal grew, slowly at first and then all at once, and I remember release cycles where the hardest part was not the code but aligning hundreds of people across time zones, cultures, companies, and priorities, with far too much energy spent "bike shedding". That is when I learned that at scale, code is not the product. It is what we ship, but coordination is what makes it possible.

5. Everyone's carrying something

I've worked with people navigating challenges I couldn't see at first. Mental health struggles, caregiving burdens, personal crises. It taught me that someone's behavior in a moment rarely tells the whole story. A healthy community makes room for people. Patience and grace are how you keep good people around.

6. Nobody fully understands Drupal anymore, including me

After 25 years and tens of thousands of contributors, Drupal has grown beyond any single person's understanding. I also google Drupal's documentation. I'm strangely proud of that, because it's how I know it has become something bigger than any one of us.

7. Volunteerism alone doesn't scale

In the early years, everything in Drupal was built by volunteers, and for a long time that felt like enough. At some point, it wasn't. The project was growing faster than the time people could give, and some important work needed more hands. Paid contributors brought stability and depth, while volunteers continued to innovate. The best projects make room for both.

8. Your words carry more weight than you realize

As recently as a few weeks ago, I sent a Slack message I thought was harmless and watched it create confusion and frustration. I have been making that same mistake, in different forms, for years. As a project grows, so does the gravity of what you say. A passing comment can redirect weeks of work or demoralize someone who is trying their best. I had to learn to speak more carefully, not because I am important, but because my role is. I am still learning to do this better.

9. Maintenance is leadership with no applause

The bottleneck in Open Source is rarely new ideas or new code. It's people willing to maintain what already exists: reviewing, deciding, onboarding new people, and holding context for years. I have seen projects stall because nobody wanted to do that work, and others survive because a few people quietly stepped up. Maintainers do the work that keeps everything together. If you want a project to last, you have to take care of your maintainers.

10. Culture is forged under stress

The Drupal community was not just built on good vibes. It was built in the weeks before releases and DrupalCons, in late night debugging sessions, and in messy moments of disagreement and drama. I have seen stress bring out the best in us and, sometimes, the worst. Both mattered because they forced us to learn how to disagree, decide, and recover. Those hard moments forged trust you cannot manufacture in calm times, and they are a big reason the community is still here.

11. Leadership has to outgrow its founder

For Drupal to last, leadership had to move beyond me, and for that to happen I had to let go. That meant stepping back from decisions I cared deeply about and trusting others to take the project in directions I might not have chosen. There were moments when I felt sidelined in the project I started, which was nobody's fault, but not easy. Letting go was not always easy, but it is one of the reasons Drupal is still here.

12. Open source is not a meritocracy

I used to say that the only real limitation to contributing was your willingness to learn. I was wrong. Free time is a privilege, not an equal right. Some people have jobs, families, or responsibilities that leave no room for unpaid work. You can only design for equity when you stop pretending that Open Source is a meritocracy.

13. Changing your mind in public builds trust

Over the years, I've had to reverse positions I once argued for. Doing that in public taught me that admitting you were wrong builds more trust than claiming you were right. People remember how you handle being wrong longer than they remember what you were wrong about.

14. Persistence beats being right early

In 2001, Open Source was a curiosity that enterprises avoided. Now it runs the world. I believed in it long before I could prove it, and I kept working anyway. It took many years before the world caught up, and I learned that sticking with something you believe in matters more than being right quickly.

15. The hardest innovation is not breaking things

For years, I insisted that breaking backward compatibility was a core value. Upgrades were painful, but I thought that was the price of progress. The real breakthrough came when we built enough test coverage to keep moving forward without breaking what people had built. Today, Drupal has more than twice as much test code as production code. That discipline was harder than any rewrite, and it earned more trust than any new feature.

16. Most people are here for the right reasons

Every large community has bad actors and trolls, and they can consume all your attention if you let them. If you focus too much on the worst behavior, you start to miss the quiet, steady work of the many people who are here to build something good. Your energy is better spent supporting those people.

17. Talk is silver. Contribution is gold

Words matter. They set direction and invite people in. But the people who shaped Drupal most were the ones who kept showing up to do the work. Culture is shaped by what actually gets done, and by who shows up to do it.

18. Vision doesn't have to come from the top

For a long time, I thought being project lead meant having the vision. Over time, I learned that it meant creating the conditions for good ideas to come from anywhere. The best decisions often came from people I'd never met, solving problems I didn't know we had.

19. The spark is individual but the fire is not

A single person can change a project's direction, but no contribution survives on its own. Every new feature comes with a maintenance cost and eventually depends on people the original author will never meet. Successful projects have to hold both truths at once: the spark is individual, but the fire is not.

20. At scale, even your bugs become features

Once enough people depend on your software, every observable behavior becomes a commitment, whether you intended it or not. Sooner or later, someone will build a workflow around an edge case or quirk. That is why maintaining compatibility is not a lesser form of work. It is core to the product.

21. A good project is measured by what people build next

For a long time, it felt like a loss when top contributors moved on from Drupal. Over time, I started to notice what they built next and realized they were carrying what they learned here into everything they did. Many went on to lead teams, start companies, or build new Open Source projects. I have come to see that as one of Drupal's most meaningful outcomes.

22. Longevity comes from not chasing trends

Drupal is still here because we resisted the urge to chase every new trend and kept building on things that last, like structured content, security, extensibility, and openness. Those things mattered twenty years ago, they still matter today, and they will still matter twenty years from now.

23. If it matters, keep saying it

A community isn't a room. People join at different times, pay attention to different things, and hear through different filters. An idea has to land again and again before it takes hold. If it matters, keep saying it. The ideas that stick are the ones the community picks up and carries forward.

24. It takes a community to see the whole road

Sometimes the path forward seems clear, but it takes the perspective of a community to see the cracks, the forks, and the doubts. Being right alone brings clarity. Bringing others along brings confidence.

25. Start before you feel ready

When I released Drupal 1.0.0, I knew almost nothing. For much of the journey, I felt out of my depth. I was often nervous, sometimes intimidated. I didn't know how to scale software, how to build a community, or how to lead. I kept shipping anyway. You don't become ready by waiting. You become ready by doing.

For those who have been here for years, these lessons will feel familiar. We learned them together, sometimes slowly, sometimes through debate, and often the hard way.

If Drupal has been part of your daily life for a long time, you are not just a user or a contributor. You are part of its history. And for all of you, I am grateful.

I am still here, still learning, and still excited about what we can build together next. Thank you for building it with me.

2025 has been a year of significant growth and accomplishment for DDEV. With 579 commits to the main repository and releases from v1.24.0 through v1.24.10, we've made substantial progress on features, infrastructure, and community building. Here's a look back at what we all achieved together.

Table of Contents

• Organizational Milestones
• Community Engagement
• Major Features and Improvements
  • Sponsorship Communication
  • Add-on Ecosystem
  • Container and Infrastructure
  • Developer Experience
  • Language and Database Updates
  • Windows Improvements
• ddev.com Website and Documentation
• IDE Integration
• DDEV Developer Improvements
• AI in DDEV Development
• Removals in v1.25.0
• Challenges and things that could have gone better
• Comparing Outcomes to 2025 Goals
• By the Numbers
• Wow, Community Contributions!
  • By Contributor
  • Summary by Count
  • Blog Guest Contributors
  • Amazing Official Add-on Maintainers
• Looking Ahead to 2026

Organizational Milestones

• Board of Directors Established: In December 2025, we formally established a Board of Directors for the DDEV Foundation, enhancing governance and setting the stage for long-term sustainability. We're super proud of this as it's something we've been working toward for years. Read all about it.
• Advisory Group Continues: Our Advisory Group meetings continued throughout the year, providing valuable input and oversight. It will continue just about the same even though we now have a formal Board.
• "Almost Everybody Loves DDEV": The Ironstar Developer Survey 2025 confirmed what we suspected - DDEV has strong community support and satisfaction.

Community Engagement

The DDEV open-source community continues excellent engagement on several fronts.

• addons.ddev.com now shows 147 community-contributed add-ons (176 in total).
• Several key features were suggested, initiated, and developed by community members. SO MANY of these are listed below.
• Online Training: We restarted online contributor and user training
• Offline Training: Randy conducted many Birds-of-a-Feature sessions at DrupalCons, spoke at Florida Drupalcamp, attended, spoke, and trained at TYPO3Camp RheinRuhr, etc.

Major Features and Improvements

Sponsorship Communication

• Massively improved reporting, communication, and management of sponsorship information
• Public sponsorship data feed via sponsorship-data repository
• Banners on DDEV web properties and The Drop Times show current funding status
• Daily ddev start notifications keep users informed about sponsorship status

Add-on Ecosystem

• The Add-on Registry launched in January 2025, now displays 176 add-ons, 29 of which are officially maintained by the DDEV team.
• PHP-based add-ons: Add-ons can now be written in PHP, as the ddev-upsun add-on shows. The PHP language is far more powerful for complex tasks than shell scripts.
• ddev add-on get now downloads add-on dependencies automatically
• x-ddev extension allows add-ons to add important information to ddev describe output
• Add-on monitoring continues for both official and community add-ons. We monitor the nightly tests of official add-ons, and periodically check in with all the community add-ons, asking people to re-enable or fix tests.
• New official add-ons: FrankenPHP (June), Redis Insight (July), Upsun (August), NVM Standalone (November)
• By year's end: 29 official add-ons and 176+ total add-ons.
• Stas continued to document and promote best practices with add-ons, including improved testing and upgrading strategies.

Container and Infrastructure

• Parallel Docker image pulls for faster project starts
• Docker Compose profiles: Start projects with specific profiles using ddev start --profiles=list,of,profiles
• Refactored Docker API code: no calls to docker binary (switched to github.com/docker/cli) and no fragile YAML map structures (switched to github.com/compose-spec/compose-go/v2)

Upcoming v1.25.0:

• Podman support: Podman rootless/rootful environments
• Docker rootless functionality added for Linux environments
• Base web server image updated to Debian 13 Trixie

Developer Experience

• XHGui integration funded by TYPO3 Association, read more
• ddev-upsun add-on provides new integration with Upsun (formerly Platform.sh) fixed and flex projects.
• New handling of privilege elevation using the ddev-hostname binary, improving security, read more
• --user/-u flag for ddev exec and ddev ssh
• ddev describe now works on stopped projects
• ddev utility download-images --all forces pulling all images in use
• Shell completion added and expanded thanks to community contributions
• ddev npx command support
• Improved cleanup for ddev delete and ddev delete images
• Automatic HTTP/S communication between DDEV projects
• Enhanced and simpler Pantheon support

Upcoming v1.25.0:

• Improved ddev share: More configurable, customizable, with pre-share hooks and DDEV_SHARE_URL environment variable
• ddev utility mutagen-diagnose: Automatic study of Mutagen problems or misconfiguration
• ddev utility xdebug-diagnose: Automatic study of possible Xdebug configuration problems

Language and Database Updates

• PHP 8.5 support added with a limited set of extensions (in v1.24.10)
• MariaDB 11.8 support added
• PostgreSQL 18 support added
• Node.js as primary web server support

Upcoming v1.25.0:

• PHP 8.4 is the default for new projects (previously PHP 8.3)
• PHP 8.5 support with all extensions
• Node.js 24 as default for new projects (previously Node.js 22)
• MariaDB 11.8 as default for new projects (previously MariaDB 10.11)

Windows Improvements

• New Windows GUI Installer handling Traditional Windows, WSL2/Docker CE, and Docker/Rancher Desktop
• ARM64 Windows installer support

ddev.com Website and Documentation

• Downloads page with improved installer access
• Theme switch button for light/dark mode
• Copy button for code blocks thanks to Bernardo Martinez
• Giscus commenting system for community discussions on blog posts
• AI integration documentation
• Multiple blog posts published covering technical guides, platform-specific instructions, and organizational updates
• Monthly newsletters tracking progress sign up!

IDE Integration

• IntelliJ IDEA plugin got regular, consistent maintenance thanks to @AkibaAT and moved to the DDEV organization on GitHub
• The VS Code DDEV Manager extension continued to be well maintained thanks to @biati-digital

DDEV Developer Improvements

• The new Quickstart tests have proved to be extremely valuable, providing early warning when upstream projects change. They also are a completely new perspective into problems with DDEV. Kudos to @rpkoller for taking those on and maintaining them!
• AkibaAT reorganized our Docker image builds so that multi-architecture builds that used to take an hour now take 10 minutes or less.
• Continuous improvements to AGENTS.md and CLAUDE.md to improve our efficiency in using AI.

AI in DDEV Development

2025 saw significant AI integration in our development workflow:

• Substantial features enabled by AI: Several features that seemed too daunting to start became achievable with AI assistance
• Increased code volume: More code, including extensive tests (though test quality varies)
• Tools used: Claude Code, GitHub Copilot
• Training: Our use of Claude Code was significantly improved by taking a Coursera Course.

Removals in v1.25.0

• NFS support removed
• ddev service command removed
• ddev nvm functionality removed, but still supported with ddev-nvm add-on
• Legacy configuration syntax cleanup

Challenges and things that could have gone better

• Market conditions are affecting agency and hosting company funding, and we go into 2026 with limited funding
• We applied to participate in the Google Summer of Code and the GitHub Secure Open Source Fund but were not accepted in either.
• Although the TYPO3 Association funded one feature submission (XHGui) later submissions were not accepted, and the nature of their program now seems to exclude DDEV features.
• Key upstream groups like the TYPO3 Association and Drupal Association still are not figuring out how to fund DDEV.
• bitnami/mysql issue: Using bitnami/mysql for MySQL 8.0 and 8.4 backfired with Bitnami ceasing its traditional support of important Docker images. This raises questions about dependency management when upstream projects change direction.
• We continue to struggle with funding for DDEV and went backward this year instead of forward.
• GitHub killed off the best strategy we had for keeping add-on tests running, which means that nightly tests must be manually enabled by their maintainers when they are discontinued automatically.
• We're so interested in solving user problems that it's possible we're too aggressive in Discord and maybe the issue queue in pursuing them. I'm thinking about whether this is an issue with users and will appreciate comment.

Comparing Outcomes to 2025 Goals

In 2025 Plans we laid out ambitious plans for 2025. Here are the outcomes:

• Continue outstanding user support Done.
• Begin formal governance for the DDEV Foundation. Done.
• Improve our Marketing CTA and information: Significant progress, with much better communication.
• Continue to develop contributors and maintainers: Great year, as shown below.
• XHGui support: Done
• addons.ddev.com: Done
• Feature: Implement mDNS as an alternate name resolution technique. Not funded, not implemented, de-prioritized.
• Allow Add-ons to include other add-ons: Done
• Go-based Upsun Add-on like ddev-platformsh: Done, but with PHP instead of Go.
• Rewrite ddev-platformsh Add-on in Go: Done, but in PHP. ddev-upsun now supports the older Platform.sh "fixed" projects.
• Develop a replacement for "Gitpod Classic": Gitpod was removed from codebase, and GitHub Codespaces support was improved, but a full replacement remains a goal for 2026.
• Improve self-diagnose capability: Done. Massive improvement with ddev utility diagnose, ddev utility mutagen-diagnose, ddev utility xdebug-diagnose.
• DDEV's Message-of-the-day and ddev.com should show current funding status and need: Done
• DDEV Windows/WSL2 packaging and installation: Done
• Change ddev share to a more configurable custom-command-based option: Done (in v1.25.0)
• Rework configuration system using Viper. Not done and de-prioritized.

By the Numbers

• 579 commits to the main repository
• 100+ pull requests merged
• Releases v1.24.0 through v1.24.10 with v1.25.0 coming in early 2026
• 93 repositories in the DDEV ecosystem
• 3,400+ GitHub stars on the core project
• 29 official add-ons
• 176+ total add-ons

Wow, Community Contributions!

As an open-source project we truly value the amazing contributions of the community. There are so many ways these contributions happen, including support requests and issues (we learn so much from those!) but also direct contributions.

By Contributor

I know this is "Too Much Information" but here is a simple and inadequate list of the amazing contributions directly to the main project by contributors other than Randy and Stas. It inspires me so much to see this consolidated list.

Ralf Koller - rpkoller - 36 contributions

• test: add a no-interaction flag to the install command in ibexa bats file (#7479)
• test: adding quickstarts for typo3 v13 and v12 plus bats tests (#7302)
• feat: add success message for xhgui on and off, fixes #7202 (#7205)
• test: make the drupal cms bats test a bit more robust and trustworthy (#7203)
• test: fix for magento2 quickstart and bats test, fixes #7191 (#7192)
• test: adjust openmage bats test assertions to the now available demo content (#7126)
• test: bats test for Statamic Composer quickstart (#7116)
• test: craftcms bats test (#7107)
• test: adding silverstripe quickstart bats test (#7112)
• test: symfony bats tests (#7102)
• (and 26 more)

Akiba - AkibaAT - 7 contributions

• build(image): use native arm builder for building Docker images, fixes #7539 (#7553)
• feat: add ddev add-on search subcommand, fixes #7491 (#7554)
• fix: add missing ephemeral port handling to xhgui service, fixes #7557 (#7560)
• fix: replace broken http and https port lookup, fixes #7246 (#7259)
• feat: add new envs DDEV_PRIMARY_URL_PORT, DDEV_PRIMARY_URL_WITHOUT_PORT and DDEV_SCHEME, fixes #7214 (#7218)
• fix: Use fast checkpoint during PostgreSQL backup, fixes #7098 (#7219)
• fix: disable Xdebug trigger for Xdebug and xhprof status checks, fixes #6191, fixes php-perfect/ddev-intellij-plugin#414 (#7216)

Ariel Barreiro - hanoii - 6 contributions

• docs: trailing whitespace on template (#7321)
• refactor: improve ddev add-on get output, add warning exit code annotation (#7263)
• fix: add BASE_IMAGE arg before everything else, for #7071 (#7258)
• feat: support prepend.Dockerfile* files for multi-stage builds (#7071)
• feat: show config..yml on ddev start (#7089)
• fix: the #ddev-description stanza in add-on install actions not showing if it's the first line (#7022)

tyler36 - tyler36 - 4 contributions

• fix(cakephp): do not override APP_DEFAULT_LOCALE (#7653)
• docs: update ngrok link (#7359)
• feat: Add live link to Discord (#7042)
• refactor: remove outdated move-issue config , fixes #6899 (#6906)

Travis Carden - TravisCarden - 3 contributions

• docs: fix a little custom command annotations code example (#7711)
• docs: Add missing sequelace command link to database-management.md (#7184)
• docs: Fix niggling code sample inconsistency in troubleshooting.md (#6984)

Laryn - laryn - 3 contributions

• feat: backdrop add bee to quickstart (#7053)
• docs: add Backdrop-specific config considerations. (#7037)
• docs: change code refs to include info about Backdrop config storage options, fixes #7013 (#7014)

Andrew Berry - deviantintegral - 2 contributions

• feat: support using zstd for snapshots, fix postgres:9 snapshot, fixes #7844, fixes #3583 (#7845)
• build: fix getopt detection on macOS (#7846)

Raphael Portmann - raphaelportmann - 2 contributions

• fix(heidisql): add default --databases=db to postgres, for #7830 (#7847)
• feat(heidisql): allow postgres connections, fixes #7675 (#7677)

cyppe - cyppe - 2 contributions

• feat(db): remove the hardcoded --server-id=0 parameter from MySQL startup, fixes #6768 (#7608)
• fix(laravel): don't edit database config in .env when there's no database (#7584)

Peter Bowyer - pbowyer - 2 contributions

• docs: clarify instructions for using PhpStorm inside WSL2 (#7333)
• docs: add MySQL 8.4 to supported databases (#6971)

Shelane French - shelane - 2 contributions

• feat: add DDEV_APPROOT variable to web container and updates documentation, fixes #7198 (#7199)
• refactor: remove solrtail from installed example commands, fixes #7139 (#7140)

Pierre Paul Lefebvre - PierrePaul - 2 contributions

• fix: XHGui launch command support custom ports, fixes #7181 (#7182)
• docs: Add the xhgui container to the building and contributing page. Add more description to the xhprof profiling page. (#7168)

Sven Reichel - sreichel - 2 contributions

• test: Add OpenMage composer quickstart and tests (#7133)
• test: add OpenMage/Magento 1 quickstart test and split it from Magento 2, for #7094 (#7091)

lguigo22 - lguigo22 - 1 contribution

• docs: add Cloudflare warp networking instructions (#7975)

Justin Vogt - JUVOJustin - 1 contribution

• fix(router): ensure Traefik monitor port is always bound to localhost (#7942)

grummbeer - grummbeer - 1 contribution

• fix(diagnose): Remove the hardcoded IP "127.0.0.1" from the DNS check, since it may be incorrect, fixes #7871 (#7872)

crowjake - crowjake - 1 contribution

• fix(commands): make HostWorkingDir respect WebWorkingDir (#7907)

Markus Sommer - BreathCodeFlow - 1 contribution

• fix: db port should be integer in generated TYPO3 AdditionalConfiguration.php, fixes #7892 (#7893)

James Sansbury - q0rban - 1 contribution

• docs: clarify instructions for disabling Mutagen on a single project (#7861)

Moshe Weitzman - weitzman - 1 contribution

• docs: remove community examples link in documentation (#7834)

Yan Loetzer - yanniboi - 1 contribution

• docs: add missing dot in .ddev/.env.* (#7828)

Garvin Hicking - garvinhicking - 1 contribution

• docs: add crosslink for shortened DDEV env variables to full list, fixes #7781 (#7782)

Benny Poensgen - vanWittlaer - 1 contribution

• feat: use composer_root in cakephp, craftcms, laravel, magento2, shopware6, symfony for app type detection (#7558)

Rob Loach - RobLoach - 1 contribution

• chore(provider): remove trailing whitespace in YAML files (#7770)

JshGrn - JshGrn - 1 contribution

• docs: explicitly mention setting system managed nvm version, for #6013 (#7733)

E - ara303 - 1 contribution

• docs(faq): remove traefik config when changing project's name, for #7638 (#7639)

Alan Doucette - dragonwize - 1 contribution

• feat: add ddev npx command (#7599)

Brooke Mahoney - brookemahoney - 1 contribution

• docs: clarify comments in the Drupal 10 and 11 quickstarts, fixes #7619 (#7620)

gitressa - gitressa - 1 contribution

• docs: remove Prerequisite section (#7621)

Eduardo Rocha - hockdudu - 1 contribution

• docs: fix typo in documentation (#7618)

Dezső BICZÓ - mxr576 - 1 contribution

• docs: Fix blog link in main nav (#7566)

Tomas Norre Mikkelsen - tomasnorre - 1 contribution

• feat: add ddev version to ddev describe command, fixes #7398 (#7541)

Danny Pfeiffer - danny2p - 1 contribution

• fix(pantheon): update Pantheon database pull to get fresh DB and file push to be CMS-agnostic, fixes #5215, fixes #4760 (#7486)

Popus Razvan Adrian - punkrock34 - 1 contribution

• feat: add Linux support for heidisql command (#7399)

Daniel Huf - dhuf - 1 contribution

• refactor: add SVG to rewrite rule for TYPO3 (#7482)

Ayu Adiati - adiati98 - 1 contribution

• docs(wsl): add wsl --update command for Windows (#7476)

Peter Philipp - das-peter - 1 contribution

• fix: temporarily allow write to /etc/mysql/conf.d/* for db container restart, fixes #7457 (#7458)

O'Briat - obriat - 1 contribution

• docs: How to use Xdebug with Composer for plugin development (#7423)

Andreas Hager - andreashager - 1 contribution

• feat: return real exit code from ddev exec and add quiet flag to it, fixes #3518 (#7385)

Bill Seremetis - bserem - 1 contribution

• docs: add Terminus downgrade tips, fixes #7352 (#7353)

Olivier Mengué - dolmen - 1 contribution

• build: upgrade mapstructure to v2 (#7396)

Rui Chen - chenrui333 - 1 contribution

• test: use main for setup-homebrew action instead of master (#7395)

michaellenahan - michaellenahan - 1 contribution

• docs: improve xhgui documentation, fixes #7376 (#7377)

August Miller - AugustMiller - 1 contribution

• docs: align Craft CMS quickstart with official documentation (#7323)

Loz Calver - lozcalver - 1 contribution

• feat: prune orphaned Node.js versions after install, fixes #7325 (#7326)

Tim Kelty - timkelty - 1 contribution

• docs: update Craft CMS quickstart, for #7236 (#7274)

Pedro Antonio Fructuoso Merino - pfructuoso - 1 contribution

• fix: Add path to docroot in wp parameters when not set, fixes #7241 (#7242)

Bang Dinh - bangdinhnfq - 1 contribution

• docs: Update Shopware quickstart with "shopware/production" instead of "shopware/production:^v6.5" (#7253)

nmangold - nmangold - 1 contribution

• docs: wrap quotes around commands that use the caret symbol (#7237)

Jeremy Gonyea - jgonyea - 1 contribution

• docs: fix minor typo in the Grav quickstart (#7197)

Colan Schwartz - colans - 1 contribution

• build: stop installing chocolatey, fixes #6636, fixes #6344 (#7049)

Mrtn Schndlr - barbieswimcrew - 1 contribution

• fix: nginx.conf should let index.php handle 404 errors for media files (#7050)

Marvin Hinz - marvinhinz - 1 contribution

• fix: add timeout for netutil::IsPortActive check for WSL2 with "mirrored networking mode" as opposed to default "NAT mode", fixes #6245 (#7166)

RubenColpaert - RubenColpaert - 1 contribution

• fix: use charset=utf8mb4 in DATABASE_URL for Symfony environment variables, fixes #7068 (#7076)

Alexey Murz Korepov - MurzNN - 1 contribution

• docs: Add docs about configuring browser for HTTPS certificates (#7075)

Adam - phenaproxima - 1 contribution

• docs: Update quickstart.md to remove Drupal CMS ZIP file instructions (#7119)

Nick Hope - Nick-Hope - 1 contribution

• docs: update Windows installation docs to use 'Docker Engine' terminology (#7092)

Damilola Emmanuel Olowookere - damms005 - 1 contribution

• docs: add DevDb tip to database management documentation (#7084)

nickchomey - nickchomey - 1 contribution

• docs: add WordPress special handling info about wp-cli.yml (#7080)

Andrew Gearhart - AndrewGearhart - 1 contribution

• refactor: improve Docker version checks, set minimum supported Docker API to 1.44, fixes #6916 (#6946)

Christopher Kaster - atomicptr - 1 contribution

• feat: change php-fpm setting 'decorate_workers_output' to 'no' (#6964)

Hervé Donner - vever001 - 1 contribution

• feat: switch apache mpm_prefork to mpm_event, fixes #6966 (#6967)

Bernhard Baumrock - BernhardBaumrock - 1 contribution

• docs: Add ProcessWire to the Quickstart List (#6879)

Erik Peterson - eporama - 1 contribution

• fix: update Drupal 7 settings.ddev.php and settings.php to match Drupal 7.103 (#6913)

Tom Yukhayev - charginghawk - 1 contribution

• fix: In acquia.yaml, specify default site source for ddev pull acquia. (#6874)

Summary by Count

Blog Guest Contributors

Guest contributions to the blog are always welcome and key contributors added significant posts this year:

Ajith Thampi Joseph - atj4me

• Tailscale for DDEV: Simple and Secure Project Sharing

Bill Seremetis - bserem

• How to Downgrade Terminus in DDEV's Web Container and Customize Other Bundled Tools

Garvin Hicking - garvinhicking

• Using DDEV to spin up a legacy PHP application

Jeremy Gonyea - jgonyea

• Building an Off-Ramp from WordPress with DDEV

ayalon - ayalon

• Exposing a Node.js App Over HTTP / HTTPS on a Subdomain in DDEV (blog author: J. Minder)

And thanks to all of you who use DDEV, report issues, answer questions in Discord and other venues, and spread the word. Your support makes this project possible.

Amazing Official Add-on Maintainers

There are so many unofficial add-ons being maintained by so many people, but here are the folks that maintained official repositories:

1. @tyler36 - ddev-browsersync, ddev-cron, ddev-cypress, ddev-qr, plus contributions to 20+ other add-ons
2. @weitzman (Moshe Weitzman) - ddev-drupal-contrib, ddev-selenium-standalone-chrome
3. @cmuench (Christian Münch) - ddev-opensearch
4. @julienloizelet (Julien Loizelet) - ddev-mongo, ddev-redis-insight
5. @mkalkbrenner - ddev-solr
6. @robertoperuzzo - ddev-sqlsrv
7. @b13 (TYPO3 agency) - ddev-typo3-solr, ddev-rabbitmq
8. @jedubois - ddev-varnish
9. @hussainweb - ddev-redis
10. @seebeen - ddev-ioncube, ddev-minio
11. @bserem (Bill Seremetis) - ddev-adminer
12. @AkibaAT - ddev-intellij-plugin
13. @biati-digital - vscode-ddev-manager

Looking Ahead to 2026

Stay tuned for our 2026 plans post where we'll outline what's next for DDEV. As always, we welcome your input through all our support venues.

Claude Code and GitHub Copilot were used as assistants in gathering lists and material, and in reviewing this article.

I used Claude Code to build a new feature for my site this morning. Any URL on my blog can now return Markdown instead of HTML.

I added a small hint in the HTML to signal that the Markdown version exists, mostly to see what would happen. My plan was to leave it running for a few weeks and write about it later if anything interesting turned up.

Within an hour, I had hundreds of requests from AI crawlers, including ClaudeBot, GPTBot, OpenAI's SearchBot, and more. So much for waiting a few weeks.

For two decades, we built sites for two audiences: humans and search engines. AI agents are now the third audience, and most websites aren't optimized for them yet.

We learned how to play the SEO game so our sites would rank in Google. Now people are starting to invest in things like Generative Engine Optimization (GEO) and Answer Engine Optimization (AEO), which are about getting cited in AI-generated answers.

I wanted to understand what that actually means in practice, so I turned my own site into a small experiment and made every page available as Markdown.

If you've been following my blog, you know that Drupal stores my blog posts as Markdown. But when AI crawlers visited, they got HTML like everyone else. They had to wade through navigation menus and wrapper divs to find the actual content. My content already existed in a more AI-friendly format. I just wasn't serving it to them.

It only took a few changes, and Drupal made that easy.

First, I added content negotiation to my site. When a request includes Accept: text/markdown in the HTTP headers, my site returns the Markdown instead of the rendered HTML.

Second, I made it possible to append .md to any URL. For example, https://dri.es/principles-for-life.md gives you clean Markdown with metadata like title, date, and tags.

But how did those crawlers find the Markdown version so fast? I borrowed a pattern from RSS: RSS auto-discovery. Many sites include a link tag with rel="alternate" pointing to their RSS feed. I applied the same idea to Markdown: every HTML page now includes a link tag announcing that an alternative Markdown version exists at the .md URL.

That "Markdown auto-discovery" turned out to be the key. The crawlers parse the HTML, find the alternate Markdown link, and immediately switch. That explains the hundreds of requests I saw within the first hour.

In the end, this took surprisingly little work. If your content already exists in a cleaner, structured form, you might be closer to this than you think. For me, this feels like the beginning of a longer experiment.

The speed of adoption tells me AI agents are hungry for cleaner content formats and will use them the moment they find them. What I don't know yet is whether this actually benefits me. It might lead to more visibility in AI answers, or it might just make it easier for AI companies to use my content without sending traffic back.

I know not everyone will love this experiment. Humans, including me, are teaching machines how to read our sites better, while machines are teaching humans to stop visiting us. The value exchange between creators and AI companies is far from settled, and it's entirely possible that making content easier for AI to consume will accelerate the hollowing out of the web.

I don't have a good answer to that yet, but I'd rather experiment than look away. I'm going to leave this running and report back.

Most things need regular care and maintenance to ensure they continue to run effectively, and your website is no exception. When it comes to website maintenance, one of the strongest parallels is with car maintenance. A vehicle only runs smoothly with routine check-ups, even if it looks perfect on the outside. You stay on the safe side when the engine is checked, parts are updated, and small issues are fixed before they turn into larger, more expensive repairs.

I’m excited to share that I’ll be teaming up with Lullabot’s Andy Blum to deliver an in-depth front-end theming training at DrupalCon Chicago 2026.

This training is especially meaningful to me because it brings together a large part of the work I’ve been doing at Dripyard over the past few years. Teaching and sharing hard-earned lessons is one of my favorite parts of being involved in the Drupal community.

Today we are talking about Recording Podcasts, The tech used, and How Drupal Can help with guest Stephen Cross. We'll also cover Chosen as our module of the week.

For show notes visit: https://www.talkingDrupal.com/535

• Podcasting and Second Signal Media
• Evolution of Podcasting
• Tech Essentials for Podcasting
• The CEO's Video Strategy Transformation
• Overcoming the Fear of Speaking on Camera
• The Importance of Consistency in Content Creation
• Editing vs. Authenticity in Video Content
• Choosing the Right Environment and Equipment
• Setting Realistic Goals for Your Podcast
• Recording Workflow Recommendations
• Tools and Tips for Improving Audio Quality

• Basic Editing with Kdenlive
• Audio clean-up tools
• Izotope
• Secret sounds

Stephen Cross - stephencross

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Andy Giles - dripyard.com andyg5000

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to give users on your Drupal site a more intuitive alternative to native HTML multiselect widgets? There's a module for that.
• Module name/project name:
  • Chosen
• Brief history
  • How old: created in Jul 2011 by shadcn but recent releases are by Bálint Nagy (nagy.balint) of Hungary
  • Versions available: 3.0.6, 4.0.3, and 5.0.3, the last of which works with Drupal 10.2 or 11
• Maintainership
  • Actively maintained
  • Security coverage
  • Test coverage
  • Number of open issues: 221 open issues, 4 of which are bugs against the 5.x branch
• Usage stats:
  • Almost 38,000 sites
• Module features and usage
  • With the module installed, your Drupal site will selectively replace select elements with a more intuitive widget, leveraging the Chosen library. In the module's configuration you can specify how many options should trigger Chosen, and also specify form field selectors to explicitly include or exclude.
  • The three active branches of the module reflect usage of different forks of the Chosen library. Notably, the 5.x versions use a fork that no longer requires jQuery, and allows Chosen to be enabled for mobile devices.
  • In addition to the module configuration, you can also force a custom form's select element to use the Chosen library simply by adding the "chosen-select" class to the form array.
  • Back in episode #409 we talked about Tagify, which in some ways is similar, but is designed specifically to work with entity reference fields. That makes it less "general purpose", though Tagify does also include some additional capabilities, such as being able to include labels or icons on results based on a property of the result.
  • Years ago I used another popular project called Select2 for turning multiselects into listboxes that included a search filter, but that project relied on a library that required jQuery but is incompatible with jQuery 4. So, Select2 has been officially replaced by Tagify, but Chosen could also be useful if your field is not an entity reference.
  • There are a variety similar modules you can also look at, including Choices.js, Selectize, and Selectify, but Chosen is by far the most widely used, even if you're only looking at numbers for the 5.x branch

Twenty years ago, I argued passionately that breaking backward compatibility was one of Drupal's core values:

The only viable long-term strategy is to focus exclusively on getting the technology right. The only way to stay competitive is to have the best product. [...] If you start dragging baggage along, your product will, eventually, be replaced by something that offers the same functionality but without the baggage.

I warned that preserving backward compatibility would be the beginning of the end:

I fear that this will be the end of Drupal as we have come to know it. Probably not immediately, maybe not even for several years, but eventually Drupal will be surpassed by technology that can respond more quickly to change.

Twenty years later, I have to admit I was wrong.

So what changed?

In 2006, Drupal had almost no automated tests. We couldn't commit to backward compatibility because we had no way to know when we broke it. Two years later in 2008, we embraced test-driven development.

By 2016, we had built up significant test coverage, and with that foundation we adopted semantic versioning and committed to backward compatibility. Semantic versioning gave us a deprecation policy. We can mark old code for removal and clear it out every two years with each major release. The baggage I feared never really accumulated.

Today, according to the Drupal Core Metrics dashboard, Drupal Core has more than twice as much test code as production code. I didn't fully appreciate how much that would change things. You can't promise backward compatibility at Drupal's scale without extensive automated testing.

Our upgrades are now the smoothest in the project's history. And best of all, Drupal didn't end. It's still a top choice for organizations that need flexibility, security, and scale.

I recently came across an interview with Richard Hipp, SQLite's creator. SQLite has 90 million lines of tests for 150,000 lines of production code. That is a whopping 600-to-1 ratio. Hipp calls it "aviation-grade testing" and says it's what lets a team of three maintain billions of installations.

I suspect our test coverage will continue to grow over time. But Drupal can't match SQLite's ratio, and it doesn't need to. What matters is that we built the habits and discipline that work for us.

In 2006, I thought backward compatibility would be the end of Drupal. In 2026, I think it might be what keeps us here for another twenty years.

Thank you to everyone who wrote those tests.

It does make me wonder: what are we wrong about now? What should we be investing in today that will slowly reshape how we work and become an obvious advantage twenty years from now? And who is already saying it while the rest of us aren't listening?

AI is moving quickly into the Drupal ecosystem, but the conversation around it has often been fragmented and uneven in quality. Drupal AI TV, launched by the Drupal AI Initiative, responds to this by focusing less on promotion and more on consolidation. Its core value lies in curation: selecting existing, publicly available sessions and placing them in a single, structured space where professionals can assess current thinking and practice around AI in Drupal without wading through unrelated material.

The range of content is notable for its balance. Alongside technical demonstrations, there is clear attention to ethical questions, organisational readiness, and the realities of integrating AI into existing systems. This signals a pragmatic stance toward AI adoption, one that recognises both its potential and its constraints. By including case studies and workflow-focused sessions, Drupal AI TV grounds abstract AI discussions in the day-to-day decisions faced by developers, content teams, and digital strategists.

As the platform grows, its usefulness will depend on how well it maintains this curatorial discipline. Regular updates are important, but relevance and depth matter more than volume. If Drupal AI TV continues to prioritise informed, experience-based perspectives, it can become a steady reference point for teams evaluating when and how AI meaningfully fits into their Drupal projects, rather than another channel that adds to the noise.

With that, let's move the spotlight to the important stories from the past week.

DISCOVER DRUPAL

• Drupal AI Initiative Launches "Drupal AI TV" to Curate Top AI Resources for Community
• Uppy for Drupal: Advanced File Uploading with Inline Image Editing Support
• Drubernetes v3 Replaces Nginx Ingress with Envoy Gateway for Modern Kubernetes Architecture
• Kevin Quillen Releases Offline htaccess Testing Plugins for VS Code and JetBrains IDEs

EVENTS

• Drupal 25th Birthday Party Set for January 15 in Zurich
• Drupal Pune Meetup to Celebrate 25 Years of Drupal on January 10
• Drupal Celebrates 25 Years at New Year Reception in Mechelen
• DrupalCamp Costa Rica 2026 Returns as Free, Multi-Track Tech Event for Web, AI, and Open Source
• Acolono and Drupal Austria to Host In-Person Drupal 25 Celebration in Vienna
• Japan Forms Committee to Launch Official Drupal Association; DrupalCamp Tokyo 2026 Announced

DRUPAL COMMUNITY

• Drupal Association Invites Community to Celebrate 25th Birthday with Photo Wall
• Drupal Turns 25 and Calls on Community to Share 25 Words of Celebration

ORGANIZATION NEWS

• Kanopi Studios Acquires Chapter Three to Strengthen Drupal Services

We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now. To get timely updates, follow us on LinkedIn, Twitter, Bluesky, and Facebook. You can also join us on Drupal Slack at #thedroptimes.

Thank you.

Alka Elizabeth
Sub-editor
The DropTimes

• Read more about A Drupal migration that wraps values in paragraphs
• Add new comment

If you think Drupal is designed only for developers, and that marketing specialists have to ask for every change, it's time to update your knowledge. Nowadays, marketers can think of a campaign one day and build a landing page the next. This is possible thanks to the committed community and thousands of modules. Three of them have completely changed the way landing pages are built and deserve a special mention. In this article, we will show you how to create pages using with drag & drop method.

AI is no longer on the horizon — it’s fully here, and reshaping nearly every corner of the digital world. It’s no longer news that with the right approach, AI tools can quietly and tirelessly simplify and streamline much of the work across various areas. Search Engine Optimization, with its many routine and repetitive tasks, is no exception.

Join Johanna and Jess as they dive deep into their experiences and insights working with Drupal in the nonprofit sector. Learn about their early careers, the evolution of Drupal's development, the significance of community in nonprofit tech, and the origins and importance of the Nonprofit Summit at DrupalCon. Discover how their community initiatives foster collaboration and support among nonprofit technologists, and get a glimpse into the upcoming summit details. Perfect for anyone interested in Drupal, open-source technology, and nonprofit organizational challenges.

For show notes visit: https://www.talkingDrupal.com/cafe012

Johanna Bates (they/them, hanpersand on drupal.org) is co-founder and co-principal of DevCollaborative, a company that builds accessible and sustainable Drupal and WordPress sites exclusively for nonprofit organizations.

Johanna began their formal tech career at WGBH in Boston in 2000 as a front-end developer. They have been building Drupal sites since 2004, and have been co-moderating NTEN's Nonprofit Drupal Community and its monthly chats for over a decade.

Johanna was involved in early Nonprofit Summits at NYCcamp starting back in 20-teens 2015, and helped bring the Nonprofit Summit to DrupalCon North America in 2017.

Jess Snyder (jesss on drupal.org and Drupal Slack) is Director of Web Systems for WETA, the flagship public media station for Washington, DC, and has over 20 years of experience in website development.

Jess is an organizer for NTEN's Drupal Community of Practice as well as Drupal GovCon. She also co-chaired the triumphant return of the Nonprofit Summit to DrupalCon Portland 2024 and its sequel at DrupalCon Atlanta 2025.

When not Drupaling, Jess sits on the Board of Directors for the National Academy of Television Arts and Sciences.

• Meet the Speakers: Johanna and Jess
• Johanna's Journey in Nonprofit Tech
• Jess's Path in Public Broadcasting
• The Importance of Community in Nonprofit Tech
• Organizing Nonprofit Summits
• Challenges and Changes in Drupal
• The Value of Open Source for Nonprofits
• Comparing Drupal and WordPress
• Concerns About JavaScript in Content Editing
• Importance of Accessibility in Content Management
• Guardrails for Content Editors
• The Nonprofit Summit: Origins and Evolution
• Summit Format and Community Building
• Sponsorship and Event Details
• Getting Involved in the Nonprofit Drupal Community
• Conclusion and Final Thoughts

Johanna Bates - hanpersand Jess Snyder - jesss

I built a dashboard that tracks Drupal Core's code quality over time, across major releases from Drupal 7 through Drupal 11. It measures lines of code, cyclomatic complexity, maintainability index, anti-patterns, and API surface area. Think of it as a health report for Drupal's codebase.

The dashboard updates automatically and is available at https://dbuytaert.github.io/drupal-core-metrics/.

The charts tell a clear story of steady, hard-won progress. A story to be proud of and worth sharing. Code quality is dramatically better than it was in Drupal 7: lower complexity, easier to maintain, fewer anti-patterns, and dramatically better test coverage. Drupal now has nearly twice as much test code as production code!

Drupal Core's API surface has modernized too. As Drupal shifted from procedural to object-oriented patterns, global procedural functions gave way to classes implementing interface methods, services, plugins, and events.

By tracking these metrics publicly, I hope to inform decisions about both code quality and developer experience. When we refactor complex code, we can measure the impact. We can set goals and track progress.

All charts use static code analysis. Static analysis measures the code as written, not what it feels like to work with it or to learn Drupal as a new developer. As a next step, I'd love to measure developer experience more directly. Dynamic analysis might help, for example by tracking call stack depth, or how many files and APIs you have to touch to make a simple change.

The dashboard is open source, and contributions are welcome at https://github.com/dbuytaert/drupal-core-metrics.

Special thanks to catch for multiple rounds of feedback. As the most active Core Committer over the past 12 months, his input was invaluable.

We often assume a tool or coding technique must be complex to be impactful, yet oftentimes, the most elegant solutions are the simplest. Before writing custom code or installing a new module, we should investigate if a native browser solution already exists. Developers often overlook this step, missing the fact that native HTML and CSS can frequently replicate the functionality of advanced third-party libraries with far less overhead.

This post explores the power of the native <details> element. By returning to these fundamental building blocks, you can create accessible, high-performance accordions without the weight of unnecessary dependencies.

The <details> and <summary> HTML elements

The <details> element, also known as the Details disclosure element, it's described as...

...an HTML element which creates a disclosure widget in which information is visible only when the widget is toggled into an open state. A summary or label must be provided using the <summary> element.

HTML and CSS have come a long way in the last years, and browser support has improved rapidly. As a result, we can use native solutions to build interactive functionality that previously required JavaScript.

The <details> element reached Baseline Widely available status in January 2020.

The Markup

The markup is simple, but it does require the <summary> element to be nested within the <details> tag. But don't be fooled by the simplicity of the markup, the <details> combined with the <summary> elements pack a surprising set of features. More on this shortly.

<details>
  <summary>Title summary</summary>
  ...details content
</details>

Standard markup and nesting structure of the <details> and <summary> elements.

While the markup structure above is required, you can still get creative with the markup should the thing you are building has specific markup requirements. See below:

<details class="accordion" name="demo">
  <summary>
    <h3 class="accordion__title">Cras justo odio, dapibus ac facilisis in</h3>
  </summary>
  <p class="accordion__content">
    Cras mattis <a href="#">consectetur purus</a> sit amet fermentum. Nullam id dolor id nibh ultricies vehicula ut id elit. Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum. Morbi leo risus, porta ac consectetur ac, vestibulum at eros.</p>
  <span class="accordion__footer">Learn more <a href="#">about this topic</a></span>
</details>

A more elaborate example of the <details> and <summary> elements using custom markup while adhering to standards.

Notable <details> features

Attributes{.small-h3}

• open: This Boolean attribute indicates whether the details — that is, the contents of the <details> element — are currently visible. The details are shown when this attribute exists, or hidden when this attribute is absent. By default this attribute is absent.
• name: The name attribute specifies a group name. Modern browsers now support the name attribute on <details> elements, allowing you to create exclusive accordions (where opening one closes others) using only HTML. 🌟

Events

• toggle: If for some reason you need to use JavaScript, the <details>'s toggle event is available to tap into it with JavaScript.

Accessibility

• Accessible by Default: The structure is recognized by screen readers as a disclosure widget, and it is natively keyboard-accessible using the Enter or Space keys.
• Focusable: By default the <details> element is focusable when navigating with keyboard or assistive technologies. It's smart enough that if its details contain focusable content (i.e. links, buttons, etc.), it automatically navigates those elements by simply continuing to press the Tab key.
• Native Disclosure Widget: By default, the <details> element is collapsed, showing only the content of the <summary>.

Other

• Semantic in nature for improved SEO.
• Responsive out of the box. No CSS needed.
• State-Based Styling: The presence or absence of the open attribute allows you to easily apply different CSS styles for the expanded and collapsed states.
• Built-in Interactivity: Clicking or touching on the <summary> automatically toggles the <details> element's open state, revealing or hiding the nested content without any JavaScript.
• Page-searchable by default. If you do a page search by pressing Cmd + F or Ctrl + F in your keyboard, and if a match is found within a <details> element, the <details> will automatically open to show the highlighted results. 🤯

Try page search below

What does this all mean?

Learning about the features available in the <details> element opens up all kinds of possibilities for the aesthetics and behavior we want to achieve with the accordion.

Codepen Demo

With a little CSS and no JavaScript, we end up with an accordion that adheres to web and accessibility standards while providing a smooth animation effect that previously required JavaScript. Run the CodePen below for an example.

See the Pen by Mario Hernandez (@mariohernandez) View on CodePenCodePen.

Demo of an accordion component built with the <details> element and CSS.

Live demo

I recently implemented this very component in a Drupal site. 🤓

Resources

• Learn more about the ::details-content pseudo-element.
• The <details> element reached Baseline Widely available in 2020.

In closing

Even after using the <details> element for some time, I am still blown away by how much functionality a few lines of HTML combined with CSS can create. My advice to developers—especially those who have been coding for a while—is to revisit the basics from time to time; you'll be surprised how much things have evolved. Happy coding! 🌟