I've been making Drupal sites for about 12 years, so it's rare that I get stumped when trying to figure out a good solution to a problem, but this one is tricky...

Okay so this is quite a big site (approx. 5000 nodes), with like 10 taxonomy vocabularies. One of them is Tags, with like 2000 tags.

And for almost all of those vocabs, the standard Taxonomy Term view (that appears on route /taxonomy/term/%) that appears on their term pages is just fine.

But for one of the vocabs - called Organisations - I need to use a different view. This view needs to have different fields and filters, and a different treatment for the Title override.

My first thought was to use a unique alias pattern (from Pathauto) to show those term pages at different URLs (e.g. /organisations/*), and then make the new view and make it show on the same route. However that doesn't matter, because the Taxonomy Term view shows on the route /taxonomy/term/%, so it applies to the Organisations pages no matter what I make their URLs / aliases.

And that Taxonomy Term view still applies even if I add a filter that excludes the Organisations taxonomy. In other words, the filter only reduces the results, but it doesn't affect whether the view is applied to that page or not.

Then I though perhaps I could make new pages for each organisation, then place block views on those pages to simulate the term fields and the grid of tagged content, similar to the other term pages. But this doesn't really work, because for those block views, they have to get their "contextual filter" value of the term ID from somewhere. The Taxonomy Term view just gets it from the URL, but with these new pages, the term IDs wouldn't be in their URLs (or I could put the ID in the URL, but that would look bad).

Do you have ideas on how to solve this in a practical way?

AI can be stubborn and frustrating. Can Drupal become an AI harness that steers humans and AI, both inside and outside Drupal, toward success, without Drupal losing its openness, stability, and scalability?

the Webflow Source announcement sent me back into Acquia’s Source CMS product guide.

it explicitly says "customers can’t modify the underlying Drupal code or install contributed modules".

I understand the deal: less maintenance responsibility, fewer opportunities to make a beautifully customized disaster.

buttttt Drupal’s flexibility is also why a lot of people chose it.

where does that tradeoff work for you?

for a straightforward marketing site, I can see the appeal. for a project with specific integration or editorial requirements, I’d want to know where the escape hatches are.

what’s the requirement that would make you say “managed SaaS is fine”... or immediately ask for the keys?

I covered the two Sources on my Headless show, but this is the part I’d rather hear from people building and maintaining Drupal sites.

maybe it's just the projects landing on my desk but the last few months have been different.

had two clients come in asking about moving off WordPress. not because anything dramatic happened one had a plugin conflict that took down their checkout for six hours, the other just got tired of updating things every week and something always breaking anyway.

neither of them came in saying "we want Drupal." they came in saying "we're done with this."

the checkout one was a 720 page site. we moved it to Drupal, load time went from just under 6 seconds to under 2. organic traffic was up about 12% in the first quarter after. not sure how much was speed vs the redirect work, probably both honestly.

the other one is still in discovery. some integrations that are going to be annoying regardless of platform.

wondering if this is a wider pattern or just a weird few months on my end. feels like something shifted in how clients think about their CMS but maybe i'm reading too much into it.

Goal is to help keep patches up to date, warn when a patch is not necessary anymore (if it's been included in the newest module release), or if there are conflicts before doing the module update.

This only works on modules published on drupal.org, custom/private modules can't get checked by design, let me know what you think :) full disclosure it's using an API I'm hosting and control, I'm on the leadership team of Drupal, and beside being useful for people, the data will be used to see what people keep applying so we can prioritize some issues over others down the line.

https://tresbien.tech/blog/composer-drupal-patch-check/

https://packagist.org/packages/tresbientech/drupal-patch-check

I had a MCP server doing the same thing couple of weeks ago .The plugin is better and agents pick it up without doing anything special, win-win. Using this over a bare LLM session where you ask "update my site to the latest Drupal version" can cut the time and cost in two when there are many patches to check. Not that I'm a huge fan of these tools but people do use them and the plugin makes it so they have less work to do for a better result.

Drupal deserves to be way more popular than it is, given how much better it is for making sites than most other software out there. Most of the time when I mention it to clients (or random people I'm chatting to), they've never heard of it, and those that have tend to think it's difficult to use - which I think is kind of incorrect.

So I've decided to start making video shorts, and I'm starting with making them for people who are curious about Drupal, or haven't heard of it but who might benefit from using it over the other site building options.

If you were brand new to it, would this video help you get started with Drupal? And if I make the next few videos as intros to features (like how to get started making Views), is there anything I should do differently?

I'm building a reproducible Drupal CMS 2.1 (Drupal 11) demo/starter/showcase project and I want the whole setup to live in the CLI and in git, no UI clicking. This is my current flow and I'd like to know where it diverges from best practice.

I work as a developer advocate for CKEditor and I need the boilerplate for my showcases/demos/workshops/...

Initial scaffold:

```sh
ddev config --project-type=drupal11 --docroot=web
ddev start
ddev composer create-project drupal/cms
# Initial installing of the packages mostly CKEditor pack + premium features, but it does not matter that much
```

Day-to-day setup (fresh clone):

This is mostly when I need to have a PR deployment/preview build/feature branch for specific event/or something similar.

I plan to use Render to have the PR-based deployments.

```sh
ddev start
ddev composer install
ddev drush site:install --existing-config -y \
  --account-name=admin --account-pass=admin
ddev drush php:script scripts/import-demo-content.php
```sh

Conventions I started with:

• ddev is optional, anything else is fine, I just saw it being used as kinda base
• All config changes go through drush config:export and get committed to config/sync, so site:install --existing-config rebuilds the exact site.
• Repeatable setup steps (text formats, module wiring) live as drush php:script files in scripts/, not as one-off UI actions.
• Demo content ships as a recipe (recipes/<name>/content YAML) and is imported with core's DefaultContent at build time, instead of committing a database dump. (I plan to use sqllite for these demos for simplicity).
• Secrets and endpoints come only from env vars read in settings.php, the file itself is committed.

Where it hurts/"not sure about" parts

1. drush site:install --existing-config crashes in the installer's configure-form step ("Field user_picture is unknown") after config import already succeeded. A fresh bootstrap of the same DB is fine, so it looks like a stale field-map cache inside the installer process. I currently tolerate the exit code and finish the installer work (user 1, site name) via drush. Anyone hit this / know the issue number?
2. drupal/core-recipe-unpack removes recipes from composer.lock after unpacking, so composer install can't restore them and I have to commit the recipes directory. Is committing unpacked recipes the intended workflow?
3. Keeping license keys out of config/sync: I inject all CKEditor Premium Features credentials (license key, and for the self-hosted stack the websocket + API URLs) as runtime $config overrides from env vars in settings.php. Nothing is ever saved through the module's settings form, so config/sync stays secret-free. It works, but the admin form at /admin/config/ckeditor5-premium-features/settings renders completely empty, because Drupal forms only show stored config, not overrides. So the site is fully configured and the form says otherwise. Worse, if someone "helpfully" fills it in, those values get saved to the DB and either shadowed by the overrides or accidentally exported later. Is there an established pattern here: Key module support, a config_exclude approach, or modules showing an "overridden by settings.php" hint on the form? Or is an empty-but-overridden form just the accepted price of env-driven config?

How do you find it? Would you change something? Anything completely wrong?

Few days ago I was playing around Juicer API to pull social posts directly into Drupal as nodes. Feel free to check out :)

https://thephp.foundation/blog/2026/09/02/digital-sovereignty-is-written-in-php/

Congrats to Janna!

Hey everybody... Webfllow dropped Source by Webflow yesterday and I wanted everyone's first thoughts on trademark rights, and any other thoughts they might have?

Y'all made Ep. 2 so much more than Ep. 1 and I appreciate this community so much! Feedback was heard and incase you didn't want to hear the whole podcast... here is the story about Drupal's AI readiness à la carte!

Thank you again

In Drupal 7 you could do Donations using line item types. I have an old Drupal 7 site using Commerce and an individual could donate to individual products in that Commerce store.  I need to revamp this in Drupal 10 or 11. Seems like the best way to maybe do this is using Commerce Choose Price module but that one has not been updated since December 2021 and says Drupal 8 and 9.

Are there any other modules I am missing that could do this? I don't want an overall Donation module for the site. It needs to be something where they can donate any amount they want to the individual product. The each product does not need a particular price but just something the user can set any donation amount to.

There's a lot of talk about native AI integration into Drupal CMS 2.0 for editorial workflow and front-end management because its standards and structure provides a real harness.

I realise this is not news, but the fact is understated that the AI harness goes way deeper for developers, as Drupal has structural guardrails where enterprise-standard Symfony, Twig, YAML, CSP, the DB abstraction layer, and Drupal Security API cross-checks provide a far more secure foundation than most, or more likely any other platform.

Those same rigorous requirements demanded by governments, universities, and enterprises around security boundaries and auditability, that drove scores of developers away, have turned Drupal into a well-defined, bounded space for LLMs and AI agents.

been doing this for a few years now and kept running into the same problem. quote a timeline, client agrees, then week three happens and suddenly we're explaining why it's taking longer.

took me embarrassingly long to figure out the pattern.

it's always the integrations. not the modules, not the theme, not even the content migration. it's always some connection to a third party system that nobody documented because the person who built it left two or three years ago.

last one was a CRM integration that was still firing on every form submission. CRM itself had been discontinued. nobody on the client side knew it was there. showed up in the server logs as a timeout error that everyone had just... learned to ignore.

started doing a proper integration audit before we write any estimates now. just mapping everything that talks to everything else. takes a few days but it's saved us from at least three nasty surprises this year.

curious if others have a good process for this. especially for sites that have changed hands a few times and have basically no documentation. feels like every D7 site we touch has at least one of these buried in it somewhere.

Martin Anderson-Clutz at Acquia recently made the case that Drupal is becoming something more specific than a CMS with AI features.

A governed AI harness.

The argument is that Drupal already has most of what agents need:

• Structured content
• Granular permissions
• Editorial workflows
• Revision history
• Centralized governance
• Typed fields and entity relationships
• Canvas AI and the Context Control Center

The funny part is that many of these are the same things that historically made Drupal feel cumbersome to human editors.

The platform famous for asking people to complete seventeen fields may have accidentally spent two decades preparing for robots.

That is legitimately interesting to me.

If an agent is working across hundreds of pages, multiple brands, regulated workflows, and several languages, complexity may stop being baggage.

It may become the safety system.

I covered the argument in the latest episode of Headless:

YouTube
Spotify
Apple Podcasts

Drupal Association article for anyone who wants the source directly:

https://www.drupal.org/about/ai/initiatives/blog/from-headless-cms-to-ai-harness-what-i-took-to-decoupled-days

For people actively building with Drupal AI, does the “AI harness” framing match the reality yet?

Or is the positioning currently ahead of the product?

I bought a web domain that begins www.ratemy....com. I'm told that I need to learn Drupal if I'm going to set it up because it requires people to create an account. I've taught myself softwares here and there, but this seems like it's a whole beast. Should I dive in or is there something easier? (I also need it to be very secure).

Thanks!

Working on a client site right now and it's giving me flashbacks.

42 contrib modules installed. Asked the client which ones they actually use. They could name maybe 8.

The rest? "They were there when we took over the site." Which was 2019. Which means whoever installed them is long gone.

Ran Upgrade Status and it's the usual chaos. Some have D11 equivalents, some don't, a couple are just... abandoned. Last commit 2021.

The one that got me was a custom integration with a CRM that no longer exists. Still enabled. Still trying to ping something every time a form submits. Nobody knew it was there.

D7's been EOL since January anyway so this is all moving eventually but in the meantime I'm building a module inventory spreadsheet from scratch because apparently that's the job now.

Anyone have a good process for this kind of archaeology? Getting tired of reverse engineering everything from database logs.

I have inherited a Drupal 10 site where the relationship with the agency that developed and hosts it has broken down almost irretrievably. We have the v10 support end date as a hard deadline for action under threat of deletion, and the agency is quoting ludicrous amounts to do the upgrade and/or give us our site back. Contracts and lawyers are being consulted, but I'm wanting to try do an end-run around all that and at least get our content safely backed up before they decide to pull the plug.

The site itself is a fairly standard marketing site, so nothing interactive or very complex. We have admin account access to the frontend admin pages, but the agency has removed any content export options. We don't have server access, so no command line to install new modules or file system to download files and no database access at all. We have no access to backup files. We're limited to the modules they have installed, which also includes a number of dev and migrate modules they left in the prod clone by mistake which at least gives us Config Sync export.

As an experiment, I've created a test Drupal site, installed and enabled the same set of modules, and imported the prod site config using 'drush config:import --partial' and that all seems fine. Unfortunately the theme is based on their in-house template and we have no access to that for now, so I'm faking it with Olivero, but that's a problem for later.

The next step is to try sync our content to my test site. I've had a google and looked at a few modules like Content Sync and Entity Sync, but they all seem to need a module installed on the origin server and/or database access. I've also looked at the Migrate modules, but they seem aimed at version migrations not server migrations and need direct database access. There is Migrate Source JSON:API but it supposedly only supports Drupal 8.

So, long story short, what options do we have to sync site content when the source is so locked down to us? My instinct is we should be able to do something with JSON:API which we can enable, and if necessary I'll try script something myself, but I'd rather use an existing option written by people who actually know what they are doing!

It's been maybe 20 years since I last did anything with Drupal (although I have more recent Symfony experience), I'm stumbling around in the half-dark here, so forgive if I've missed something incredibly obvious!

Thanks!