Drupal projects are moving their issues from Drupal.org to GitLab work items, and ContribKanban couldn't see them. I rebuilt it so that one board tracks both.

A familiar WordPress design can now become an editable Drupal site. But what survives the conversion, who maintains the result, and how close is the experiment to working on real projects?

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.

Discover Drupal Canvas beyond the UI: leverage open-source CLI and Nebula toolchains to manage components, pages, and Git-based workflows.

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.