Drupal is 25 this year, and its code has had linters for a long time. Its words haven't, and with Drupal AI writing straight into the node form, more of them now come from a model. A search of drupal.org turns up readability scores and spellcheckers, but nothing that holds a save to your own style guide.

Vale (for Drupal) does that with the Vale prose linter. Break an error-level rule and the save is refused, or only the publish if drafts should save freely. 1.0.0 is out now for Drupal 10.3, 11 and 12, and needs the Vale binary on your server.

Vale in CI is the right tool for Markdown in a repository. Content in Drupal arrives through a save instead: the node form, a Fully Decoupled frontend over JSON:API, a workspace being published. The module checks there, on the server, whatever editor the author used.

Continue reading →

In the Open is a weekly series from Drupal Association Interim CEO Tiffany Farriss, sharing what she is hearing across the Drupal community and where the Association is headed. In this episode: why Drupal's commons is under pressure, how the Drupal Certified Partner program is evolving, and what it takes to keep free software running for the next 25 years.

"Drupal is free. The code of Drupal is free forever. But those of us who run Drupal know that running Drupal has never been free."

The following is a transcript of Tiffany's remarks, lightly edited for readability.

What I'm hearing from the community

The thing that's top of mind for me this week is reflection. I've spent a lot of time listening to folks, talking to folks, asking a lot of questions. I wanted to take a few minutes to share back some of the things I'm hearing, because these are the things motivating the changes in how I'm thinking about existing programs, and about how we might want to do things differently for the next 25 years of Drupal.

Whether it was the ecosystem survey, the business community survey, or conversations with the core release maintainers and other parts of the community, it's very clear to me that our commons is fragile. The technology of Drupal itself is a brick. It is solid. We are super proud of our security team. But the people and the funding sustaining it aren't yet in a sustainable place, and there's a lot of pressure.

That pressure is echoed in the business community. The businesses that have been very supportive of Drupal through the years, and I'm thinking not just of those 126 Drupal Certified Partners but of all of us, everyone is getting squeezed. The business survey data showed that the average deal size was down, and that pipeline expectations had gone negative for the first time in the Drupal business survey.

That creates a real impetus for us to make sure that people who aren't in our community are hearing about Drupal, because right now we don't think they are. We think the visibility and the curb appeal of Drupal is weak. It was one of the weakest scores in the business survey. And yet where Drupal is already in the mix, it continues to do really well. This is where you see our advocacy program trying to address this: getting the word out to people who may have a very dated view of Drupal, who haven't looked at us in a while. Because when people actually know Drupal, we succeed.

Rethinking the Drupal Certified Partner program

I take all that feedback, and I've been thinking a lot about the Drupal Certified Partner program. One thing that stood out in conversations across the ecosystem is that calling it the Drupal Certified Partner program has created misimpressions that aren't serving us well. It lets some folks opt out: "Oh, that's not really for me, that's just for small agencies, just for the folks who are already there, who are already contributing." That's not true. It also creates the idea that we're some sort of trade association, and we're not. We're a 501(c)(3). We are a not-for-profit with a charitable and educational mission around the Drupal project itself, which has been recognised as a digital public good. So we need to reinvent what that message is and how we address it.

Free code was never free to run

There are things that always have to be true. Drupal is free. The code of Drupal is free forever. But those of us who run Drupal know that running Drupal has never been free. It requires security coordination. It requires testing and packaging and releases, and those cost real time and money. A small group has paid for that for a really long time, and I think this is the time when the wider world is waking up and realising that's not such a good idea.

Last week's security incident with PHP brought a lot of light to that. The PHP Foundation has one full-time staff person, my equivalent, Elizabeth Barron. She's amazing. But just one person, and 70% of the internet runs on that. She has twelve people she's able to fund part-time to do security and maintenance work on PHP. So I'm hopeful that the broader conversation about what it takes, about this open source technology that everyone depends on, that's in everything and everywhere, creates an opportunity for us to have that conversation.

What every Drupal site receives

A lot of what I've done is extend the work I did a few years ago on what the Drupal Association itself puts into supporting Drupal. It's about $10 a year per site, and $7.50 of that we're actually able to raise. Then when we consider the things that aren't scratching your own itch, like core release management or the security work, things done by the community, I think the community itself puts in another $30 a year. So every year, every site receives $40 of services that are simply donated to it.

And when we come back to that volunteer time, those 126 companies who are Drupal Certified are shouldering that burden today. That isn't fair to them, and it's not safe for Drupal.

Making contribution visible, expected, and recognised

What I want to do is make it easy and expected for everybody in the ecosystem, everyone who receives value from Drupal, everyone who uses it, to understand what it means to be a net neutral citizen of Drupal, and to give that back easily in ways that are appropriate. We have asked people to give back for a long time. That's gotten us here, but I don't think it gets us where we need to go. The next step is to make that contribution visible, expected, and recognised.

That's how I'm thinking about the Drupal Certified Partner program becoming the Drupal Certified program. What we can do is be a certified trust registry. What does the Drupal Association uniquely have to offer? We can reflect how you're giving: in what ways you are a maker, in what ways you are a patron, in what ways you are an advocate. And we can calibrate those so they're appropriate to the sector you're in and the ways you would naturally want to contribute to Drupal.

Certified organisations will be those who agree to a set of shared good practices: contributing fixes upstream, responding to our security team, tending the issue queues you maintain, and keeping sites current. Any organisation with a developer can meet those maintenance commitments in-house. And if not, we're going to set up a maintainers fund. Drupal has a lot of maintainers who would appreciate a little support, so if your organisation has modules you maintain, or that you need maintained, we can be a conduit for that. We can help you be a good Drupal citizen.

What will always be true

Drupal is GPL, and Drupal is always going to be free for everyone. Security patches and advisories will be available to everyone. No one can pay for that. You can join the security team, and I really encourage people to do that, because we know the volume of security issues is up tremendously. AI is both the culprit and the solution to that.

