Il y a deux semaines, l’équipe de Gutenberg a lancé un appel ouvert pour des commentaires sur les widgets basés sur des blocs. J’avais déjà écrit un examen long du nouveau système plus tôt en septembre, mais un membre de l’équipe m’a demandé de partager mes réflexions sur l’itération la plus récente. Avec le gel à venir de WordPress 5.6 Beta 1 dans une semaine, je me suis dit que cela ne ferait pas de mal de faire une autre plongée en profondeur.

Pour référence, mes derniers tests portent sur la version 9.2.0-alpha-172f589 du plugin Gutenberg, qui était une version antérieure à la journée. Le développement de Gutenberg avance rapidement, mais tout doit être précis à ce stade.

En fin de compte, bon nombre des problèmes que j’ai signalés il y a plus d’un mois existent toujours. Cependant, l’équipe a nettoyé la plupart des problèmes mineurs, tels que pointer les flèches d’ouverture / fermeture des barres latérales (zones de bloc) dans la bonne direction et la rendre plus cohérente avec l’écran de post-édition. L’interface utilisateur est beaucoup plus raffinée.

Avant de plonger dans tous les problèmes, je veux répondre à la question que je propose. Oui, le système de widgets basé sur des blocs sera prêt pour les heures de grande écoute lorsque WordPress 5.6 arrive. Ce n’est pas encore là, mais c’est à un point où il y a une ligne d’arrivée claire qui est accessible dans les deux prochains mois.

J’ignorerai l’échec des widgets basés sur des blocs dans le personnalisateur, qui a atterri dans Gutenberg 8.9 et était supprimé en 9.1. Je vais également regarder au-delà de la récente proposition de reconstruire l’écran des widgets pour utiliser l’API Customize, du moins pour le moment. Il existe une multitude de problèmes que les widgets basés sur des blocs présentent pour le personnalisateur, et ces problèmes sont insurmontables pour WordPress 5.6. À long terme, WordPress doit avoir un emplacement unique pour modifier les zones de widgets / blocs. Les utilisateurs devront probablement vivre avec certaines incohérences pendant un certain temps.

En supposant que l’équipe n’essaie pas de lancer un Je vous salue Marie de dernière minute et d’implémenter l’édition complète des blocs dans le personnalisateur ce tour, il est prudent de dire que les widgets basés sur des blocs sont en bonne voie vers un début réussi de WordPress 5.6.

L’expérience utilisateur

Ajout d'un widget à l'écran d'édition de widget dans Gutenberg.
Écran des widgets basés sur des blocs.

En tant qu’utilisateur, j’aime vraiment utiliser le nouvel écran d’administration de Widgets. Les zones de bloc ouvertes et de forme libre créent des possibilités incalculables pour la conception de mes sites WordPress. Les widgets traditionnels avaient une portée limitée. Les utilisateurs étaient attachés à une poignée de widgets de base, peut-être à des widgets de plugins, et à tout ce que leur auteur de thème proposait. Cependant, avec les blocs, le pool de choix s’étend au moins au triple des options prêtes à l’emploi (je ne compte pas les blocs de type incorporé individuellement). De plus, les blocs fournissent un ensemble d’options de conception beaucoup plus complet qu’un widget traditionnel.

En comparaison, les widgets traditionnels sont obsolètes. Les blocs sont supérieurs à presque tous les égards. Cependant, il y a encore des problèmes avec ce nouveau système.

Le plus gros problème à l’heure actuelle est que les utilisateurs finaux peuvent quitter l’écran Widgets sans enregistrer leurs modifications. Il n’y a aucun avertissement pour leur faire savoir que tout leur travail est sur le point d’être perdu dans l’éther. C’est l’un de ceux OMGBBQéléments de niveau qui doivent se produire avant que WordPress 5.6 ne tombe.

Une fonctionnalité intéressante mais pas nécessaire serait la possibilité de faire glisser des blocs d’une zone de bloc à une autre. Dans l’ancien système de widgets, les utilisateurs pouvaient déplacer les widgets de la barre latérale vers la barre latérale. L’alternative actuelle consiste à copier un widget, à le coller dans une nouvelle zone de bloc et à supprimer l’original.

Je ne suis pas non plus fan de ne pas avoir d’option pour la barre d’outils supérieure, qui est disponible sur l’écran de post-édition. L’une des raisons d’utiliser cette barre d’outils est que je n’aime pas la barre d’outils contextuelle par défaut sur les blocs individuels. Cela me distrait et gêne souvent mon travail.

