Wenn du lange genug Inhalte in Drupal bearbeitest, bist du wahrscheinlich schon auf diesen kleinen, aber nervigen Workflow-Bruch gestoßen: Du markierst ein Wort oder setzt den Cursor, wechselst zu Source, um das Markup anzupassen, und … du verlierst deine Position. Ich habe ein kleines Modul gebaut, das genau dieses Problem behebt.

Ein CTO fragte mich einmal mitten in einem Planungsmeeting für ein entkoppeltes Drupal-Projekt: „Welche API sollten wir also verwenden?“

Für einen Moment wurde es still im Raum. Das Frontend wollte GraphQL. Das Backend wollte JSON:API. Ein Integrationsanbieter war bereits von REST ausgegangen. Der Product Owner wollte einfach nur, dass die mobile App nicht mehr auf Website-Releases warten muss.

Diese kleine Frage klingt meistens technisch. Das ist sie nicht. Sie ist eine Governance-Frage, eine Budgetfrage und manchmal eine Einstellungsfrage im Entwickler-Hoodie.

Einmal öffnete ich ein Drupal-Menü mit mehreren tausend Links und sah zu, wie der Browser vor mir aufgab. Die Seite wurde technisch gesehen geladen. Danach fühlte sich jeder Klick an, als würde man einen alten Drucker bitten, seine Gefühle zu erklären.

Ein mehrsprachiger Backlog hat einen ganz eigenen Geruch. Du veröffentlichst am Montag auf Englisch, versprichst Deutsch „diese Woche“, und am Freitag starrst du auf 47 aktualisierte Seiten — ohne eine saubere Antwort auf die Frage: „Also… wie ist der echte Status?“

Ich habe Teams gesehen, die das mit noch mehr Prozess lösen wollten: Tabellen, Übersetzungstickets, wöchentliche Syncs. Das funktioniert, bis jemand den Hero-Absatz auf 200 Seiten ändert. Dann wird wieder geraten.

1 Einführung

Lightbox-Plugins sind seit über einem Jahrzehnt ein fester Bestandteil von Drupal-basierten Websites. Sie ermöglichen es Redakteurinnen und Redakteuren, Bilder, Videos und andere Medien in einer Overlay-Darstellung anzuzeigen, ohne die aktuelle Seite zu verlassen – ein Muster, das Besucherinnen und Besucher auf modernen, medienreichen Websites erwarten.

Bei DrupalBook unterstützen wir Drupal‑Plattformen, bei denen die redaktionelle Arbeitsweise geschäftskritisch ist und nicht lediglich eine technische Randnotiz darstellt. Als Drupal von CKEditor 4 auf CKEditor 5 umgestellt wurde, entstand zwar eine moderne Grundlage für das Editieren, gleichzeitig jedoch auch eine erhebliche Lücke für Organisationen, die auf bewährte CKEditor‑4‑Plugins angewiesen waren.

1. Warum CI‑gesteuertes Konfigurationsmanagement wichtig ist

Drupals Konfigurationssystem ist eine der größten Stärken der Plattform — und eine ihrer zuverlässigsten Schmerzquellen. Die Möglichkeit, jede einzelne Site‑Konfiguration als YAML‑Dateien zu exportieren und zu importieren, ist mächtig, aber nur dann, wenn alle sich einig sind, wer dafür verantwortlich ist, diese Dateien zwischen den Umgebungen zu bewegen. In den meisten Teams existiert diese Einigung nie so richtig.

Obwohl der Support für Drupal 7 bereits ausgelaufen ist und es keine neuen Updates mehr geben wird, werden alle neuen Module ausschließlich für Drupal 11+ veröffentlicht. Dennoch nutzen weiterhin viele Websites Drupal 7 und können nicht auf neuere Versionen migrieren. Dafür gibt es Gründe, insbesondere bei Websites mit einer großen Menge an individuellem Custom-Code.

Warum diese Änderung?

• In Drupal 9 wurde jQuery Cookie aus dem Core entfernt und durch die js-cookie-Bibliothek ersetzt. Ein BC‑Shim (core/jquery.cookie) existierte während Drupal 9, wurde jedoch für Drupal 10 entfernt.