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?

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?

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

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.