fidzu : Drupal

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

27 Oct 2026 12:47pm GMT

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.

27 Oct 2026 12:31pm GMT

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.

27 Oct 2026 11:16am GMT

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

27 Oct 2026 10:35am GMT

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

26 Oct 2026 3:27pm GMT

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!

26 Oct 2026 3:16pm GMT

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.

26 Oct 2026 3:03pm GMT

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.

26 Oct 2026 2:26pm GMT

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.

26 Oct 2026 12:26pm GMT

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.

26 Oct 2026 11:28am GMT

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.

26 Oct 2026 7:00am GMT

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

26 Oct 2026 1:18am GMT

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.

26 Oct 2026 12:00am GMT

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.

23 Oct 2026 3:18pm GMT

Major Drupal conferences can be difficult to attend for people with limited budgets or family commitments. Megan McDermott explains why regional events matter and how local sponsorship helps bring learning opportunities within reach.

23 Oct 2026 2:47pm GMT

How much should developers trust AI, and what changes will Drupal 12 demand of maintainers? Nine speakers share practical lessons on development, accessibility, infrastructure and governance ahead of Southwestern Ontario Drupal Camp.

23 Oct 2026 2:12pm GMT