A CTO once asked me, halfway through a decoupled Drupal planning meeting, “So which API should we use?”

The room went quiet for a second. Frontend wanted GraphQL. Backend wanted JSON:API. One integration vendor had already assumed REST. The product owner just wanted the mobile app to stop waiting on website releases.

That small question usually sounds technical. It isn’t. It is a governance question, a budget question, and sometimes a hiring question wearing a developer hoodie.

I once opened a Drupal menu with several thousand links and watched the browser give up before I did. The page loaded, technically. Then every click felt like asking an old printer to explain its feelings.

A multilingual backlog has a special smell. You publish in English on Monday, you promise German “this week,” and by Friday you’re staring at 47 updated pages and no clean way to answer, “So… what’s the real status?”

I’ve watched teams try to solve this by throwing more process at it: spreadsheets, translation tickets, weekly syncs. It works until someone edits the hero paragraph on 200 pages. Then you’re back to guessing.

At DrupalBook, we support Drupal platforms where editorial experience is a business‑critical concern, not a technical afterthought. When Drupal transitioned from CKEditor 4 to CKEditor 5, it introduced a modern editing foundation, but also created a significant gap for organizations that relied on established CKEditor 4 plugins. This article explains how we addressed that gap by migrating essential functionality, ensuring continuity for editorial teams while enabling our clients to move forward with modern Drupal versions.

1 Introduction

Lightbox plugins have been a staple of Drupal-powered websites for over a decade. They allow editors to display images, videos, and other media in an overlay without navigating away from the current page — a pattern visitors expect on modern, media-rich sites.

1. Why CI-Driven Configuration Management Matters

Drupal's configuration system is one of the platform's greatest strengths — and one of its most reliable sources of pain. The ability to export and import every piece of site configuration as YAML files is powerful, but only if everyone agrees on who is responsible for moving those files between environments. In most teams, that agreement never quite exists.

The classic problems are well-known to anyone who has shipped a Drupal site:

Although support for Drupal 7 has already ended and no new updates will be released, all new modules are now being published for Drupal 11+, there are still many websites running on Drupal 7 that are unable to migrate to newer versions. There are valid reasons for this, especially for sites with a large amount of custom code.

Why this change?

• In Drupal 9, jQuery Cookie was removed from core and replaced with the js-cookie library. A BC shim (core/jquery.cookie) existed during Drupal 9 but was removed for Drupal 10.

This section is about updating the Drupal core from previous versions (including legacy Drupal 6 and Drupal 7) to the latest stable release. I will also publish articles here on how to update contributed modules for Drupal.