What you'll start to see over the next six months is a real evolution in how we take that responsibility as a public ledger very seriously, and make sure it's clear to people both inside and outside our community how you're engaging with this ecosystem. So that we can continue to have a really nice commons, a digital one at that, for the next 25 years.

Follow the conversation

New episodes of In the Open publish each week. Subscribe on the Drupal Association YouTube channel to follow along.

With thanks to Stephen Cross of Second Signal Media for producing this series.

Supply Chain Security for Drupal Projects admin Tue, 10/27/2026 - 14:38 Drupal Security

A developer needs a fix from a contrib module, so they open a terminal inside DDEV and run composer update. The container can reach an SSH agent and a hosting token. Composer downloads a few packages and writes a new lock file.

Nothing about that looks unusual. That is the problem.

The recent wave of supply chain attacks did not exploit Drupal. It exploited the moment a developer or a build changes dependencies with credentials in reach. The Drupal Security Team has been clear about the boundary. Its remit is code hosted on Drupal.org, and site owners are responsible for third-party libraries.

The rest of the dependency tree is ours.

We develop locally in DDEV and use Dependabot in GitHub for update pull requests. Here is how we think about protecting a Composer-based Drupal project.

The risk arrives when dependencies change

These attacks arrive with a dependency change, and a Drupal project gives them three places to run.

The first is Composer plugins. In April 2026, an attacker moved an existing intercom/intercom-php tag to a malicious commit. The malicious commit turned the library into a Composer plugin that stole credentials during install.

The second is autoload.files. In May 2026, attackers rewrote historical tags on four laravel-lang packages. The payload was registered in autoload.files, so it ran on every PHP request.

The third is npm lifecycle scripts. The Shai-Hulud worm spread through npm install scripts and the npm tokens it stole. A later campaign hid a postinstall hook in the package.json of PHP packages, aimed at projects that also run JavaScript tooling. Many Drupal themes run npm tooling, so the theme's package.json belongs in the same review.

Each vector needs its own control.

Allow plugins by name and treat the lock file as code

Commit composer.lock, and have builds and deploys run composer install rather than composer update. An install reproduces the commits already recorded in the lock file. The same behavior protected laravel-lang users whose lock files predated the attack.

Keep drupal/core-recommended as the core requirement, because it pins core's own dependencies tightly.

A common piece of generic advice is to install with --no-plugins, but on Drupal that breaks the build. Both composer/installers and the core scaffold plugin are Composer plugins. Without them, modules do not land in web/modules/contrib and scaffold files are never placed.

The control that fits Drupal is allow-plugins. By default it allows no plugins, and the drupal/recommended-project template already ships a short list of named packages. Keep that list explicit, and never set it to true.

Then review lock file diffs as carefully as code. Three changes deserve a second look:

• a package whose type becomes composer-plugin
• a new plugin appearing at all
• a changed source reference on an unchanged version number

An unexpected plugin prompt is a code review event, not a formality.

Let Composer and npm block what they already know is bad

Newer package managers now do much of this work by default. Composer 2.9 blocks updates to versions with known security advisories. Composer 2.10 adds malware blocking that also applies to composer install, so a malicious version that slipped into a lock file fails the next build instead of installing quietly.

That malware data comes from a Packagist.org feed, so it covers core and its dependencies but not contrib from packages.drupal.org.

Versions with advisories can still be installed from an existing lock file, though. The audit therefore belongs in the build:

composer install --no-dev --no-interaction --no-progress composer audit --locked

Drupal advisories reach composer audit because packages.drupal.org publishes advisory data for the projects it hosts. When an advisory does not apply to a site, record an exception with a reason in Composer's policy configuration instead of removing the audit step.

That also retires two older tools. Drush 12.3.0 removed pm:security in favor of composer audit, and Composer's built-in blocking replaces roave/security-advisories.

On the theme side, npm 12 blocks dependency lifecycle scripts unless the root package explicitly allows them. Treat that allowScripts list like allow-plugins, and install with npm ci against a committed package-lock.json.

Teams that want a review step on every dependency change can watch Laravel Vet. Despite the name, it works with any Composer project. It is still in beta and requires PHP 8.4, and we have not tested it with Drupal.

Wait a week, except for security releases

We recommend a 7-day waiting period for routine Composer and npm updates, with security releases exempt and applied the same day.

The timing supports it. The malicious intercom-php tag was live for under two hours, and Packagist says malicious versions are typically pulled or detected within hours. The first Shai-Hulud worm kept publishing new malicious versions for about two days in September 2025, so a week leaves margin. For a long-lived Drupal site, a week of delay on routine updates costs little.

The exemption matters just as much.

Drupal shipped core security releases rated highly critical in May 2026 and critical in October 2026. Both times, the Security Team warned that exploits might be developed within hours or days. A waiting period must never delay those updates.

For Composer packages from Packagist.org, Dependabot already waits 3 days by default. In dependabot.yml, a 7-day cooldown looks like this:

version: 2 updates: - package-ecosystem: "composer" directory: "/" schedule: interval: "weekly" cooldown: default-days: 7

The cooldown applies only to version updates, never to security updates. That exemption only helps when Dependabot recognizes the advisory. GitHub's reviewed advisories cover Drupal core, often late, but not contrib modules from packages.drupal.org.

Contrib security releases therefore arrive as ordinary version updates. The cooldown does not hold them back either. Dependabot's code reads release dates from a field that packages.drupal.org does not publish, so the 7-day window covers core and other Packagist.org packages, not contrib.

Contrib needs a manual path. Watch the Drupal security advisories and apply those releases directly, and check release dates on routine contrib updates.

The package managers can enforce the same window. npm 11.10 added min-release-age, so min-release-age=7 in the theme's .npmrc sets that window for npm.

Composer's native cooldown is merged but unreleased, and it is planned for Composer 2.11 as policy.cooldown.period set to "7 days". Its documentation measures age from published-time, which packages.drupal.org publishes, so it should cover contrib too. Neither npm nor Composer recognizes security fixes, so urgent fixes need a per-package exemption.

Install-time code can read whatever is in reach

