Désactiver Gutenberg proprement sur un site existant

L'éditeur de blocs est devenu l'éditeur par défaut de WordPress il y a plusieurs années, et il continue de susciter des demandes de retour à l'éditeur précédent. Les motifs sont variés : habitudes d'une équipe de rédaction, incompatibilité avec un thème ancien, extension métier reposant sur l'ancien fonctionnement, ou simplement rejet d'une interface jugée moins productive. La désactivation est possible et elle n'est pas une opération anodine sur un site où des contenus ont déjà été créés en blocs. Cet article détaille ce qui se désactive réellement, ce qu'il advient de l'existant, les points de vigilance et la façon de conserver une porte de sortie.

Ce que recouvre la désactivation

Le premier malentendu porte sur le périmètre. Parler de désactiver l'éditeur de blocs recouvre en réalité plusieurs mécanismes distincts, qui se désactivent séparément et dont l'un peut être conservé tandis qu'un autre est retiré. Faire ce tri avant d'agir évite de retirer plus que nécessaire, ce qui est la situation la plus fréquente. Une équipe qui souhaitait simplement retrouver l'éditeur de texte des articles se retrouve parfois privée de fonctions qu'elle appréciait. Le fonctionnement général de cet éditeur est présenté dans notre article sur Gutenberg, l'éditeur de blocs natif de WordPress.

L'éditeur de contenu

C'est le cœur de la demande : remplacer l'interface en blocs par la zone de texte classique lors de la rédaction d'un article ou d'une page. Cette bascule se fait par un filtre indiquant qu'un type de contenu n'emploie pas le nouvel éditeur, ce qui rétablit l'ancien. Elle peut être appliquée à tous les types de contenu ou à certains seulement, distinction utile lorsque les articles et les pages n'ont pas les mêmes besoins. C'est la partie la plus simple de l'opération et celle qui produit l'effet visible attendu. Elle est aussi parfaitement réversible, le retrait du filtre rétablissant immédiatement l'éditeur de blocs.

L'éditeur de site

Les thèmes dits par blocs remplacent l'ensemble des gabarits par une édition visuelle, ce qui constitue un mécanisme distinct. Il ne se désactive pas par le même filtre et il dépend entièrement du thème employé. Un site utilisant un thème classique n'est pas concerné par cette dimension. Un site utilisant un thème par blocs ne peut pas revenir à l'éditeur classique de contenu sans changer de thème, ce qui transforme l'opération en chantier de refonte. Cette contrainte doit être annoncée dès la première discussion, sous peine de laisser croire qu'une intervention légère suffira.

Les feuilles de style des blocs

Le cœur charge des styles destinés à l'affichage des blocs sur le site public, indépendamment de l'éditeur employé. Sur un site qui n'emploie aucun bloc, ces styles représentent un poids inutile et se retirent par un filtre. Sur un site où des contenus en blocs existent déjà, les retirer casse leur affichage, ce qui produit des mises en page désorganisées. Cette distinction est essentielle et elle est régulièrement ignorée par les recettes trouvées en ligne. Le gain de poids obtenu, quelques dizaines de kilooctets, ne justifie de toute façon pas le risque sur un site comportant des contenus en blocs.

Les blocs dans les widgets

La gestion des zones de widgets est passée à une interface en blocs, changement distinct des précédents et souvent le plus mal vécu par les gestionnaires de sites. Un filtre dédié rétablit l'interface classique de ces zones. Il peut être appliqué seul, sans toucher à l'éditeur de contenu, ce qui répond à une demande fréquente. C'est probablement la désactivation la plus consensuelle des quatre. Elle ne touche aucun contenu éditorial et elle rétablit une interface que la plupart des gestionnaires de sites connaissent depuis des années.

Les blocs réutilisables et les motifs

Les éléments enregistrés pour être réemployés dans plusieurs contenus deviennent inaccessibles après désactivation de l'éditeur. Ils restent en base et ne peuvent plus être ni modifiés ni insérés. Sur un site qui en fait un usage intensif, cette perte est le principal obstacle à la désactivation. Il faut donc inventorier leur usage avant de décider, ce qui prend quelques minutes avec une requête simple. Lorsque cet usage est important, la conversion préalable de chaque élément réutilisable en contenu ordinaire constitue la seule sortie propre.

Ce qui n'est pas concerné

Les contenus déjà enregistrés ne sont pas modifiés par la désactivation, quelle qu'elle soit. Ils restent en base sous leur forme actuelle et continuent d'être affichés, sous réserve que les styles nécessaires soient toujours chargés. La désactivation agit sur l'interface d'édition et sur ce qui est chargé, jamais sur les données. Comprendre ce point rassure et il évite les sauvegardes paniquées, tout en rappelant que la reprise éditoriale, elle, sera nécessaire. C'est cette reprise, et non la désactivation technique, qui représente l'essentiel de la charge sur un site fourni.

Le sort des contenus existants

C'est la question qui décide de la faisabilité de l'opération sur un site en activité. La réponse dépend entièrement de la façon dont les contenus ont été construits.

