Cinq modèles de défaillance issus des mises à niveau majeures précédentes de WordPress – ce que Gutenberg 5.0 à FSE 6.0 a enseigné aux équipes de maintenance

Avec la liste de contrôle préalable à la mise à niveau composée de sept éléments et le cadre d'étalonnage indiquant quand postuler, nous avons couvert la préparation et le calendrier des mises à niveau majeures de WordPress. Le troisième volet est « ce qui peut mal tourner » – les échecs qui se sont réellement produits dans les majors précédentes, organisés en cinq modèles.

Les exemples sont liés à des versions spécifiques (5.0 / 5.6 / 6.0), mais le fait est que les mêmes modèles structurels se répètent dans les nouvelles majors. Les avoir sous forme de types dans votre tête est payant lorsque la version 7.0 ou 8.0 arrive et que vous devez effectuer un tri rapide.

Modèle 1 — Les « extensions d'interface utilisateur adjacentes à l'éditeur » disparaissent en masse (5.0 Gutenberg)

L'incident le plus impactant sur le plan opérationnel lorsque WordPress 5.0 a standardisé l'éditeur de blocs (Gutenberg).

Symptôme : les méta-boîtes personnalisées en supposant que l'éditeur classique (TinyMCE), les interfaces utilisateur de champs personnalisés et les extensions de l'éditeur de plug-in tiers ont cessé de fonctionner simultanément. Le contenu lui-même n'était pas cassé, mais l'interface utilisateur d'édition a disparu.

Cause : Le code écrit sur le DOM et les hooks de l'éditeur classique perd ses points d'ancrage dans l'interface utilisateur basée sur React de Gutenberg. Simpleadd_meta_box()les extensions ont continué à fonctionner, mais tout ce qui était directement connecté à une instance TinyMCE est tombé complètement.

Le modèle de correctif : exécutez leÉditeur class...
[Courte citation de 8% de l'article original]