Assume anything running composer update or npm install can read everything in that environment. The payloads above went looking for cloud credentials, .env files, SSH keys, and CI secrets.

Run npm inside the DDEV container rather than on the host, so a script sees the container and not a developer's home directory. Then review what the container and the build runner can actually see, including forwarded SSH agents, hosting tokens, and local settings files with real credentials.

Keep long-lived credentials out of jobs that change dependencies, and give build tokens the narrowest permissions the job needs. Shai-Hulud used the GitHub tokens it found to push workflows into every repository it could reach.

Finally, protect the accounts that publish code. Anyone who maintains packages should turn on two-factor authentication for Drupal.org, GitHub, Packagist, and npm.

Supply chain security is a maintenance habit

None of these controls is exotic. Commit the lock file and install from it. Allow plugins by name, and gate builds on composer audit. Wait a week for routine releases, and apply security releases the same day. Keep credentials away from the moment dependencies change.

Supply chain security is not a scanner we add to a project once. It is how we treat every dependency change.

Travis Tomka

Turn Drupal website inquiries into proposed email replies your team can review. This guide explains how Webform, ECA, and Drupal’s AI framework work together, with practical setup steps and checks before launch.

Your website may have the information people need. But the way they discover and evaluate their options is changing, with AI-generated answers becoming part of the journey.

EAB’s survey of more than 5,000 U.S. high school students, conducted in late 2025 and published in February 2026, 46% reported using AI tools during their college search, up from 26% in spring 2025. A separate EAB survey published in August 2026 found that 57% of more than 2,500 U.S. parents surveyed had used AI to evaluate colleges and compare options for their children.

Together, these findings suggest that students and families are adding conversational tools to the ways they research universities. For institutions, that raises a practical question: could a more guided experience also help people make sense of the information on their own websites?

Growing adoption doesn’t mean trust is guaranteed. Pew Research Center found that 66% of U.S. adults were extremely or very concerned about people getting inaccurate information from AI. For institutions exploring AI-assisted guidance, that makes accuracy, transparency, and testing with real users central to the experience.

For Higher Education institutions, this raises a practical question: could a more guided experience help students and families make sense of institutional information while preserving accuracy, trust, and control?

On October 29, 2026, at 9:30 am PT / 12:30 pm ET / 4:30 pm GMT, join James Hall, Product Lead for Websites at Everyone TV, as he chats with Joe Kwan of the University of Waterloo, and John Tran, CTO at ImageX about “Navigation to Guidance Using AI to Improve Digital Experiences”. They’ll share a behind-the-scenes look at an AI-powered admissions advisor proof of concept, with practical lessons for anyone exploring where AI could improve a digital experience.

Start with the questions people are trying to answer

The University of Waterloo and ImageX began by working with Waterloo’s graduate and undergraduate admissions teams to understand the student journey.

Where were students getting stuck? Which questions came up repeatedly? Where did search and navigation fall short? And when did students need guidance from a person?

Those conversations shaped a conversational prototype designed to help prospective students find trusted information, compare programs, understand requirements, and navigate next steps.

The project offers a useful starting point for other organizations: identify a specific moment where people struggle, then explore whether AI could help. That gives teams a concrete problem to investigate and a clearer basis for deciding whether to invest further.

Find out what users actually think

A working prototype is only part of the story. The team also tested the experience directly with prospective students. Research showed strong interest in a more conversational way to explore university information. It also surfaced important considerations around privacy, tone, usability, content quality, transparency, and trust.

The webinar will explore what the team learned through that testing and where human guidance remains essential.

The session will focus on discovery, prototyping, and user research, and what those stages can help an organization understand before moving toward production.

Where Drupal fits

An AI-assisted experience raises questions about the information behind it: Where does it come from? Who maintains it? How is it reviewed? And what happens when it changes?

For the Drupal community, the session will explore the role Drupal can play as the governed content foundation behind these experiences, connecting AI assistance to institutional information that an organization manages and trusts. For marketing, digital, and service leaders, the broader question is equally relevant: how can you make information easier to use while retaining oversight of its quality and accuracy?

You don’t need to work with Drupal or in higher education to benefit from the discussion. The approach is relevant to teams considering AI for complex information journeys across nonprofits, public services, and businesses.

What you’ll take away

Join the webinar to explore:

• How discovery with internal teams can uncover AI use cases worth investigating.
• What prospective students thought about using AI to explore university information.
• What user testing revealed about trust, privacy, tone, transparency, and usability.
• Where human guidance remains essential.
• How governed content can support AI-assisted experiences.
• How to validate an idea with real users before moving toward production.

Whether you’re a Drupal practitioner, a higher education leader, or someone responsible for a complex website, this session offers a practical example of moving from an AI idea to an experience you can test and evaluate.

Join James Hall, John Tran and Joe Kwan on October 29, 2026, at 9:30 am PT / 12:30 pm ET / 4:30 pm GMT for From Navigation to Guidance Using AI to Improve Digital Experiences.

Register for the webinar →

With Drupal 12 on the horizon and Drupal 10 reaching end of life in December, I'm facing two challenges. First, I need to upgrade my current site from Drupal 10 to Drupal 11. Second, I need to update my contributed modules to support Drupal 12, while still supporting Drupal 10. Frankly, I am more anxious about upgrading to Drupal 11 and supporting Drupal 12 than about integrating AI into my workflow.

Upgrading to Drupal 11

Upgrading to Drupal 11 has gotten easier over the years thanks to tools such as Drupal Rector, the Drupal Lenient Composer Plugin, the Upgrade Status module, and the Project Update Bot. Still, if you rely on contrib and custom modules, you'll have a lot to tweak and test.

I've done a "big-bang" upgrade via a dedicated branch, using the Lenient plugin and the Project Update Bot's patches for contrib modules, and fixing deprecations in custom code with Drupal Rector. There were always a few rough edges. Ideally, I'd like to gradually test my upgrade to Drupal 11 while continuing to support Drupal 10 in the same codebase using the DeprecationHelper.

