Thèmes FSE et WordPress : à quoi ressemble le MVP ?

Josepha Haden Chomphosy, la directrice exécutive de WordPress, a publié un suivi de son aperçu de l'année à venir. Des questions se sont posées sur ce à quoi ressemblait un produit minimum viable (MVP) pour l'édition complète du site (FSE), qui devrait être prêt dans le plugin Gutenberg en avril. L'équipe de base vise également un lancement en juin de FSE dans WordPress lors de la livraison de WordPress 5.8.

Ces objectifs semblent ambitieux, mais les membres de la communauté des développeurs et des entreprises de WordPress se sont demandé : « Qu'est-ce qu'un MVP pour FSE ? Ce n'est pas une nouvelle question. Qu'il s'agisse du rythme rapide du développement, d'une rupture de communication ou d'une grande partie du projet caché derrière une couche après l'autre des problèmes de GitHub, il peut être difficile à suivre. Il n'y a pas de grande page Web qui énonce chaque étape dans les moindres détails de l'évolution du projet. Les informations peuvent parfois sembler dispersées. Cela peut donner une pause aux développeurs tiers et aux propriétaires d'entreprise qui ont besoin de savoir à quoi s'attendre pour mettre à jour leurs produits.

Joost de Valk, le CPO de Yoast, a exprimé sa frustration face au processus dans les commentaires. Nous en avons discuté plus tard plus en détail.

"Je pense que FSE changera ce qu'est un thème et, s'il est exécuté correctement, il sera beaucoup plus facile de créer un thème, car les thèmes seront beaucoup plus petits", a-t-il déclaré. «Cela impose à la communauté le fardeau de trouver des méthodes de style fiables et des conventions sur les noms de classe ou similaires, pour que le style fonctionne partout. Je ne comprends actuellement pas ce qui est même considéré comme MVP pour l'édition complète du site, et je ne vois aucune discussion sur la façon dont cela fonctionnera avec des thèmes qui ne sont pas spécialement conçus pour cela, et cela m'inquiète.

Il partage certaines des mêmes préoccupations que d'autres membres de la communauté qui ont l'impression qu'il n'y a pas de processus en place pour un MVP.

"Et il n'y a rien de tel", a-t-il dit. "Une vision sans exécution n'est qu'une hallucination."

Chomphosy a déclaré qu'elle était consciente de l'interdépendance. "Je vois aussi que les informations que nous avons publiées ne sont pas dans un article ordonné et suivi qui aiderait les gens à prendre de bonnes décisions au nom de 39 % du Web", a-t-elle déclaré.

Elle a pointé un ticket qui répertorie six (maintenant sept) jalons. Chacun de ces jalons, pris ensemble, représente où FSE doit être pour un MVP.

"Ensemble, ils décrivent une architecture qui permet l'expression d'un thème complet à l'aide de blocs et d'un éditeur capable de personnaliser ce thème", a-t-elle écrit. « Le MVP doit permettre de construire une version du thème Twenty Twenty-One, en utilisant uniquement des blocs, sans aucune connaissance en codage. "

Ce qui suit est une ventilation des étapes qui doivent être terminées avant que nous voyions la première version de FSE atterrir dans WordPress :

Étape 1 : Infrastructure et interface utilisateur

La partie la plus cruciale de FSE est peut-être un éditeur de site fonctionnel. La fusion du système de modèles WordPress dans une interface utilisateur cohérente est la base du projet. L'infrastructure sous-jacente gère le fonctionnement des modèles et des composants de modèle. À ce stade, cette fondation est dans un endroit fiable. Ce sont toutes les fonctionnalités qui en découlent qui nécessitent plus de travail. Cette étape comprend également la mise en place de l'interface d'édition du site et la gestion de la sauvegarde multi-entités.

La dernière étape du jalon permet aux utilisateurs de modifier des modèles à partir de l'éditeur de publication, en basculant efficacement entre l'édition de contenu et l'édition de conception. Le programme de sensibilisation FSE a récemment testé cette fonctionnalité pour recueillir des commentaires après Gutenberg 9.6.

Étape 2 : Naviguer

Ce jalon couvre l'ensemble du travail de navigation dans l'interface utilisateur de l'éditeur du site. Il existe de nombreuses parties mobiles, telles que le basculement entre les pages, les modèles, les parties de modèle, les styles globaux, etc. Les utilisateurs doivent savoir sur quel élément ils travaillent.

Il s'agit de la seule étape marquée comme terminée. Cependant, il existe un ticket ouvert pour explorer l'idée d'un mode "navigation" parallèlement aux modes d'édition et de sélection.

Étape 3 : Style

Pour l'essentiel, cette étape est centrée sur le prochain système Global Styles. Le système crée une hiérarchie de la façon dont les styles sont appliqués aux blocs, des valeurs par défaut du thème aux modifications globales de l'utilisateur, jusqu'aux options de style par bloc.

Alors qu'une grande partie du travail est terminée pour un MVP, il y a des dizaines de tickets de fonctionnalité dans le backlog. C'est également un domaine où le système de blocage a des années de retard sur les constructeurs de pages tiers. Attendez-vous à voir des ajouts de fonctionnalités à long terme basés sur les commentaires post-lancement.

Étape 4 : Blocs thématiques

Les auteurs de thèmes doivent surveiller de près ce ticket. La seule façon pour que les thèmes basés sur des blocs deviennent une réalité pour la plupart des développeurs de thèmes est que toutes les balises de modèle aient un bloc correspondant dans l'éditeur de site. Ou, du moins si les balises de modèle les plus utilisées le font. Certaines de ces fonctions ne sont plus applicables dans l'éditeur de blocs. Les développeurs de thèmes doivent s'assurer qu'ils disposent des blocs dont ils ont besoin pour recréer tout ce qu'ils construisent aujourd'hui.

Certes, je suis triste de voir qu'il est peu probable que les blocs pour les signets/liens progressent. Bien que la fonctionnalité soit obsolète, je suis toujours nostalgique du bon vieux temps des blogrolls. Peut-être que ce serait mieux de laisser un plugin. Une renaissance du plugin Link Manager pourrait être de mise.

Étape 5 : Bloc de requête

Le bloc Requête et son bloc Boucle correspondant sont, à certains égards, les éléments les plus essentiels de l'édition complète du site. Ils gèrent quels messages sont chargés et comment ils sont affichés. La fonctionnalité est l'une des énigmes les plus complexes à résoudre. L'équipe de développement de Gutenberg a continué à l'itérer pendant des mois, et il est maintenant à une bonne base. Cependant, il lui reste encore beaucoup à faire avant de pouvoir gérer sérieusement tout ce que les auteurs de thèmes doivent faire avec.

À l'heure actuelle, le bloc Query ne gère qu'une poignée d'options pour personnaliser la requête. L'équipe doit déterminer quels contrôles doivent être disponibles dans la barre latérale pour les utilisateurs finaux et intégrer les blocs avec des modèles pour différents types d'affichages de post-liste.

Étape 6 : Bloc de navigation

Mis à part le bloc Requête, la navigation est le seul autre bloc qui nécessite son propre jalon. Les problèmes de menu de navigation ont tourmenté le projet WordPress pendant plus d'une décennie. C'est l'une des choses les plus difficiles à faire correctement. Alors que les menus de navigation dans WordPress sont aujourd'hui généralement faciles à utiliser, leur conception n'est pas personnalisable par l'utilisateur final. La sortie est entièrement à la discrétion de l'auteur du thème. Répondre à l'éventail de conceptions de menus possibles que les auteurs de thèmes pourraient souhaiter et le rendre personnalisable pour l'utilisateur final est probablement l'un des problèmes les plus difficiles pour le projet Gutenberg.

Il y a au moins deux douzaines de sous-tickets qui ont besoin de contributeurs. Même dans ce cas, il pourrait s'écouler plusieurs versions plus tard avant que le bloc de navigation ne soit prêt pour les modèles plus complexes utilisés dans certains thèmes aujourd'hui.

Étape 7 : Adoption progressive

Une fois les six premières étapes représentant le MVP terminées, WordPress a besoin d'un moyen de permettre aux utilisateurs finaux et aux auteurs de thèmes d'adopter progressivement FSE. Il s'agirait principalement d'un mélange de modèles basés sur des blocs et de modèles traditionnels basés sur PHP. Les développeurs devraient être autorisés à mettre à jour leurs thèmes sans les modifier en gros, laissant potentiellement derrière eux des segments de leur base d'utilisateurs.

Les widgets basés sur des blocs et les écrans de navigation relèvent également de cette étape. Les deux fonctionnalités ont été lancées dans les versions futures après avoir échoué en 2020. Cependant, ce seront des tremplins pour les utilisateurs qui ne sont pas tout à fait prêts à passer à FSE ou qui ne peuvent pas le faire en raison de leur thème.