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.

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.

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.

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?

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?

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/

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