As a maintainer of a contributed module, I face a slightly different challenge: supporting Drupal 12, 11, and 10.

Supporting Drupal 10, 11, and 12

As a maintainer of multiple contributed modules, I need to test them across previous, current, and next Drupal versions. I typically use dedicated DDEV instances for each Drupal version. I've started using Git worktrees to maintain a single Drupal playground with branches for each Drupal version. Still, maintaining a composer.json file that targets different Drupal versions across branches is challenging because it...Read More

A second workplace platform may help governments survive a technology disruption. Whether it also gives them the freedom to leave a dominant supplier is a harder test.

We are back from Rotterdam, and we are still blown away. Three weeks later we are still processing what happened. We brought a whole bouquet of topics: structured concurrency for PHP, Translation Bliss, our page builder session and CrowdPower.Digital. Some days felt a bit like a movie. One conversation led to the next, and suddenly we were at a table with people whose names we have read in the issue queue for years.

Nearly two decades after development began, Outer-Core is evolving without starting over. Alessandro Feijó explains the decisions behind its revival.

PHP2Shell, and DDEV v1.25.5

On October 21, PHP released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619, nicknamed "PHP2Shell". A single unauthenticated request could run code on any server running PHP. PHP's security advisory↗ has the details.

Local DDEV projects listen only on your own computer, so nobody on the internet could reach them. Projects exposed with ddev share or used for casual hosting↗ were at risk, and so were your production servers. Stas wrote up the same day what DDEV users needed to do, including how to get the fixed PHP into projects before a new DDEV release: PHP2Shell: What DDEV Users Need to Know.

DDEV v1.25.5 shipped on October 26 with the fixed PHP in ddev-webserver. PHP 8.1 and older are past end of life and get no fixes from PHP, but deb.sury.org patched every version it ships, so PHP 5.6 through 8.1 in DDEV are fixed too. Upgrade, run ddev restart, and check ddev php -v. If you haven't updated PHP on the servers where your sites are hosted, do that first.

v1.25.5 also brings 142 community PRs that were waiting for the next release:

