Réécriture des plugins CKEditor 4 pour CKEditor 5
Chez DrupalBook, nous accompagnons des plateformes Drupal pour lesquelles l’expérience éditoriale est un enjeu critique pour l’entreprise, et non une simple considération technique secondaire. Lorsque Drupal est passé de CKEditor 4 à CKEditor 5, une base d’édition moderne a été introduite, mais cette transition a également créé un écart important pour les organisations qui dépendaient de plugins CKEditor 4 bien établis. Cet article explique comment nous avons comblé cet écart en migrant des fonctionnalités essentielles, garantissant la continuité pour les équipes éditoriales tout en permettant à nos clients d’évoluer vers des versions modernes de Drupal.
Plugins manquants dans CKEditor 5
La transition de CKEditor 4 vers CKEditor 5 ne constituait pas une mise à niveau classique, mais un remplacement complet de l’architecture de l’éditeur. Du point de vue de la gestion, cela signifiait que de nombreux plugins familiers sont soudainement devenus indisponibles, y compris des outils que les éditeurs utilisaient quotidiennement depuis des années. Dans plusieurs projets clients, ces plugins manquants étaient profondément intégrés aux workflows éditoriaux, aux supports de formation et aux standards de qualité. Leur suppression aurait ralenti la production, augmenté les taux d’erreur et réduit la confiance éditoriale dans la plateforme.
Pour les décideurs, le défi était stratégique plutôt que technique. Rester sur CKEditor 4 bloquait les mises à jour de Drupal et augmentait les risques à long terme en matière de sécurité et de maintenance, tandis qu’une mise à niveau sans plugins clés aurait immédiatement perturbé les opérations métier. Attendre que l’écosystème rattrape son retard n’était pas réaliste compte tenu des délais projets et des exigences de conformité. Il ne restait donc qu’une seule option viable : la migration personnalisée des plugins critiques de CKEditor 4 vers CKEditor 5, avec un accent mis sur la préservation de l’expérience utilisateur plutôt que sur la reproduction du comportement technique hérité.
Migration du plugin CKEditor 4 « Keep Text Selection »
L’un des premiers problèmes signalés par les éditeurs après le passage à CKEditor 5 a été une perte perçue de contrôle lors des tâches d’édition quotidiennes. Des actions telles que l’ajout de liens ou l’insertion de médias ne s’appliquaient plus de manière fiable au texte ciblé, rompant des habitudes d’édition bien établies. Bien que ce changement de comportement soit le résultat d’améliorations internes apportées par CKEditor 5, son impact sur la productivité a été immédiat et notable, en particulier pour les éditeurs professionnels travaillant à grande échelle.


D’un point de vue métier, il ne s’agissait pas d’un simple problème d’ergonomie, mais bien d’une régression des workflows. Les éditeurs devaient répéter des actions, corriger manuellement des erreurs et ralentir leur travail pour vérifier les résultats. Notre objectif, en migrant la fonctionnalité Keep Text Selection, était de rétablir la confiance et la prévisibilité sans obliger les éditeurs à modifier leurs habitudes. En veillant à ce que l’intention de l’utilisateur soit toujours respectée, nous avons supprimé les frictions du processus quotidien de création de contenu et maintenu les niveaux d’efficacité attendus avant la migration.
Migration d’IMCE avec images, Lightbox, infobulles et vidéo
La migration la plus impactante concernait IMCE, qui faisait office, dans les projets de nos clients, d’une solution complète de gestion des médias intégrée directement à l’éditeur. Les éditeurs s’en servaient non seulement pour téléverser des images, mais aussi pour gérer des ressources réutilisables, insérer des vidéos, activer les comportements Lightbox et enrichir les contenus à l’aide d’infobulles. Ces fonctionnalités étaient centrales pour la qualité éditoriale et l’engagement des utilisateurs, en particulier sur des plateformes de publication complexes.
La structure de contenu plus stricte de CKEditor 5 a nécessité une refonte complète de cette fonctionnalité, mais l’exigence métier était claire : aucune perte de capacité et aucune perturbation des workflows éditoriaux. Nous avons reconstruit l’intégration IMCE afin de prendre pleinement en charge l’insertion de médias riches tout en l’alignant sur les standards modernes de Drupal et de CKEditor 5. Les éditeurs ont conservé la possibilité de créer des contenus visuellement riches et interactifs, tandis que les organisations bénéficient désormais d’une base plus propre et plus robuste, favorable à la montée en charge, à la gouvernance et aux évolutions futures.


Migrer de CKEditor 4 vers CKEditor 5 est avant tout un enjeu de continuité métier, et non seulement un défi technique. Les plugins manquants peuvent, s’ils ne sont pas traités de manière proactive, éroder silencieusement la productivité, la qualité et la confiance des équipes. Notre expérience montre que la réécriture des plugins critiques est souvent le moyen le plus efficace de protéger les workflows existants tout en répondant aux exigences des plateformes modernes.
Chez DrupalBook, nous abordons ces migrations comme des investissements stratégiques dans l’efficacité éditoriale et la pérennité des plateformes, afin de garantir que les équipes puissent continuer à travailler sereinement pendant que leur infrastructure numérique évolue.
Ivan Abramenko, Architecte principal Drupal
ivan.abramenko@drupalbook.org
projects@drupalbook.orgprojects@drupalbook.org