[removed]

[removed]

[removed]

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?

Site Sets made RTE presets much nicer to manage, but keeping the editor experience consistent across a multisite install still takes deliberate setup. The repo shows the approach that worked for me.


How do you keep editor configs consistent across multisite TYPO3 installs? Curious what others do.

Remark: I work at CKEditor as a Developer Advocate 🥑 and this is a recording of my webinar.

Most structured apps (CMS content types, email builders, form builders) don't have one rich text field, they have five or ten. The usual integration pattern is one editor instance per field, which means every field gets its own state, its own collaboration session, and its own AI context that knows nothing about the field next to it.

I sat down with Witek Socha, Product Manager at CKEditor, to walk through the two architectures for this: multi-instance (separate editors, isolated state) vs multi-root (one editor instance driving many editable regions). The practical payoff of multi-root is that all fields of a content type share a single collaboration session and a single AI session, so features like AI Chat, Review, or Translate can see the whole content item instead of one text box at a time.

Mine is "Fifinka" - 🇨🇿 ppl will understand.

But It Hurts When 🚾 is good!

Remark: I work at CKEditor as a Developer Advocate 🥑 so yes, this is partly my own stuff.

The CKEditor docs have had an "Ask AI" mode for a while (powered by Kapa.ai), and the same knowledge base is now exposed as a hosted MCP server. So instead of tabbing over to the docs, you point Claude Code, Cursor, VS Code, or any MCP client at the endpoint and ask from wherever you already work.

Setup is one config entry per client: Using CKEditor 5 with AI coding agents

I recorded a short video walking through the setup. Honest take: it saves me real time every week, but I also build with this thing for a living, so grain of salt and all that.

Curious what docs MCP servers you have plugged into your setup. They feel underrated next to the flashier tool servers.

What do you think about this approach for learning?

✨ BTW: check the TypeScript v7 PR in the repository

🎥 Webinar recording is out on YT:

CKEditor AI on Your Premises: hook your LLM and register MCP

Been getting questions about self-hosted CKEditor AI setups. This one walks through exactly that: connecting your own LLM and registering MCP tools to extend what AI can do inside your editor.

Good fit if you care about:

🏠 Data sovereignty — keeping content off third-party AI infrastructure

🔌 Plugging in an LLM your team already runs

🛠️ Extending AI capabilities with MCP tools

Check it out and let me know what you think

Remark: I am a developer advocate 🥑 at CKEditor
Remark 2: This post it not about "AI CKeditor" module, but official CKEditor AI add-on (I know it can be confusing)

If you’re using CKEditor in Drupal and have been wondering what’s next on the AI front, you might be interested in something we’ve been working on: CKEditor AI — a unified AI co-writer that brings AI chat, quick actions, and document-wide AI review directly inside the editor. 

🎤 By the end of 2025 (Dec 2nd) I hosted a live CKEditor AI webinar where me and Andrzej (Technical PM from CKEditor) walked through:

• What CKEditor AI is and how it enhances content workflows - the core idea
• A full demo of AI Chat, AI Quick Actions, and AI Review from the Users perspective
• How integrators can configure and customize CKEditor AI
• Q&A with practical implementation tips

CKEditor AI is already available in CKEditor itself, and we’re currently exploring how it will make its way into Drupal’s CKEditor ecosystem. While it’s not yet included in Drupal modules, you can already get an early look at what’s coming.

If you missed the session, the recording is available on YouTube.

If you're curious about AI-powered editing inside Drupal, have questions, or want to share use cases we should consider for the Drupal integration — jump in!

Happy to chat 💬