Maintenance WordPress : Préparer et planifier la mise à jour vers Gutenberg

Gutenberg

En tant que modification majeure de l’éditeur de contenus de WordPress, Gutenberg pose de vraies questions pour la maintenance des parcs de sites existants.

En effet, la migration vers Gutenberg changeant radicalement la gestion actuelle des contenus, les sites utilisant des champs personnalisés sur-mesure, des développements spécifiques ou des page builders risquent d’être impactés. En plus de cela, de nombreux confrères produisant des sites WordPress et aussi beaucoup d’utilisateurs de ce CMS s’inquiètent d’un changement non anticipé et ont peur de se retrouver le jour-J devant un arbitrage complexe : dois-je passer sur WP 5.0 et Gutenberg ou suis-je condamné à rester sur la branche 4.9 ?

Sachant que nous proposons une offre spécifique de maintenance de sites WordPress, nous sommes obligés d’anticiper les changements induits par Gutenberg. Tout comme nous anticipons chaque mise à jour du core WordPress en général.

Investir du temps dans nos contributions à la communauté et participer directement au développement du cœur WordPress permet en effet de proposer aux clients l’expertise la plus complète possible sur ce CMS.

Dans le cas de notre parc de sites WordPress et avec les élément appris pendant les meetings hebdomadaires des développeurs de la version 5.0 de WP auxquels nous participons, plusieurs cas de figure se présentent :

  • Passer de WordPress 5.0 et à Gutenberg – en prenant soin de proposer un accompagnement au changement pour les personnes chargées de l’administration des sites.
  • Passer de WordPress 5.0 en conservant l’éditeur classique tout en communicant sur la sortie de Gutenberg.
  • Rester sur la branche 4.9 car le site ne permet pas une mise à jour maîtrisée. Ce cas est à éviter par tous les moyens (on en parlera plus loin), mais dans tous les cas, une communication est faite au client en toute transparence.

Note importante : nous ne connaissons à ce jour pas la date de sortie de WordPress 5.0 et donc la roadmap associée. J’ai donc choisi de présenter des rétroplannings plutôt que des échéances datées. Vous pourrez y associer des dates dès que la roadmap sera connue, ce que nous ne manquerons pas d’annoncer sur ce blog 🙂

Cas 1
Mise à jour vers WordPress 5 et utilisation de Gutenberg & conduite du changement pour les responsables éditoriaux

Le cas de figure idéal : le site utilise des dépendances applicatives (thèmes, plugins, développements spécifiques) conformes aux WordPress Coding Standards et après tests du plugin Gutenberg (déjà disponible), tout fonctionne plutôt bien. La mise à jour doit tout de même être anticipée et donc planifiée.

Planification de la migration vers Gutenberg et WordPress 5

J-30
WordPress 5.0 : Sortie de la première béta

  • Clonage du site sur une instance de test spécifique qui pourra être supprimée à l’issue de ce process.
  • L’extension Classic Editor est installée sur l’instance de test. Cette extension permettant de basculer à tout moment de Gutenberg à l’éditeur classique est paramétrée par défaut en « mode Gutenberg » avec possibilité d’activer le mode « Classic ».
  • Première recette du site en mode Gutenberg.
  • Si des incompatibilités ou des risques majeurs sont finalement détectés, suppression de l’instance de dév « G. » et bascule sur le cas de maintenance numéro 2.

J-30 à J-15
Développements spécifiques

  • Côté Whodunit, nous allons créer une extension (qui pourrait être intégrée dans le Whodunit Dashboard, notre plugin permettant des réglages de base optimisés de WP pour nos clients) permettant d’activer/désactiver certains blocs ou paramètres de l’éditeur Gutenberg.
  • Dans certains cas, des développements spécifiques devront être réalisés.

J-15
WordPress 5.0 – Sortie de la première RC

  • Vérification de bon fonctionnement de l’instance de dév.
  • Passage en pré-production.
  • Recette.

J+10
WordPress 5.0 – Déploiement

Mise à jour de l’installation en pré-production.

La suite suit un schéma classique 

  • Recette
  • Passage en production
  • Vérification de fonctionnement nominal
  • Rapport de maintenance

PRINCIPAUX RISQUES

Failles de sécurité du core
— Risque faible : nous sommes en version 5.0, le site est donc à jour

Incompatibilité de dépendances applicatives
— Risque faible, mais…
➡️ Si des dépendances (thèmes, plugins, développements spécifiques) ne sont pas compatibles avec Gutenberg lors des tests à J-30, le site doit être placé dans le cas de figure numéro 2 (voir plus loin).