• A rebuilt ddev tui that fits any window and shows database addresses, snapshots, ports, and add-on updates
• ddev config global --ssh-agent-upstream=host, so containers use the SSH agent you already run (macOS agent, 1Password, Secretive, YubiKey)
• ddev restart -s <service> to recreate only the services you name
• QR codes from ddev share and ddev launch --qr, replacing the ddev-qr add-on
• zstd for ddev import-db, ddev export-db, and ddev import-files
• Global hooks, and global_config.*.yaml files merged over global_config.yaml
• Initial PHP 8.6 support (RC3, which doesn't have the PHP2Shell fixes yet)

The release post covers these and the changes that might affect you.

Standing on the Shoulders of Giants

DDEV couldn't have shipped a PHP fix this way on its own. It has always depended on two upstreams that most PHP developers rely on without thinking about them.

Ondřej Surý has packaged PHP for Debian since PHP 5, and maintains deb.sury.org↗, the repository that ddev-webserver, the ondrej/php PPA, and a large part of the PHP world install from. On the day of the PHP release, he published fixed AMD64 packages for every PHP version back to 5.6, including versions PHP itself no longer supports. As he writes on his site, "The PHP packaging is time consuming and I do this mostly in my free time." The BBC told his story in How one man became the unsung hero of the internet during a cyber-security scramble↗. His day job is director of DNS engineering at ISC↗, the nonprofit behind the BIND DNS server, and when the PHP2Shell details leaked early he had less time than planned to build the packages: "The feeling is like I am responsible for all these people and I can't fail them." Donations that week passed $10,000, which he said was "basically about a year's worth of the contributions that I got before." His message to the companies that depend on his packages: "If you just take and don't give back then it will backfire."

The PHP Foundation leads development and maintenance of PHP itself, including the security work behind releases like this one. The team is small for a language that runs so much of the web. "We have one full-time staff member (that's me) and 14 mostly part-time contractors," Executive Director Elizabeth Barron told CNA↗ after the release, adding that "it is clear that PHP is incredibly under-funded." In 2025 its developers made 2,929 commits across 9 PHP repositories and reviewed 1,685 community PRs in php-src (2025 impact report↗). On release day it also published Today's PHP Security Release, and How We're Strengthening PHP Security↗.

The DDEV Foundation has sponsored both for years, because DDEV is built on their work. If PHP is part of how you make a living, please support them too:

• Ondřej Surý: GitHub Sponsors↗ or Open Collective↗. Companies that need a supported PHP for older versions can look at PHP LTS from Freexian↗.
• The PHP Foundation: Open Collective↗. Company memberships are on the sponsor page↗.

Community Projects

DDrovr: a native macOS app for DDEV — A SwiftUI desktop interface from Bison Digital for projects, logs, databases, Git, and settings, with start and stop from the menu bar. It runs the DDEV CLI and reads .ddev/ rather than replacing anything. Version 1.0.3 needs macOS 14 and DDEV v1.24 or later. ddrovr.com↗

ddev-openlitespeed — An add-on from morvy that replaces DDEV's web server with OpenLiteSpeed running lsphp, for PHP 5.6 through 8.5. It honors .htaccess and works with the LiteSpeed Cache WordPress plugin. Install with ddev add-on get morvy/ddev-openlitespeed. GitHub↗

ddev-clim — A small terminal UI from lemachinarbo for starting and stopping DDEV projects, which can also restore your running projects at boot, with a systemd user service on Linux. Available from the AUR. GitHub↗

Mage 3.0 detects DDEV — Sean van Zuidam's CLI for Magento 2 and Mage-OS now detects DDEV and runs its commands inside the container, so mage cache:clean works without ddev exec. Release post↗

Talks and Tutorials from Around the Web

• What's New in DDEV for TYPO3 Folks, October 2026 → Snapshots and seeded databases, Branchery, TYPO3 Quickstarter, Knecht, and PHP2Shell, for TYPO3 developers. Read on news.typo3.com↗
• René Kreijveld at Joomla World Conference → Joomla development with DDEV. View the slides↗
• DDEV for Drupal: setup, import, and export → Nadeem Mir of Dynamosys on setting up a Drupal 11 project, importing a site's database and files, and exporting it again, with warnings about what ddev import-db and ddev import-files overwrite. Read on dynamosys.com↗
• Migrating a 13-year-old WordPress blog to Drupal CMS → Christian López Espínola (penyaskito) moved a 722-post blog to Drupal CMS 2.2. The WordPress clone ran as its own DDEV project, and the Drupal project read its database container directly with wordpress_migrate_sql across 24 migrations. Read on penyaskito.com↗
• Import a WordPress site with BackWPup → Matthias Andrasch shows how to pull a BackWPup backup into DDEV with a custom provider and ddev pull backup. It's from 2023, so adjust the versions in the example config. Read on dev.to↗

DDEV Live Training

All sessions are open to everybody.

Shopware with DDEV, with Benny Poensgen — The October 21 session is recorded. Watch the recording↗, browse the slides↗, or read Benny's Shopware on DDEV post.

Hobobiker Rides Again, at the Drupal AI Learners Club — Randy, Amber Matz, and Angie Byron are migrating hobobiker.com, a Drupal 6 site from 2009, with Claude, live and in three parts. Everything runs in DDEV, and the repository, a sanitized database, and the slides are linked from the hobobiker.com README↗.

• Part 1, Road Test (October 16) → Before migrating anything, Claude wrote a Playwright test suite against the old site. Working from the raw Drupal 6 database, it found the content types on its own, knew to use only the latest node revisions, and flagged problems nobody asked about, including database backups that anyone could download. Watch the recording↗ or read the club's recap↗.
• Part 2, The Last Ride (October 23) → Claude retired the site as static HTML, following Lullabot's "Sending a Drupal Site into Retirement" and checked against the tests from Part 1. The archive is now live at static.hobobiker.com↗. Watch the recording↗ or read the club's recap↗.
• Part 3, The Long Haul (Friday, October 30 at 10:30 AM US Mountain / 12:30 PM US Eastern / 17:30 CET) → Drupal 6 to Drupal 11. Claude explores the source and the destination and writes a migration plan before touching any code, and the finished site has to pass the same test suite. Register on Luma↗

The next DDEV training session:

• November 11, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CET — Advanced Coder.ddev.com Techniques
  Using the coder CLI, local and web-based VS Code, and remote-controlling Claude, including the freeform template.
  Add to Google Calendar • Download .ics

Zoom Join Info:
Link: Join Zoom Meeting
Passcode: 12345

Governance

• The next DDEV advisory group meeting, open to everybody, is November 4, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CET. Add to Google Calendar • See the agenda. We love to hear from our community!

Sponsorship Update

We so appreciate all of you supporting the project!

September 2026: ~$10,099/month (84.2% of goal)

October 2026: ~$10,239/month (85.3% of goal)

If DDEV has helped your team, consider sponsoring. → Become a sponsor↗

Contact us to discuss sponsorship options that work for your organization.

Stay in the Loop—Follow Us and Join the Conversation

• Blog↗
• LinkedIn↗
• Mastodon↗
• Bluesky↗
• Discord↗

Compiled and edited with assistance from Claude Code.

Aidan Foster's keynote on adapting to AI: balance cheap execution with human judgment, deep customer relationships, and strategic creativity.

On October 25, Akismet turns 21. We’re celebrating with a few new guests: an official Drupal module, a PHP SDK, and another year of improvements to our WordPress plugin. Spam still isn’t on the list.

Akismet launched in October 2005 to help people spend less time dealing with comment spam and more time enjoying their blogs. The web has changed a lot since then. People build communities, collect inquiries, accept donations, and create applications on all kinds of platforms. Each of those places gives people a way to contribute. It also gives spammers somewhere to try their luck.

Since then, Akismet has blocked over 570 billion pieces of spam. Every one is something a site owner didn’t have to spend time sorting through. Our birthday wish is to keep making more room for the real people.

Welcome, Drupal

This year, we released the official Akismet Drupal module, built by the team behind Akismet. It brings our spam protection to Drupal comments, contact forms, webforms, and user registrations, with tools for moderators to review submissions and send corrections back to Akismet.

We’ve continued building on that welcome. The latest release supports Drupal 12 and passes richer bot-detection signals into spam scoring. On Drupal 12, comments and registrations are supported now; contact forms, webforms, and the Key module will follow as those modules become ready for Drupal 12.

For people using the older community module, we also built an upgrade path to the official module that carries their API key and protection settings across. The migration guide explains the requirements and which settings need attention.

Welcome, PHP developers

Akismet’s API has long made it possible to protect sites beyond WordPress. This year’s official PHP SDK gives developers a first-party client for bringing that protection into their own PHP applications, including projects built with Laravel or Symfony.

The SDK handles the Akismet API integration so developers can focus on their application. It supports checking submissions, reporting spam and legitimate content, and retrieving usage and account information. The official Drupal module uses it too.

If you’re building a place where people can post, sign up, or send a message, there’s a new tool to help you keep the spam out.

A familiar guest, with a few improvements

WordPress has been with us from the beginning. This year, we kept improving that experience: clearer setup and error messages, accessibility improvements, better detection of automated submissions, and compatibility fixes. You can find the details in the WordPress plugin release log.

Version 5.7 also added support for Abilities and Connectors, helping Akismet fit into WordPress’s evolving tools for integrating external services.

More room for real people

A comment worth replying to. A message from a future customer. A donation to a cause someone cares about. Those are the things we want coming through.

Thank you to everyone who uses Akismet, builds an integration, reports a problem, or helps us improve. You’ve been part of these 21 years, and you’re very much invited to the celebration.

Whether your site runs on WordPress, Drupal, or something you’re building yourself with the PHP SDK, there’s room at the table.

Just no room for spam.

Try out the Drupal module today!

Opening access is only the first step. Sustaining the people, institutions and infrastructure that keep knowledge available is the greater challenge.

Behind every published research paper lies years of work, often supported by public funding. Yet the institutions producing that knowledge do not necessarily control how it reaches the world. New research released by SPARC on 14 October, ahead of International Open Access Week, estimates that more than 95% of investment in a typical research article occurs before publisher submission, based on its accounting model. A companion study found operating margins of 24% to 38% among major academic publishers in 2025. The figures raise an uncomfortable question: who should benefit from knowledge that society has largely paid to create?

Removing paywalls is important, but it does not automatically make scholarly publishing fair or sustainable. Some open-access models shift costs from readers to researchers through publication fees, potentially excluding scholars with fewer resources. Alternatives exist. Harvard Library, for instance, supports journals that charge neither authors nor readers. Such models still require institutional investment, editorial labour and dependable technology. The real challenge is not simply making research available, but ensuring that openness does not depend on another form of exclusion.

The same challenge extends to the infrastructure behind public knowledge. A 14 October appeal from SCOSS sought renewed funding for the Research Data Alliance and Software Heritage, noting that insufficient funding had delayed some planned standards work. Open-source communities understand these pressures. Drupal, for example, supports complex institutional publishing environments, including a UK university platform managing more than 190,000 research records. Maintaining such systems requires continuing work on security, accessibility, data management and technical reliability. The software may be open, but the responsibility of sustaining it remains substantial.

Perhaps the most important lesson from this year's Open Access Week is that openness needs a long-term commitment, not just a declaration of principle. Universities, governments and other institutions should treat shared digital infrastructure as an essential public investment, with predictable funding, accountable governance and support for the people maintaining it. The open-source movement has demonstrated what communities can build together. Its continuing challenge is ensuring that those contributions remain useful and accessible for generations. Knowledge should belong to everyone, but keeping it that way must also become everyone's responsibility.

Follow The DropTimes on LinkedIn and Bluesky, or join #thedroptimes on Drupal Slack.

Kazima Abbas wrote and curated this issue of Editor’s Pick.

Drupal.org accepts AI-assisted work only from contributors who have checked it, can explain every change and say when a tool wrote a significant share.

Colour choices can influence how people experience a website, but assumptions about emotion and culture need testing. Kanopi Studios' Anne Stefanyk shares three practical ways to make colour decisions more consistent, evidence-led and accessible.

Everyone’s talking about the 9.2 PHP vulnerability that dropped on a Wednesday evening. We patched 30+ Drupal sites in 24 hours with zero downtime. Here’s what our audit found next.

We checked the homepages and platforms of 95 of the world's most-visited museums. What the best museum websites put first, and which CMS they run.

In a Talking Drupal Cafe conversation, Stephen Cross chats with recent Talking Drupal Guest Host, Tim "Tea Sharp," a relatively new Drupal user at Appalachian State University, starting with a light discussion about a 3:00 PM drink before digging into Tim's path from sustainability science and design through nonprofit work, WordPress site building, and finally Drupal in higher ed. Tim describes learning Drupal 7, discovering Views, and then helping his team manually consolidate hundreds of departmental subdomain sites while migrating to Drupal 10 using a product approach and a shared distribution initially built with Lullabot. He discusses training and documentation for non-technical site managers, professional development through DrupalCon Atlanta and Drupal Camp Asheville, interest in Drupal AI for tasks like alt text generation, and aspirations to keep speaking, contribute more, and improve module discoverability and documentation.

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

Topics

• Finding Talking Drupal
• From Sustainability to Design
• Pandemic Pivot to Web
• WordPress Site Builder Era
• Discovering Drupal at App State
• Drupal 10 Rebuild and Consolidation
• Team Structure and Iteration
• AI in Drupal Workflows
• Upgrade Blockers Cleared
• Aspiring Drupal Speaker
• Raycast Productivity Talk
• Stage Fright Reframed
• Posting Beyond Comfort
• Finding a Username
• Joining Talking Drupal
• Better Module Discovery
• Open Source Burnout Lessons
• Why More TD Cafe
• Final Encouragement

Tim Sharp

Tim is a self-taught Web Developer at Appalachian State University in Boone, North Carolina. At App State, he works with a team of developers to support over 300 websites. Tim is passionate about community organizing and recently became a co-organizer of Drupal Camp Asheville.

Stephen Cross

Stephen is the founder of Talking Drupal and Drupal Developer.

Guests

Tim Sharp - tea-sharp Stephen Cross - stephencross

DDEV v1.25.5 is out sooner than we planned, because PHP published fixes for two critical vulnerabilities and we wanted ddev-webserver to ship them. It also brings 142 PRs from the DDEV community that were already waiting for the next release: your suggestions, bug reports, code, and financial support made them possible.

Table of Contents PHP Security Fixes

ddev-webserver now ships PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, which fix CVE-2026-109618 and CVE-2026-109619 ("PHP2Shell"). Projects on PHP 5.6 through 8.1 get deb.sury.org's fixed packages too, because upgrading DDEV rebuilds their web image. Every project picks up the fixed PHP the next time it starts. PHP2Shell: What DDEV Users Need to Know explains who is affected.

DDEV now applies two of PHP's mitigations by default: session.upload_progress.enabled is 0 in every PHP version, as PHP's October 23 advisory suggests, and fatal_error_backtraces is 0 in PHP 8.6. Few applications use session upload progress, and the PECL uploadprogress extension that Drupal uses isn't affected. To turn either back on, see Custom PHP Configuration.

/phpstatus now answers only requests from inside the web container, and with nginx-fpm, PHP files in CMS upload directories no longer run. If you removed #ddev-generated from .ddev/nginx_full/nginx-site.conf, merge the new rule into your copy.

Initial PHP 8.6 Support

You can test a project on PHP 8.6 before its final release:

ddev config --php-version=8.6 && ddev restart

DDEV ships 8.6.0 RC3, which doesn't have the PHP2Shell fixes yet, because deb.sury.org hasn't packaged RC4. The mitigations above don't cover everything, so don't expose a PHP 8.6 project. Some extensions aren't packaged for 8.6 yet either, and enabling Xdebug, XHProf, or Blackfire on it shows an error instead of breaking the container.

A Rebuilt ddev tui

Running ddev with no arguments opens the TUI, and it has a new layout that fits any window size and shows the project list before Docker responds. Here are 15 projects, 10 of them running, in v1.25.4 (top) and v1.25.5 (bottom). The list now says how many projects are running, and the header shows the health of the SSH agent next to the router:

The project view adds the database address from your host, from the project, and from other projects; snapshots; the published ports of every service; and add-ons that have an update available, like ddev-redis here. When it doesn't fit the window, it scrolls:

Paths and URLs are clickable links, and o, v, and p open the project in your file manager, VS Code, or PhpStorm. D deletes a project, thanks to @MitraKumar. ? lists every key, and the help now fits the window:

Two keys changed: R restarts and r refreshes, swapped from before, and only enter opens the project view.

SSH Agent Passthrough

If your SSH keys live in an agent instead of ~/.ssh, such as the macOS agent, 1Password, Secretive, a YubiKey through gpg-agent, or an agent forwarded with ssh -A, DDEV's containers can now use it directly:

ddev config global --ssh-agent-upstream=host ddev auth ssh # lists the keys your containers can use

After that, every project uses your agent, and there are no key files to add with ddev auth ssh. DDEV also follows a symlinked agent socket, such as VS Code Remote's /tmp/vscode-ssh-auth-sock-*. Which agent your containers get on macOS depends on your Docker provider, and Rancher Desktop and Podman aren't supported; Using an Existing SSH Agent has the table.

Restart Only the Services You Name

ddev restart -s recreates the services you name and leaves the rest of the project running:

$ ddev restart -s redis Restarting redis in project docs-portal... Building images for [redis].... built in 1.0s Container Recreated: ddev-docs-portal-redis Container Started: ddev-docs-portal-redis Waiting for containers to become ready: [redis]... ready in 0.5s ddev-router already running, pushing new config... ready in 0.9s Restarted redis in docs-portal

That took under four seconds here. It takes a comma-separated list, as in ddev restart -s solr,redis, and ddev utility rebuild -s now accepts several services too. ddev restart --profiles=x replaces ddev restart && ddev start --profiles=x.

Interrupting DDEV is also safer now. Ctrl-C, SIGTERM, or closing the terminal no longer leaves temporary containers like start-chown-* holding project volumes, and interrupting ddev import-db, ddev export-db, or ddev snapshot leaves no partial dump or snapshot behind.

QR Codes for ddev share and ddev launch

ddev share prints a QR code for the tunnel URL, so you can open the shared site on your phone without typing it. ddev launch --qr prints the project URL with its QR code:

This replaces the ddev-qr add-on, which ddev start now removes. Thanks to @tyler36, who started all of this in ddev-qr.

zstd for Database and File Imports and Exports

ddev import-db and ddev import-files accept zstd files, and ddev export-db picks the format from the file extension:

ddev export-db -f db.sql.zst ddev import-db -f db.sql.zst

--compression chooses gzip, bzip2, xz, zstd, or none explicitly. One consequence: ddev export-db --file=x.sql now writes plain SQL. Before, it wrote gzip data to a file named .sql.

Global Hooks and global_config.*.yaml

Global hooks in ~/.ddev/global_config.yaml run for every project, before the project's own hooks:

hooks: post-start: - exec-host: "echo a global hook ran"

A project can opt out with skip_global_hooks: true. global_config.*.yaml files in ~/.ddev are merged over global_config.yaml, the way config.*.yaml files are in a project, so a team can hand out a global_config.team.yaml without touching the file DDEV rewrites. Check ~/.ddev for leftovers like global_config.old.yaml, because those are merged now too.

New pre-delete and post-delete hooks clean up files a project created, without doing it on every ddev stop, thanks to @wazum.

Changes That Might Affect You

• WP-CLI, Drush 8, the Backdrop Drush extension, magerun, magerun2, and Symfony CLI are installed only in the project types that use them. To use one elsewhere, add it in a web-build Dockerfile; see Project-Specific Utilities.
• A custom service or add-on whose container_name isn't ddev-<project>-<service> is renamed, with a warning. Reach it by its service name instead.
• DDEV assigns host ports itself. Unconfigured db, web, and Mailpit host ports move to 20000-29999 the next time their containers are created, and the router's fallback ports move to 30000-32000. Ports you set with host_*_port don't change.
• --profiles replaces COMPOSE_PROFILES, as in Docker Compose, so on a stopped project ddev start --profiles=x no longer starts the profiles in COMPOSE_PROFILES as well.
• ddev delete exits with an error and keeps the project listed when it can't remove a volume. Before, it reported success.
• DDEV_DEBUG no longer shows per-layer image download progress or routine start messages; DDEV_VERBOSE does.
• The database buffer pool drops from 1024M to 512M, which can slow large imports, and each project's database volume grows by about 160-210M on the first start after upgrading. On MySQL 8.0, 8.4, and 9.7 and MariaDB 11 and later, the connection collation is now utf8mb4_unicode_520_ci, matching the server's.

Regressions, Fixed

• Directory listing works again. The 403 explanation page in v1.25.4 had disabled it for every project.
• ddev composer create-project again passes flags like --no-dev and -vvv to the Composer scripts it runs after creating the project, which v1.25.3 stopped doing.
• Magento, Magento 2, and Maho show their own 404 pages again, instead of DDEV's explanation page, thanks to @gunnie-agency.

Everything Else

ddev list, ddev describe, and ddev tui respond faster, and the more projects you have running, the bigger the difference. nginx passes PATH_INFO to PHP, so URLs like /index.php/foo/bar work as they do with Apache, and running ddev start or ddev poweroff in several terminals at once no longer breaks the shared router. See the release notes for the rest.

From all of us, thanks for using, promoting, contributing, and supporting DDEV!

If you have questions, reach out in any of the support channels.

If you wonder how all this could be done, it's because of generous sponsors who let two of us work on this every day. If you and your team aren't already financially supporting DDEV, consider joining our sponsors.

Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.

This article was edited and refined with assistance from Claude Code.

PHP2Shell: What Happened and How to Know Your Site Is Safe demet Fri, 10/23/2026 - 10:18

A pair of critical PHP vulnerabilities affected much of the web this week. Here’s how they were fixed, how to check your site, and how to stay protected going forward.

This week’s disclosure of PHP2Shell, a pair of security vulnerabilities that impacted up to two-thirds of the internet and resulted in the temporary shutdown of many high-profile websites, was, for many people, the first real look at how AI is changing digital security. The vulnerabilities are now patched, and if you’re a Palantir.net client, your sites are protected. Below, we explain what happened, how to confirm your site is safe, and how to stay protected going forward.

Those of us who design, develop, and support digital applications have anticipated a disclosure like this for some time. Over the last year or so, AI coding tools have grown increasingly capable of finding and exploiting previously undetected software vulnerabilities.

The good news is that the same tools are also helping the people who build and maintain software find and fix vulnerabilities faster. Many open source software projects have dedicated security teams that work in collaboration with other projects and organizations like Alpha-Omega, who have access to security-focused AI models that are not available to the general public.

What is PHP2Shell, and who was impacted by it?

PHP2Shell is the collective name given to a pair of critical vulnerabilities discovered in PHP, a popular scripting language that many websites and web applications are written in, including content management platforms like Drupal, WordPress, and Joomla, as well as the software that powers Wikipedia. It is estimated that between half and two-thirds of sites on the internet run on PHP.

The vulnerabilities affect all versions of PHP released in the last 20 years. They allow attackers to run executable code on a target’s server and access passwords and other sensitive data stored in process memory. These flaws had been present in PHP for many years, but there were no known ways to exploit them until an independent audit of the codebase using AI tools was conducted in August.

How were the PHP2Shell vulnerabilities fixed?

Because the vulnerabilities exist in the PHP code itself, the only way to fix them was with a software patch written by the PHP security team, a very time-consuming process given the complexity and sophistication of the issue. Following established best practices, this work was conducted privately, because once the vulnerabilities were disclosed publicly, they could be exploited by malicious actors.

On October 20, the PHP security team issued an advisory that a critical security patch would be released the following day, giving software vendors and the general public time to prepare. The patch was then released on the 21st at 9am Central US Time  (14:00 UTC).

At that point, web hosting and application vendors began integrating the patch into their software, testing it to make sure that it didn’t break pre-existing configurations or take their clients’ sites offline. Many hosting and developer platform companies, including the ones who host our clients’ sites, implemented short-term mitigations designed to temporarily protect their sites while the patch was still being rolled out; others simply took their sites offline until the patch was deployed.

How do I know if my site is safe from PHP2Shell?

You can tell if your website or application is protected by confirming it is running one of the latest supported versions of PHP. If you’re running a content management platform built in PHP, like Drupal or WordPress, you can look up the PHP version number in your site’s administrative interface:

• Drupal: by going to “Status Report” in the “Reports” menu.
• WordPress: by going to “Site Health” in the “Tools” menu, then clicking on “Info” and opening the “Server” section.

Your site should be running one of the following versions of PHP:

• 8.5.12 (or better)
• 8.4.27 (or better)
• 8.3.36 (or better)
• 8.2.35 (or better)

Keep in mind that updating Drupal or WordPress does not update the version of PHP running underneath it. PHP updates come from your server or hosting provider, and the server typically needs to be restarted before the patched version takes effect.

If you are running PHP version 8.1 or earlier, it is still possible that your site is protected, but you will need to confirm this with your hosting provider. The PHP team did not release official updates for these older versions; it published only minimal source code fixes that hosting providers must apply themselves.

Is it possible that my site was hacked before the patch was applied?

While some information about the PHP2Shell vulnerabilities was leaked in advance of the patch’s release and both Amazon and Cloudflare have reported early attempts to exploit them, there are currently no confirmed reports of any successful attacks before the patch was released.

Sites that use Cloudflare’s web application firewall (WAF) received protection more than 10 hours before the patch’s release, and as mentioned above, many hosting providers, including those who host our clients’ websites (Acquia, Pantheon, and Upsun), also applied temporary mitigations. The Drupal Association has posted information on how administrators can audit their sites to see if they were probed in the days leading up to the patch’s release.

How can I protect my site from future security vulnerabilities?

The best way to be sure that your site remains secure is to keep it up to date with the latest security releases. This includes not only server-level languages like PHP, but the applications that run on top of them like Drupal and WordPress.

We utilize automated security scanning to ensure that critical issues that impact your site’s content management platform are identified and addressed as quickly as possible. Our proactive approach anticipates potential issues instead of reacting to them, so you’re prepared when a new vulnerability is announced.

As an example, just one week before the release of PHP2Shell, a patch was released to address a critical vulnerability in Drupal’s core software. We made sure that all of our clients’ sites were up to date in advance of the patch’s release, applied mitigations within an hour of its release, and had all sites patched within three hours.

We also partner with hosting platforms like Acquia and Pantheon who are part of the Drupal Steward Program, which provides mitigation for critical Drupal security vulnerabilities in advance of their official release. In addition, these partners have long and well-established records of keeping their platforms secured from threats that occur outside the application layer.

Staying secure as AI changes the landscape

AI is speeding up security work on both sides. The same tools that uncover vulnerabilities are also helping maintainers, hosting partners, and teams like ours find and fix them faster. Staying secure in this environment comes down to steady habits: keeping every layer of your site current, working with hosting partners who mitigate threats early, and having people watching on your behalf.

If you’re a Palantir.net client, there’s nothing you need to do. Your sites are running patched versions of PHP, and our team continues to monitor for new issues. If you’re not a client and want help confirming your site is protected, or want to build a support plan that keeps you ready for the next disclosure, get in touch with us.

Cover illustration created using Google Gemini.