Le balisage des blocs

Un contenu créé en blocs est enregistré comme du HTML classique, entouré de commentaires qui décrivent chaque bloc et ses réglages. Ces commentaires sont invisibles à l'affichage et ils sont ce qui permet à l'éditeur de reconstituer l'interface. Une fois l'éditeur désactivé, ces commentaires apparaissent tels quels dans la zone de texte classique, ce qui produit un contenu difficile à modifier. Le contenu reste correct à l'affichage et il devient pénible à éditer, ce qui est exactement le problème que l'on cherchait à éviter. Un rédacteur découvrant ces commentaires pour la première fois croit généralement à une corruption du contenu, ce qui mérite d'être expliqué en amont.

Les blocs simples

Un contenu composé uniquement de paragraphes, titres, listes et images produit un HTML parfaitement lisible une fois les commentaires retirés. Ces contenus se reprennent facilement, un simple nettoyage des commentaires suffisant à retrouver un texte propre. C'est le cas le plus favorable et il concerne la majorité des articles rédactionnels. Un traitement automatisé sur l'ensemble de la base est envisageable, avec les précautions d'usage sur les sauvegardes. Le résultat obtenu est en général plus propre que ce que produisaient les anciens éditeurs, ce qui constitue un bénéfice inattendu de l'opération.

Les blocs de mise en page

Les colonnes, groupes, espacements et blocs de couverture produisent un balisage nettement plus dense, avec des classes qui dépendent des styles du cœur. Retirer ces styles casse la mise en page, les conserver oblige à garder une partie du mécanisme que l'on voulait retirer. Ces contenus demandent une reprise manuelle, ce qui les rend coûteux au delà de quelques dizaines de pages. Leur inventaire conditionne la décision. Un site comptant vingt pages construites en colonnes se reprend en une journée, un site en comptant deux cents ne se reprend pas.

Les blocs d'extensions

Un bloc fourni par une extension produit souvent un balisage minimal, le rendu étant calculé à l'affichage. Ces blocs cessent purement et simplement de fonctionner si l'extension est retirée, et ils deviennent inéditables si l'éditeur est désactivé. Ils constituent le cas le plus problématique. Les recenser avant toute décision est indispensable, une recherche sur les noms de blocs dans la base donnant la liste en une requête. Cette liste doit être confrontée à celle des extensions actives, certains blocs provenant d'extensions désinstallées depuis longtemps.

Le nettoyage des commentaires

Un traitement retirant les commentaires de blocs des contenus concernés produit un HTML propre, éditable dans l'éditeur classique. Cette opération est irréversible et elle doit être précédée d'une copie complète de la table des contenus. Elle ne doit porter que sur les contenus composés de blocs simples, les autres perdant leur mise en page. Le tri se fait par une recherche sur les noms de blocs présents dans chaque contenu. Un contenu ne comportant que des blocs de paragraphe, de titre, de liste et d'image peut être traité sans risque.

La conversion en bloc classique

L'éditeur propose de convertir un contenu entier en un bloc unique de type classique, qui contient le HTML sans structure de blocs. Cette conversion, faite avant désactivation, produit exactement le résultat souhaité pour l'édition ultérieure. Elle se mène contenu par contenu depuis l'interface, ce qui la limite aux petits volumes. Le contenu conserve alors intégralement son apparence, seule sa structure interne changeant. Sur un site important, un script reproduisant cette transformation est préférable, ce qui rejoint les précautions décrites dans notre article sur TinyMCE et le passage de WordPress à Gutenberg.

Mettre en place la désactivation

La mise en œuvre offre deux voies, l'extension et le code, dont le choix dépend surtout de qui maintiendra le site.

L'extension officielle

Une extension maintenue par la communauté rétablit l'éditeur classique, avec un réglage permettant de choisir entre remplacement complet et coexistence des deux éditeurs. Elle constitue le choix raisonnable pour un site géré par un client autonome. Son maintien dans le temps est annoncé pour plusieurs années, ce qui donne de la visibilité. Elle ajoute une dépendance, ce qui est son seul inconvénient réel. Sur un site comptant déjà vingt extensions, une de plus ne change pas grand chose au niveau de risque global.

Le code dans un thème enfant

Quelques lignes dans le fichier de fonctions du thème enfant suffisent à obtenir le même résultat, sans dépendance supplémentaire. Cette approche convient aux sites maintenus par une équipe technique et elle offre un contrôle plus fin, notamment pour ne désactiver l'éditeur que sur certains types de contenu. Elle demande de savoir où intervenir et de documenter le choix. C'est la voie à privilégier sur un développement sur mesure. Le code doit impérativement se trouver dans un thème enfant ou dans une extension maison, jamais dans le thème parent, sous peine d'être effacé à la première mise à jour.

La désactivation sélective