Complexité de gestion et moyens à mettre en œuvre

Accompagner le changement pour les rédacteurs de contenus sur Gutenberg

Dans un premier temps, l’installation Classic editor est configurée afin de laisser le choix à l’utilisateur d’utiliser ou non Gutenberg. L’utilisateur doit être encouragé à utiliser Gutenberg et à ne réserver l’éditeur classique qu’à l’édition de contenus bien identifiés pour leurs spécificités.

Les types de contenus personnalisés (CPT) trop spécifiques pour accueillir Gutenberg sont identifiés et sur ces contenus le nouvel éditeur est désactivé via un filtre disponible dans le noyau WordPress. Il est actuellement nommé : 

gutenberg_can_edit_post_type( )

Un guide d’utilisation de Gutenberg pour les rédacteurs de contenus doit être créé par le prestataire afin d’accompagner sa prise en main.

La question principale est d’anticiper les coûts de ce process pour le client, sachant qu’une part du process est mutualisée (guide d’utilisation et désactivation/activation de blocs et pré-paramétrage de Gutenberg) et qu’une autre partie est spécifique (développements spécifiques et recette).

Anticiper le coût des développements spécifiques à réaliser

Création d’un plugin de paramétrages par défaut pour Gutenberg : il s’agit d’une extension maison qui s’ajoute à notre plugin spécifique Whodunit Dashboard pour réaliser un certain nombre de paramétrages par défaut sur Gut’. Elle comprend :

  • La désactivation de certains blocs
  • Le paramétrage des options de formatage : suppression de niveaux de titres inutiles, suppression de boutons, ajout des formatages indice/exposant, etc.
  • La gestion des développements spécifiques propres au projet :
    • Mise en conformité des développements spécifiques réalisés sur l’éditeur : options de formatage, shortcodes éventuels, transformation de shortcodes en blocs Gutenberg, etc.
    • Mise en conformité des développements spécifiques réalisés sur la page d’édition, par exemple d’éventuelles métaboxes spécifiques.

Cas 2
Mise à jour vers WordPress 5 sans Gutenberg avec un retour vers l’éditeur classique

Il s’agit du choix de mettre à jour vers WordPress 5 mais de faire un fallback, c’est à dire de conserver l’éditeur en mode « classic ». Ce choix pourrait être le choix le plus courant sur les sites actuellement en maintenance, au moins le temps d’effectuer des correctifs voire de lancer une refonte partielle de certains éléments du périmètre fonctionnel de chaque site.

Il est le choix retenu si l’installation se trouve dans ce cas de figure :

  • Dépendances applicatives (thème, extensions et développements spécifiques éventuels) listées comme étant peu ou pas compatibles avec Gutenberg.

Planification du fallback Classic Editor sur WordPress 5.0

J-30
WordPress 5.0 : Sortie de la première béta

  • Le site est classé dans ce cas de figure numéro 2.

J-15
WordPress 5.0 – Sortie de la première RC

  • Au moment de la sortie de la première Release Candidate de WP 5 (fin de la période de béta test), l’extension Classic Editor est installée en tant que mu-plugin (extension ne pouvant être désactivée que par une action spécifique). Son auteur Andrew Ozz (WordPress Core lead developer) a d’ores et déjà annoncé que l’extension sera modifiée pour pouvoir être installée alors même que Gutenberg n’est pas présent sur le site.

J+10
WordPress 5.0 – Déploiement

  • Mise à jour de l’installation en preprod et activation du mode classique paramétré pour se substituer totalement à Gutenberg, qui est alors désactivé pour tous les types de contenus de l’installation.

La suite suit un schéma classique

  • Recette
  • Passage en production
  • Vérification de fonctionnement nominal
  • Rapport de maintenance

PRINCIPAUX RISQUES ET MOYENS À METTRE EN ŒUVRE

Failles de sécurité du core
— Risque faible, on est en WP 5.0

Difficulté de maintenance du core
— Risque moyennement élevé à moyen terme, cette extension devrait rester fonctionnelle pendant quelques temps.

Incompatibilité de dépendances applicatives
— Risque moyennement élevé à court et moyen terme | Complexe
➡️ Chaque installation concernée par ce choix doit être auditée afin de mettre en avant la liste des dépendances (thèmes et extensions) pouvant présenter des incompatibilités à moyen terme lors de leur passage progressif à Gutenberg.
Cette liste doit faire l’objet d’une vérification mensuelle. Pour plus de sûreté, il est conseillé de ne réaliser les mises à jour que mensuellement, ou en tout cas après une vérification de la liste des dépendances mutuelles et de leur compatibilité.
Pour mutualiser ces risques, il peut être utile de maintenir une liste commune des extensions/thèmes et une liste pour chaque site, ces documents étant mis à jour depuis une seule liste commune.

