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/