Conserver l'éditeur de blocs sur les pages et l'ancien éditeur sur les articles, ou l'inverse, répond souvent mieux au besoin réel qu'une désactivation générale. Les pages de présentation bénéficient des blocs de mise en page, les articles rédactionnels se passent très bien de l'éditeur classique. Cette granularité s'obtient par un simple test sur le type de contenu dans le filtre. Elle mérite d'être proposée avant toute désactivation complète. Elle résout la majorité des demandes réelles, qui portent presque toujours sur la rédaction d'articles plutôt que sur la construction de pages.

Conserver les styles nécessaires

Si des contenus en blocs subsistent, la feuille de style correspondante doit rester chargée sur le site public. La retirer par souci d'allègement casse l'affichage de ces contenus, parfois de façon peu visible sur les pages les moins consultées. Le contrôle consiste à parcourir quelques pages construites en blocs après désactivation. Une extraction des seuls styles réellement employés est possible, avec un peu de travail. Elle ne se justifie que sur un site où la performance est un enjeu mesuré, le gain restant modeste.

Vérifier les extensions dépendantes

Certaines extensions n'exposent leurs fonctions que sous forme de blocs et deviennent inutilisables après désactivation. Formulaires, galeries, tableaux de tarifs, blocs de réservation sont les cas les plus fréquents. Leur inventaire doit être fait avant l'intervention, en listant les extensions actives et en vérifiant lesquelles proposent une alternative en code court. Certaines proposent les deux, ce qui règle la question. Pour les autres, il faut soit renoncer à la désactivation, soit remplacer l'extension, soit accepter de perdre la fonction concernée.

Former les rédacteurs

Le retour à l'éditeur classique change les habitudes autant que le passage aux blocs les avait changées. Une note d'une page rappelant comment insérer une image, un lien ou un tableau évite une semaine de questions. Un temps d'échange de trente minutes avec les personnes concernées vaut mieux que dix pages de documentation que personne ne lira. Ce point est systématiquement négligé alors qu'il conditionne l'acceptation du changement, comme nous le rappelons dans notre article sur la manière de créer un premier article avec WordPress.

Garder une porte de sortie

Une désactivation menée sans réversibilité expose à devoir tout refaire si la décision est révisée, ce qui arrive régulièrement après quelques mois d'usage.

Sauvegarder avant tout

Une copie complète de la table des contenus, conservée séparément, permet de revenir en arrière sur les contenus transformés. Cette copie doit être gardée plusieurs mois, les problèmes se découvrant parfois longtemps après sur des pages peu consultées. Elle coûte quelques mégaoctets et elle est la seule assurance réelle. La désactivation elle même, en revanche, est parfaitement réversible tant que les contenus n'ont pas été nettoyés. C'est cette asymétrie entre les deux opérations qui doit guider l'ordre dans lequel on procède.

Ne pas nettoyer immédiatement

Désactiver l'éditeur sans toucher aux contenus permet d'observer pendant quelques semaines si la décision tient. Les commentaires de blocs restent visibles à l'édition, ce qui est désagréable et supportable temporairement. Ne lancer le nettoyage qu'après cette période d'essai évite une transformation irréversible sur une décision qui pourrait être revue. Cette prudence coûte quelques semaines d'inconfort et elle évite des situations bien pires. Beaucoup de demandes de désactivation s'éteignent d'elles mêmes pendant cette période d'observation.

Traiter par lots

Le nettoyage des contenus doit se faire par lots de quelques dizaines, avec un contrôle visuel entre chaque. Un traitement appliqué d'un coup à mille articles rend tout diagnostic impossible en cas de problème. Cette progression allonge l'opération et elle la rend réversible à chaque étape. Commencer par les contenus les moins consultés limite l'exposition en cas d'erreur. Les pages les plus visitées se traitent en dernier, une fois le traitement éprouvé sur plusieurs lots.

Documenter la configuration

Une note indiquant ce qui a été désactivé, comment et pourquoi permet à un successeur de comprendre la situation. Sans elle, la personne suivante s'étonnera de ne pas voir l'éditeur attendu et cherchera longtemps d'où vient le comportement. Cette note doit préciser l'emplacement exact du code ou le nom de l'extension employée. Elle tient en dix lignes et elle fait gagner une demi journée.

Surveiller après les mises à jour

Une mise à jour majeure du cœur peut modifier le comportement des filtres employés, notamment lorsque des fonctions sont dépréciées. Un contrôle après chaque mise à jour majeure, consistant simplement à ouvrir un article en édition, suffit à détecter une régression. Ce contrôle prend trente secondes. Son absence explique les situations où l'éditeur de blocs réapparaît sans que personne ne comprenne pourquoi.

Réévaluer périodiquement

L'éditeur de blocs évolue et les motifs de désactivation d'il y a trois ans ne sont pas nécessairement encore valables. Une réévaluation annuelle, portant sur les raisons initiales et sur ce qui a changé depuis, évite de maintenir indéfiniment une configuration devenue inutile. Cette revue prend une heure et elle s'inscrit dans la maintenance normale du site. Elle permet aussi d'anticiper une bascule éventuelle plutôt que de la subir un jour dans l'urgence.