L'édition complète du site atterrira-t-elle dans WordPress 5.8 ? Une décision est à venir

Hier, Josepha Haden Chomphosy a annoncé la feuille de route pour décider si l'édition complète du site (FSE) atterrira dans WordPress 5.8. Après le lancement de Gutenberg 10.4 le 14 avril, un petit groupe de core leads participera à une démo go/no-go.

Les personnes suivantes seront à l'appel :

• Matias Ventura – Gutenberg Project Lead qui animera la démo.
• Matt Mullenweg – Chef de projet WordPress.
• Helen Hou-Sandi – Développeur principal.
• Josepha Haden Chomphosy – Directrice exécutive.

L'ordre du jour de la réunion est simple. Ventura hébergera la démonstration, et le groupe discutera et couvrira les questions de mise en œuvre.

S'il n'y a pas de bloqueurs, ils partageront un plan pour fusionner FSE dans WordPress. Le résultat le plus probable est qu'ils trouveront au moins quelques éléments qui doivent être traités. Dans ce cas, ils les partageront publiquement avec un plan pour les résoudre avant une deuxième date de non-participation du 27 avril.

La première version bêta de WordPress 5.8 est prévue pour le 8 juin, avec une version grand public pour le 20 juillet. L'équipe doit décider de l'inclusion au début du cycle de publication pour donner aux développeurs de thèmes et de plugins le temps de se préparer.

Alors que beaucoup sont sur leurs gardes en attendant une décision finale, tout le monde doit faire preuve d'un peu de patience pour le moment. Tout doit être soigneusement pesé par les porteurs de projet. Il y a de fortes chances que nous ne sachions pas le résultat avant cette deuxième date limite, le 27 avril.

La majeure partie de la transition FSE serait une version bêta pour un sous-ensemble d'utilisateurs. Inclure ces fonctionnalités dans le noyau ne signifie pas que WordPress bascule immédiatement le commutateur et active tout pour 40 % du Web. Pour l'expérience globale de FSE, les utilisateurs doivent faire un choix explicite d'installer et d'activer un thème basé sur des blocs.

Dans cet esprit, l'expérience d'intégration doit être une expérience accueillante qui invite les utilisateurs à modifier le site tout en les informant des problèmes potentiels. S'il s'agit d'une version bêta intégrée, ils doivent vraiment comprendre que des améliorations sont à venir.

Une version bêta intégrée comme celle-ci est également la bienvenue, étant donné le lancement du projet de l'éditeur de blocs il y a quelques années. Que les gens aient aimé ou détesté l'éditeur de blocs, le déploiement n'a pas été fluide pour tout le monde. WordPress a laissé tomber les utilisateurs finaux dans un système remanié, ce qui a été un changement choquant pour beaucoup. Le projet a une chance de faire mieux cette fois-ci en introduisant progressivement des fonctionnalités aux utilisateurs et en permettant aux autres de s'immerger dans la nouvelle expérience de leur choix.

"Le contexte le plus important à partager est qu'il ne s'agit pas de l'expérience complète par défaut pour les utilisateurs ", a écrit Chomphosy dans le message, notant que l'équipe grandit au-delà des erreurs passées. "L'un des commentaires les plus clairs du processus de fusion de la phase un était que nos extenseurs (agences, auteurs de thèmes, développeurs de plugins, constructeurs de sites, etc.) n'avaient pas assez de temps pour se préparer aux changements à venir."

Les décideurs peuvent également décider d'expédier certaines pièces mais pas d'autres. FSE est un projet composé de plusieurs composantes.

"L'ensemble du projet d'édition complète du site est en quelque sorte un terme générique pour une collection d'outils et de projets, il serait donc possible que certaines pièces soient expédiées tandis que d'autres ne le font pas", a déclaré Haden Chomphosy. "Il y a probablement quelques exceptions à cela, comme vous l'avez mentionné, mais beaucoup d'entre elles peuvent être expédiées dès qu'elles sont prêtes."

Les exceptions auxquelles elle faisait référence sont des composants qui ont plus de sens ensemble. Par exemple, les thèmes basés sur des blocs via un fichier de configuration theme.json et la plupart des blocs d'édition de site ne sont pas aussi utiles lorsqu'ils sont séparés.

Bien sûr, il y a des cas où quelque chose comme le bloc Query pourrait être utilisé en dehors de l'éditeur du site. Les utilisateurs peuvent créer des requêtes personnalisées dans une page sans bénéficier de l'éditeur de site, par exemple.

Ma principale préoccupation ne concerne pas les fonctionnalités liées à l'éditeur de site, mais les widgets basés sur des blocs. C'est un outil de transition pour les utilisateurs sur des thèmes traditionnels. Avec le nouvel écran des menus de navigation, il ne fait pas partie de l'expérience des thèmes basés sur des blocs. L'objectif est de permettre aux utilisateurs de commencer à utiliser des blocs à plus d'endroits. Cependant, cela se traduira par une UX cassée dans de nombreux cas.

L'expérience des widgets est encore partiellement interrompue, traitant chaque bloc comme un widget séparé. Les utilisateurs doivent apprendre à mettre un titre (titre du widget) et un autre bloc (contenu du widget) dans un groupe (widget wrapper) pour les bonnes classes liées au widget sur le front-end du site. Pour certains thèmes, que les utilisateurs le fassent ne sera pas un problème. Pour d'autres, cela aura l'air moche au mieux et cassera la mise en page au pire. Mettre cette responsabilité sur les épaules des utilisateurs finaux a été considéré comme une solution acceptable.

Je voulais me concentrer sur ce problème car c'est l'une de ces choses qui peuvent simplement être activées pour tous les utilisateurs. Je crains toujours que la transition d'un système fonctionnel à un système potentiellement défectueux ne soit un parcours cahoteux.

L'équipe de publication de WordPress 5.6 a décidé de ne pas expédier de widgets basés sur des blocs. Hou-Sandi, en tant que responsable technique principal de la version 5.6, a fourni un historique de la décision et expliqué pourquoi elle n'était pas prête à être incluse :

Ma question pour les fonctionnalités qui affectent le front-end est "puis-je essayer cette nouvelle chose sans risquer de gâcher mon site?" - c'est-à-dire la confiance des utilisateurs. À l'heure actuelle, étant donné que les zones de widgets ne sont pas affichées comme ce que vous voyez sur votre site sans que les thèmes y mettent vraiment l'effort et que vous devez enregistrer vos modifications en direct sans révisions pour obtenir une vue contextuelle réelle, les blocs de zones de widgets ne vous permettent d'essayer cette nouvelle fonctionnalité sans vous pénaliser pour l'expérimentation.

Bien que les widgets se soient sans doute améliorés, je considère toujours que la réponse est la même qu'en octobre dernier. Je n'ai pas vu suffisamment d'adhésion de la part de la communauté de développement de thèmes pour prendre en charge l'éditeur de blocs lui-même, et encore moins de nouvelles fonctionnalités liées aux blocs. Cependant, à un moment donné, le projet doit simplement avancer. Themers devra juste suivre.