Les widgets hérités semblent toujours être un travail en cours. Le bloc Legacy Widget ne fonctionnait pas du tout pour moi à certains moments. Ensuite, cela a commencé à fonctionner comme par magie. Cependant, Gutenberg ajoute désormais automatiquement des widgets tiers enregistrés à l’inséreuse de blocs comme s’il s’agissait de blocs.

Insertion d'un widget hérité tiers dans le système de widgets de Gutenberg.
Faire fonctionner le widget d’un plugin.

Cela posait ses propres problèmes. La seule façon dont j’ai réussi à faire fonctionner les widgets de plugins tiers était d’insérer le widget, d’enregistrer et d’actualiser l’écran des widgets. À ce stade, les widgets sont apparus et sont devenus modifiables.

L’expérience de l’auteur du thème

L’une de mes plus grandes préoccupations pour les auteurs de thèmes à l’heure actuelle est qu’il ne semble pas y avoir de documentation dans le manuel de l’éditeur de blocs. Il y a beaucoup de temps pour que cela se produise, mais il y a des choses dont les auteurs de thèmes doivent être conscients. Avoir un emplacement centralisé, même pendant le développement de la fonctionnalité, les aiderait à se préparer pour la version 5.6.

Certaines de ces questions, auxquelles on peut répondre dans divers articles de blog Make, devraient exister sur une page de documentation dédiée:

  • Comment un thème peut-il désactiver les widgets basés sur des blocs?
  • Quels sont les crochets pour ajouter des styles personnalisés à l’écran Widgets?
  • Les thèmes peuvent-ils cibler des styles de barre latérale spécifiques sur l’écran Widgets?
  • Est-il possible de styliser de manière cohérente les sections comme les widgets traditionnels sur le front-end?
  • Les thèmes peuvent-ils opter pour un alignement large et complet dans les zones de bloc, qui pourraient essentiellement être utilisés de la même manière que la zone de contenu de l’article?

Telles sont quelques-unes des questions auxquelles j’aimerais avoir une réponse en tant qu’ancien auteur de thèmes. Je ne suis plus dans l’épaisseur du jeu de conception de thème et je suppose que ceux qui le sont auraient une plus grande liste de questions.

Une documentation moins évidente devrait se concentrer sur la façon de gérer les replis ou les défauts widgets. Traditionnellement, les thèmes qui devaient afficher un ensemble de widgets par défaut vérifient si la barre latérale contient des widgets et reviennent à l’utilisation the_widget() pour afficher une ou plusieurs valeurs par défaut. Bien que les auteurs de thèmes puissent toujours le faire, nous devrions commencer à les faire passer à travers le système de blocs.

Les auteurs de thèmes doivent-ils copier / coller le code HTML comme solution de secours? Le système de contenu de démarrage serait-il meilleur pour cela et le contenu du widget de démarrage peut-il gérer les blocs? Quelle est la méthode recommandée pour les solutions de secours de widgets dans WordPress 5.6?

Il y a encore le problème en cours de la façon dont les auteurs de thèmes doivent gérer le HTML traditionnel du widget et du wrapper de titre de widget dans le nouveau paradigme de bloc. Un patch ajouté depuis la sortie de Gutenberg 9.1 enveloppe chaque bloc de niveau supérieur avec le wrapper de widget. Si cela arrive dans la version 9.2, cela aggravera probablement le problème.

Dans le système traditionnel, le titre et le contenu du widget sont regroupés dans un conteneur. Cependant, si un utilisateur ajoute un bloc d’en-tête (titre du widget) et un autre bloc (contenu du widget), chaque bloc est enveloppé séparément avec les wrappers de widget du thème. La seule façon de rectifier la situation telle qu’elle se présente est que les utilisateurs finaux ajoutent un bloc de groupe pour chaque «widget» qu’ils souhaitent, ce qui nécessiterait une rééducation importante pour les utilisateurs de WordPress. Ce n’est pas un scénario idéal.

Affichage en direct et en code du code HTML incorrect du wrapper de widget dans Gutenberg.
Chaque bloc est enveloppé comme une section individuelle.

Au lieu d’essayer de «résoudre» directement ce problème, WordPress devrait à la place ne rien faire sur la sortie. Les blocs et les widgets traditionnels sont fondamentalement différents.

Laissez les auteurs de thèmes prendre les rênes de celui-ci et explorer les possibilités. Cependant, donnez-leur les outils pour le faire, tels que prise en charge des modèles de bloc.


Source link