[![Profile picture for user Joachim](/sites/default/files/styles/thumbnail/public/avatars/1776092216762.png.avif?itok=EuiDMMaI)](/user/2) Gespeichert von [Joachim](/user/2 "Benutzerprofil anzeigen.") am So. 6 Sep 2026 - 14:52 09.06.2026 # Der Formate-Button, der einfach nicht wollte: Ein unsichtbarer CKEditor-5-Bug und wie du ihn jagst Geschrieben von [Joachim](/user/2) [ ckeditor ](/taxonomy/term/63) [ debugging ](/taxonomy/term/64) 💡 Key Facts - Das Problem: Ein CKEditor-5-"Formate"-Dropdown mit drei Callout-Styles (Update/Powertipp/Info) blieb dauerhaft grau und deaktiviert – egal, wo der Cursor stand. - Die Falle: Jede Config-PrĂŒfung sah perfekt aus. JSON-Settings korrekt, Dropdown-EintrĂ€ge mit den richtigen Labels und Farben generiert. Trotzdem: nichts ging. - Der eigentliche Bug: Die Styles zielten auf <blockquote> – aber CKEditor 5 kann Blockquote keine freie Klasse verpassen, weil das Element schon von einem eigenen Feature verwaltet wird. - Der Fix: Ziel auf <p> umgestellt. Button war sofort klickbar, Dropdown zeigte die drei Farbkacheln mit Emoji-Label – fertig. - Die Lehre: "Sieht in der Config richtig aus" ist keine BestĂ€tigung. Öffne den echten Editor im Browser, bevor du eine Style-Konfiguration fĂŒr fertig erklĂ€rst. Kennst du das GefĂŒhl? Du baust ein Feature, jede Zeile Config stimmt, du liest deinen eigenen JSON-Output dreimal gegen – und trotzdem tut die UI einfach nicht das, was sie soll. Kein Fehler in der Konsole. Keine rote Meldung. Nur ein Button, der stur grau bleibt. Genau das ist mir heute beim Bau der Callout-Boxen fĂŒr diese Seite passiert. Und weil der Bug am Ende so unauffĂ€llig war, dass ich ihn fast ĂŒbersehen hĂ€tte, will ich dir zeigen, wie ich ihn gefunden habe – damit du nicht dieselbe Stunde verlierst, wenn du mal selbst CKEditor-5-Styles konfigurierst. ## Die Mission: Drei Callout-Boxen fĂŒr den Editor Die Idee war simpel: Redakteur:innen sollen einen Absatz markieren, im Editor auf "Formate" klicken und daraus eine farbige Hinweisbox machen – 🔔 Update, 💡 Powertipp oder â„č Info. Ähnlich wie ein Toast in Bootstrap 5, nur direkt im CKEditor nutzbar. Drupal bringt dafĂŒr das passende Werkzeug schon mit: das CKEditor-5-"Style"-Plugin. Du definierst ein paar Styles in der Editor-Konfiguration, jeder bekommt ein Ziel-Element plus eine oder mehrere CSS-Klassen, und Drupal baut dir daraus automatisch das "Formate"-Dropdown. Kein eigenes JavaScript nötig. Also los: Drei Styles definiert, jeweils gemappt auf ein **blockquote** mit eigener Klasse: ```yml ckeditor5_style:  styles:    - label: Update      element: '
'    - label: Powertipp      element: '
'    - label: Info      element: '
' ``` Dazu noch **filter\_html** erweitert, damit die drei Klassen auf blockquote ĂŒberhaupt erlaubt sind, und ein bisschen CSS fĂŒr Farbe und Emoji-Label. Sah in jeder Config-Ansicht wasserdicht aus. ## Der Endgegner: Ein Button, der nichts tut Cache geleert, Editor neu geladen – und dann: nichts. Der "Formate"-Button in der Toolbar stand einfach nur grau da. Kein Klick, kein Dropdown, keine Reaktion. Egal, ob der Cursor im Text stand oder nicht. Das TĂŒckische daran: Es gab absolut keinen Hinweis darauf, *warum*. Kein Fehler in der Browser-Konsole. Die generierten JavaScript-Settings fĂŒr den Editor zeigten exakt das, was ich erwartet hatte – die drei Styles, korrekt benannt, mit den richtigen Farben. Wenn du nur auf die Konfiguration schaust, wĂŒrdest du schwören: Das muss funktionieren. Hier ist der Punkt, an dem viele aufgeben und anfangen, wahllos an der Config herumzuschrauben. Stattdessen bin ich einen Schritt zurĂŒckgegangen und habe mir den Button selbst angeschaut – nicht die Config, sondern das tatsĂ€chliche DOM-Element im Browser: document.querySelectorAll('button') .find(b => b.textContent.trim() === 'Stile') .getAttribute('aria-disabled'); // → "true" Da war er, der eigentliche Zustand: **aria-disabled="true"**. Fest verdrahtet, unabhĂ€ngig von Cursorposition oder Auswahl. Der Button war nicht kaputt – er war *absichtlich* deaktiviert. Nur eben von CKEditor 5 selbst, aus einem Grund, den keine Config-Datei verraten hĂ€tte. ## Die Auflösung: Blockquote ist schon vergeben CKEditor 5 aktiviert den "Formate"-Button nur, wenn mindestens einer der konfigurierten Styles auf das aktuelle Element angewendet werden *kann*. Und genau hier lag der Haken: blockquote wird bereits von einem eigenen, fest eingebauten Feature verwaltet – dem BlockQuote-Feature, das fĂŒr den normalen "Zitat"-Button in der Toolbar zustĂ€ndig ist. Dieses Feature kennt zwar blockquote, aber es ist nicht darauf ausgelegt, dass ihm ein anderes Plugin einfach beliebige CSS-Klassen unterschiebt. Das Style-Plugin und das BlockQuote-Feature reden schlicht nicht dieselbe Sprache – und weil keins von beiden das als Fehler behandelt, bleibt der Button einfach fĂŒr immer deaktiviert. Kein Absturz, keine Warnung. Er tut einfach: nichts. Der Fix war am Ende eine einzige Änderung: statt blockquote als Ziel-Element <p> verwenden: ckeditor5\_style: styles: \- label: Update element: '<p class="callout callout--update">' \- label: Powertipp element: '<p class="callout callout--tip">' \- label: Info element: '<p class="callout callout--info">' Warum <p>? Weil das Textformat hier schon lange bewiesen hat, dass Klassen-basiertes Styling auf <p> zuverlĂ€ssig funktioniert – die Textausrichtung (linksbĂŒndig, zentriert, 
) lĂ€uft ĂŒber exakt denselben Mechanismus. Nach der Umstellung: Button sofort klickbar, Dropdown zeigt alle drei Styles mit Farbvorschau und Emoji-Label, Klick verwandelt den Absatz tatsĂ€chlich in die farbige Box. ## Warum eigentlich kein <div>? Die vollstĂ€ndige Liste Naheliegende Frage, die ich mir selbst gestellt habe: Wenn blockquote schon Ärger macht, warum dann nicht einfach ein neutrales <div class="callout"> nehmen, ganz ohne konkurrierendes Feature? Um das sauber zu beantworten, bin ich eine Ebene tiefer gegangen, als die Config normalerweise verlangt: direkt in den JavaScript-Quellcode, den Drupal-Core fĂŒr das Style-Plugin mitliefert (core/assets/vendor/ckeditor5/style/style.js – minifiziert, aber lesbar). Dort steckt die eigentliche Logik, und sie beantwortet die Frage eindeutig. CKEditor 5 unterscheidet fĂŒr jedes Style-Ziel-Element drei Situationen: 1. **Kein eigenes Feature, direkt von General HTML Support (GHS) verstanden.** <p> und die Überschriften h1–h6 fallen darunter – GHS behandelt sie als sein eingebautes "paragraphartiges" Standardelement. Kein Konflikt möglich, weil niemand sonst Anspruch auf den Tag erhebt. 2. **Eigenes Feature, aber mit eingebauter BrĂŒcke zum Style-Plugin.** Listen, Tabellen und Links werden zwar von eigenen, spezialisierten Features verwaltet (List, Table, Link) – aber CKEditor 5 liefert dafĂŒr extra KompatibilitĂ€ts-Plugins mit: ListStyleSupport, TableStyleSupport, LinkStyleSupport. Die verbinden das jeweilige Feature explizit mit dem Style-Plugin. Ich habe das fĂŒr <li> selbst nachgestellt (Style nur auf <li class="test-li"> konfiguriert, Absatz per Toolbar in eine Liste verwandelt): Button sofort aktiv, keine Spur des Problems von vorhin. 3. **Eigenes Feature, aber keine BrĂŒcke.** Genau das ist der Fall bei blockquote. Das BlockQuote-Feature verwaltet den Tag exklusiv, aber es existiert kein BlockQuoteStyleSupport – anders als bei Listen, Tabellen und Links hat hier schlicht niemand die BrĂŒcke gebaut. Ergebnis: fĂŒr immer deaktiviert, ohne jede Fehlermeldung. Und <div>? Der landet in einer vierten, eigentlich noch einfacheren Kategorie: Es ist gar kein Tag, das dieses Textformat ĂŒberhaupt erlaubt. General HTML Support kennt fĂŒr diesen Editor nur die Elemente, die filter\_html freigibt – <div> steht da nicht drin. Der Style-Eintrag findet dadurch weder ein Block- noch ein Inline-Ziel und bleibt komplett wirkungslos, noch bevor die Frage "eigenes Feature ja/nein" ĂŒberhaupt eine Rolle spielt. Die gute Nachricht: Genau deshalb ist <div> kein Sackgassen-Fall. Wenn du unbedingt einen neutralen Container brauchst, kannst du ihn ĂŒber die "Source Editing"-Konfiguration (Drupals OberflĂ€che fĂŒr General HTML Support) explizit erlauben. Dann kennt GHS den Tag, niemand sonst beansprucht ihn – und er verhĂ€lt sich wie <p>: Kategorie 1, keine BrĂŒcke nötig. Hier die Liste als Tabelle, mit allem, was ich direkt bestĂ€tigen konnte (live getestet oder im Core-Quellcode mit Namen gefunden) und allem, was sich logisch aus derselben Mechanik ergibt: | Element | Funktioniert mit Style? | Warum | |---|---|---| | <p> | Ja (live bestĂ€tigt) | Kein eigenes Feature, GHS-Standardelement | | <h1>–<h6> | Ja | Gleiche GHS-Mechanik wie <p> | | <li> | Ja (live bestĂ€tigt) | Eigenes List-Feature, aber ListStyleSupport-BrĂŒcke | | <ul>, <ol> | Ja | Gleiche ListStyleSupport-BrĂŒcke | | <td>, <th> | Ja | Eigenes Table-Feature, aber TableStyleSupport-BrĂŒcke | | <thead>, <tbody> | Ja | Gleiche TableStyleSupport-BrĂŒcke | | <a> | Ja (als Inline-Style) | Eigenes Link-Feature, aber LinkStyleSupport-BrĂŒcke | | <blockquote> | Nein (live bestĂ€tigt) | Eigenes BlockQuote-Feature, keine BrĂŒcke vorhanden | | <hr>, <br>, <img>, drupal-media | Nein | Von Drupal-Core offiziell als "bekannt inkompatibel" dokumentiert, inkl. Verweis auf offene Upstream-Issues | | <div>, <span>, <article>, <section>, <figure> | Nein – aber nachrĂŒstbar | Vom Textformat gar nicht erlaubt; GHS kennt den Tag nicht. Über "Source Editing" freischalten, dann wie <p> nutzbar | Zeilen ohne "live bestĂ€tigt" habe ich nicht selbst durchgeklickt, sondern aus derselben, im Quellcode klar benannten Mechanik abgeleitet (Plugin-Namen wie ListStyleSupport oder TableStyleSupport sind kein Rateergebnis, die stehen wortwörtlich so im Code). Bei <hr>, <br>, <img> und drupal-media ist es noch eindeutiger: Die stehen in einer festen Liste namens KNOWN\_UNSUPPORTED\_TAGS direkt im Drupal-Core-Code, mit Kommentaren, die auf die jeweiligen offenen Tickets verweisen. ## Die grĂ¶ĂŸere Lehre Eine Konfiguration, die auf dem Papier – oder im JSON-Export – korrekt aussieht, ist noch keine funktionierende Konfiguration. Öffne den echten Editor, bevor du einen Haken dran machst. Manche Bugs verstecken sich nicht im Code, sondern genau in der LĂŒcke zwischen "sieht richtig aus" und "tut auch, was es soll". Und wenn du wirklich wissen willst, warum etwas nicht geht: Config-Ebene ist oft nur die halbe Wahrheit – die andere HĂ€lfte steckt manchmal im JavaScript, das der Browser tatsĂ€chlich ausfĂŒhrt. 🔗 WeiterfĂŒhrende Links - [CKEditor 5 Style-Feature (offizielle Doku)](https://ckeditor.com/docs/ckeditor5/latest/features/style.html) - [CKEditor 5 General HTML Support (offizielle Doku)](https://ckeditor.com/docs/ckeditor5/latest/features/html/general-html-support.html) - [Drupal.org: CKEditor 5-Modul](https://www.drupal.org/project/ckeditor5) - [MDN: aria-disabled](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled) [Zur Blog-Übersicht](/blog) [ ← ZurĂŒck JahresrĂŒckblick 2025 – Wie die KI Deutsch lernte & was 2026 kommt ](/blog/jahresrueckblick-2025-wie-die-ki-deutsch-lernte-was-2026-kommt)