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 :

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

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

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

J+10
WordPress 5.0 – Déploiement

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

La suite suit un schéma classique 

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 :

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 :

Planification du fallback Classic Editor sur WordPress 5.0

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

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

J+10
WordPress 5.0 – Déploiement

La suite suit un schéma classique

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 :

Planification

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.

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.

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.

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 ?