Cas 3
L’impossibilité de mettre à jour vers WP 5.0…

Il s’agit du choix de repousser ou même de refuser sur le long terme la mise à jour vers WordPress 5 pour rester en branche 4.9.x. Ce choix expose à divers problématiques de maintenance bien connues et ne doit être pris qu’en tout dernier recours, et bien évidemment évité à tout prix si cela est possible.

Il est le choix retenu si l’installation se trouve dans l’un de ces cas de figure :

  • Présence d’un page builder n’ayant pas annoncé de support de Gutenberg et présentant des risques de ne pas fonctionner nominalement avec l’extension Classic Editor. Suivant l’évolution de l’écosystème (extension Classic Editor et page builder concerné), ce cas de figure pourra être transféré dans le cas 2.
  • Présence d’extensions / thèmes dont la compatibilité avec Gutenberg ne sera pas assurée à court et moyen terme.
  • Installation instable.
  • Installation multisite avec de nombreuses hétérogénéités suivant les sites du réseau et une incompatibilité partielle conduisant à l’impossibilité de réaliser la mise à jour vers WordPress 5.0 pour l’ensemble du réseau.

Planification

  • Communication client et proposition d’alternatives (allant de la mise en place de patches correctifs jusqu’à envisager une refonte complète ou partielle suivant les cas)
  • Désactivation des mises à jour majeures automatiques le cas échéant.
  • Activation des mises à jour mineures automatiques.
  • Désactivation de la possibilité de mettre à jour le core depuis notre console de maintenance.
  • Maintenance d’une liste des sites concernés et suivi de l’état de santé des sites.

PRINCIPAUX RISQUES ET MOYENS À METTRE EN ŒUVRE

Failles de sécurité du core
—Risque moyennement élevé à court et moyen terme, très élevé à critique sur le long terme
➡️ La branche 4.9 sera a minima maintenue en terme de sécurité durant les deux prochaines années, soit jusqu’à 2019 voire 2020.

Incompatibilité de dépendances applicatives
— Risque élevé à court terme ; très élevé à moyen terme | Complexe
➡️ Chaque installation concernée par ce choix doit être auditée afin de mettre en avant la liste des dépendances (thèmes et extensions) pouvant présenter des incompatibilités à moyen terme lors de leur passage progressif à Gutenberg. Cette liste doit faire l’objet d’une vérification mensuelle. Pour plus de sûreté, il est conseillé de ne réaliser les mises à jour que mensuellement, ou en tout cas après une vérification de la liste des dépendances mutuelles et de leur compatibilité.
Pour mutualiser ces risques, il peut être utile de maintenir une liste commune des extensions/thèmes et une liste pour chaque site, ces documents étant mis à jour depuis une seule liste commune par la suite.

Difficulté de maintenance du core
— Risque faible à moyen terme | Moyennement complexe
➡️ Les mises à jour du core devront être rendues indisponibles pour ces sites sur ManageWP. Les mises à jour mineures du core WordPress devront être automatisées. Pour les installations ne permettant pas l’automatisation des MAJ mineures, elles devront être réalisées manuellement, en prenant garde de ne pas passer en branche 5.x. Les mises à jour réalisées ne seront en tout état de cause pas reportées sur les rapports de maintenance ManageWP.

Pour conclure sur WordPress 5, Gutenberg et la maintenance de vos sites

Je vous recommande vivement et dès à présent de lister les sites que vous avez en maintenance, de les catégoriser et de les répartir suivant les cas de figure. Chez Whodunit, notre objectif est bien évidemment de passer un maximum de sites web dans les cas 1 et 2 et donc d’accompagner nos clients en maintenance pour une migration vers WordPress 5.

J’espère avant tout que cet article sur la façon dont nous envisageons notre maintenance et la migration vers WordPress 5.0 et Gutenberg vous aura apporté des billes sur la question délicate qui se pose aujourd’hui : dois-je ou non passer sur Gutenberg et comment m’y prendre pour réaliser et planifier cela ?

Maintenance WordPress

Maintenance préventive, corrective, évolutive et TMA… retrouvez nos ressources pour bien comprendre la maintenance WordPress.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *