Josepha Haden Chomphosy, la directrice exécutive de WordPress, a publié un suivi à elle 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ête dans le plugin Gutenberg en avril. L’équipe principale envisage également un lancement en juin de FSE dans WordPress lors de la livraison de WordPress 5.8.
Celles-ci semblent être des objectifs ambitieux, mais les membres de la communauté des développeurs et des entreprises 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 panne de communication ou d’une grande partie du projet caché derrière une couche après couche de problèmes GitHub, cela peut être difficile à suivre. Il n’y a pas de grande page Web qui explique chaque étape dans les moindres détails de la destination 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 avec le 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 fiables de style, 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 dans la communauté qui pensent qu’il n’y a pas de processus en place pour un MVP.
«Et il n’y a rien de tel», dit-il. «Une vision sans exécution n’est qu’une hallucination.»
Chomphosy a déclaré qu’elle était consciente de l’interdépendance. «Je vois également que les informations que nous avons publiées ne sont pas dans un article ordonné et suivable qui aiderait les gens à prendre de bonnes décisions au nom de 39% du Web», a-t-elle déclaré.
Elle a souligné un ticket qui répertorie six (maintenant sept) jalons. Chacun de ces jalons, lorsqu’ils sont pris ensemble, représentent 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», écrit-elle. « Le MVP devrait 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 jalons qui doivent être achevés avant de voir la première version de FSE débarquer dans WordPress:
Jalon 1: infrastructure et interface utilisateur
La partie la plus cruciale de FSE est peut-être é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 parties 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. Ce jalon comprend également la mise en place de l’interface d’édition de site et la gestion de la sauvegarde multi-entités.
La dernière étape du jalon permet aux utilisateurs de modifier les modèles depuis l’éditeur de publication, basculant efficacement entre le contenu et l’édition de conception. Le programme de sensibilisation FSE récemment testé cette fonctionnalité pour recueillir des commentaires après Gutenberg 9.6.
Étape 2: navigation
Cette étape couvre tous les travaux pour navigation dans l’interface utilisateur de l’éditeur du site. Il existe de nombreuses parties mobiles, telles que la commutation entre les pages, les modèles, les éléments de modèle, les styles globaux, etc. Les utilisateurs doivent savoir sur quel élément ils travaillent.
C’est la seule étape marquée comme terminée. Cependant, il existe un ticket ouvert pour explorer l’idée d’un Mode «navigation» à côté des modes d’édition et de sélection.
Étape 3: Stylisme
Pour l’essentiel, cette étape est centrée sur le prochain système Global Styles. La 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 utilisateur globales, jusqu’aux options de style par bloc.
Bien qu’une grande partie du travail soit terminée pour un MVP, il y a des dizaines de tickets de fonctionnalités 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 garder un œil attentif sur ce ticket. La seule façon dont les thèmes basés sur des blocs deviennent une réalité pour la plupart des développeurs de thèmes est si tout les balises de modèle ont un bloc correspondant dans l’éditeur du 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 que les blocages pour les signets / liens ont peu de chances d’avancer. Bien que la fonctionnalité soit obsolète, je suis toujours nostalgique des bons vieux jours de blogroll. Peut-être que ce serait mieux de laisser un plugin. Un renouveau de la Gestionnaire de liens plugin pourrait être en ordre.
Étape 5: Bloc de requête
La Bloc de requête et son bloc Loop 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. Cette 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 des kilomètres à parcourir avant de pouvoir gérer sérieusement tout ce que les auteurs de thèmes doivent en faire.
À l’heure actuelle, le bloc Requête 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.
Jalon 6: bloc de navigation
Mis à part le bloc de requête, la navigation est le seul autre bloc qui nécessite son propre jalon. Les problèmes de menu de navigation affectent le projet WordPress depuis plus d’une décennie. C’est l’une des choses les plus difficiles à faire. 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. Prendre en compte l’éventail de conceptions de menus que les auteurs de thèmes peuvent 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 y avoir 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 premiers jalons représentant le MVP terminés, 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 basés sur PHP traditionnels. 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 et les écrans de navigation basés sur des blocs relèvent également de cette étape. Les deux fonctionnalités ont été livrées à de futures versions après avoir échoué à atterrir en 2020. Cependant, ce seront des tremplins pour les utilisateurs qui ne sont pas tout à fait prêts à passer à FSE ou qui ne le peuvent pas en raison de leur thème.
Source link