Enquête ouverte pour les auteurs de thèmes WordPress sur les fichiers JSON et les thèmes de blocs

WordPress 5.8 a introduit un système opt-in pour les thèmes afin de configurer les paramètres de bloc, les styles, les modèles, etc. Cela se fait via un nouveau fichier theme.json que les auteurs peuvent mettre à la racine de leurs dossiers de thèmes. Anne McCarthy, responsable du programme de sensibilisation FSE, a annoncé un sondage plus tôt dans la journée pour obtenir les commentaires des développeurs sur cette fonctionnalité.

"Étant donné que ce nouveau mécanisme est une première étape vers un système de style complet pour l'avenir de WordPress, il est important d'entendre tous ceux qui utilisent actuellement theme.json pour en savoir plus sur la façon dont les gens utilisent cet outil et ce qui pourrait être logique d'inclure dans Core à l'avenir », a-t-elle écrit dans l'annonce.

L'enquête est ouverte à tous les auteurs de thèmes qui ont utilisé theme.json , ce qui leur donne la possibilité de faire part de leurs premiers commentaires et d'aider à diriger le navire à l'avenir.

Parce que j'ai beaucoup travaillé avec ce système au cours des derniers mois, j'avais quelques choses à dire. De plus, j'aime tout simplement participer à des sondages liés à WordPress. J'ai également décidé que ce serait l'occasion de partager certaines de mes réflexions non filtrées du point de vue du développement sur l'état actuel de theme.json .

Ce qui suit sont mes réponses aux questions de l'enquête - enfin, la version rangée.

Remarque : il s'agit d'un article centré sur les développeurs qui pourrait ne pas plaire à tous nos lecteurs. J'ai essayé d'expliquer certaines choses dans une terminologie conviviale, mais certaines connaissances préalables du développement de thèmes peuvent être nécessaires.

De l'expérience

La première question du sondage est assez simple. Il vous demande quelle est votre expérience avec les thèmes de blocs de construction ou l'utilisation theme.json . Il propose quatre choix (et une option "autre") :

• J'ai construit et lancé des thèmes de blocs.
• J'ai expérimenté des thèmes de blocs de construction.
• J'ai exploré l'utilisation de theme.json avec un thème classique.
• J'ai utilisé un thème de bloc, mais je n'en ai pas encore construit.

J'ai choisi la première option car j'ai déjà construit deux thèmes de blocs pour la famille et les amis. Il s'agissait de simples sites personnels que je maintiens déjà gratuitement - honnêtement, je dois commencer à facturer . Je travaille également sur un thème que j'espère rendre public.

Comment ça a commencé et comment ça se passe

La deuxième question demande comment on a commencé avec les thèmes de bloc et theme.json . Les choix sont entre créer un thème existant, utiliser le thème vide ou partir de zéro.

Encore une fois, c'est l'une de ces choses où j'ai expérimenté chaque direction, mais je ne me souviens pas du point de départ exact. L'essentiel de mon travail est venu de la création d'un thème sur lequel j'ai travaillé pour la dernière fois en 2019.

Je prévois de le publier en tant que nouveau thème gratuitement à un moment donné. J'attends surtout les choses suivantes :

• Développement du bloc de navigation pour s'installer
• Le bloc Post Author à diviser en blocs plus petits
• Un ensemble robuste de blocs liés aux commentaires
• Bloc Post Featured Image pour avoir une option de taille

Je pense que je pourrais de manière réaliste publier une version bêta de mon thème à vos propres risques aujourd'hui si ces éléments étaient traités.

Modèles et parties de modèle

L'enquête demandait quels modèles et parties de modèle les thèmes incluaient toujours dans leurs thèmes basés sur des blocs. Il y avait un champ de commentaire de forme libre - des étapes sur une boîte à savon…

J'ai une relation amour/haine avec les modèles de blocs en ce moment. La nature statique des modèles HTML me rappelle des temps plus simples où le développement de thèmes était moins compliqué. Cependant, cela pose également un problème dans un système dynamique.

Je ne me souviens pas de la dernière fois où j'ai construit un thème traditionnel basé sur PHP avec plus d'un modèle de niveau supérieur : index.php . Les pièces dynamiques ont toujours été les entrailles de la chose, qui sont des pièces de modèle. Avec PHP, il est facile de définir une variable ou d'utiliser un appel de fonction pour charger contextuellement les parties de modèles nécessaires à la page qu'un visiteur consulte actuellement sur un site.

Le système de modèle de bloc ne fonctionne pas comme ça. Cela oblige essentiellement les développeurs à enfreindre le principe Ne vous répétez pas (DRY).

Par exemple, si un concepteur souhaitait afficher une partie de modèle d'en-tête différente pour les pages et les publications, il lui suffirait de créer un header-page.php ou header-post.php dans les thèmes traditionnels. Cependant, comme le système de modèle de bloc est différent, ils doivent maintenant créer deux modèles de niveau supérieur, single.html (post) et page.html , pour accomplir la même chose.

C'est une "mauvaise chose" car les auteurs de thèmes doivent dupliquer tous les autres codes dans chacun des modèles de niveau supérieur. Il n'existe aucun moyen de charger contextuellement différentes parties de modèle.

Pour répondre à la question : j'utilise presque tous les modèles de niveau supérieur possibles par nécessité.

J'ai également répondu à la deuxième partie de la question et répertorié mes éléments de modèle les plus couramment utilisés (ventilés par hiérarchie):

• Entête
• Contenu
  - Boucler
  – Barre latérale
• Bas de page

Les parties de modèle content-*.html et loop-*.html sont celles qui présentent le plus de variations.

Définir les couleurs

La section suivante de l'enquête demande comment les auteurs de thèmes définissent leurs slugs de palette de couleurs dans theme.json . Croyez-le ou non, nommer les couleurs peut être le sujet le plus controversé dans le monde des thèmes depuis des années. Les deux seules choses généralement convenues sont les couleurs « d'arrière-plan » et « de premier plan ».

Morten Rand-Hendriksen a ouvert un ticket en 2018 pour la standardisation d'un schéma de dénomination des couleurs de thème. Ce n'était pas la première discussion et n'a pas été la dernière. Le problème qu'il était censé résoudre était les slugs pour les couleurs dans le système, c'est ainsi que les thèmes définissent leurs palettes. Une fois qu'un utilisateur utilise une couleur prédéfinie, le slug est codé en dur dans son contenu. Passez à un autre thème avec des slugs différents, et les anciennes couleurs disparaissent et ne passent pas automatiquement aux couleurs du nouveau thème.

J'utilise des noms sémantiques qui suivent quelque chose qui ressemble étroitement au système d'ombrage du framework CSS Tailwind. Au lieu de red-medium (descriptif), j'utiliserais primary-500 (sémantique), par exemple. Une approche sémantique permettrait aux auteurs de thèmes de définir un ensemble de couleurs qui sont mises à jour chaque fois qu'un utilisateur change de thème.

Bien sûr, il existe d'autres écoles de pensée, et même tous ceux qui préfèrent la dénomination sémantique ne sont pas d'accord sur le même système. J'ai décrit mon approche plus en détail dans un ticket GitHub plus récent et j'ai un theme.json Gist pour les autres qui pourraient vouloir l'essayer.

Autres paramètres JSON du thème

En dehors des couleurs et de la typographie, l'enquête demande quels autres auteurs de thèmes de paramètres ont utilisés. C'est un autre scénario où j'utilise généralement tout - s'il y a une option pour cela, je le définis.

Un cas d'utilisation pour lequel WordPress n'a pas actuellement de préréglage est l'espacement global. La plupart des auteurs de thèmes utilisent une seule valeur pour la plupart des marges verticales (espace blanc entre les blocs et les éléments). Il est également souvent utilisé pour le rembourrage vertical et horizontal par défaut.

Je ne sais pas si je veux un préréglage car je ne sais pas comment WordPress va l'utiliser. C'est quelque chose que d'autres ont demandé, et il est presque omniprésent. Définir un système entier autour de lui pourrait causer des maux de tête sur la route, mais j'aimerais quand même voir une discussion sur la mise en œuvre d'au moins un préréglage d'espacement global standard.

Paramètres et styles par bloc

Cette section d'enquête était une question oui/non, demandant simplement si les auteurs de thèmes incluaient des paramètres ou des styles par bloc dans leurs fichiers theme.json . Bien sûr, j'ai laissé quelques commentaires supplémentaires plus tard dans la section des commentaires facultatifs.

Je suis satisfait du système en ce qui concerne les paramètres, ce qui permet aux utilisateurs de définir quelles fonctionnalités sont activées globalement ou par bloc. Cependant, je ne suis pas convaincu par l'ajout de styles via theme.json .

Écrire du CSS dans JSON, ce dont nous parlons essentiellement, semble mal à bien des niveaux. Actuellement, il est limité à quelques styles configurables, donc tout ce qui va au-delà nécessite de toute façon de plonger dans un fichier CSS réel. C'est problématique car la moitié du code CSS du thème est divisée entre theme.json et un fichier CSS séparé. Du point de vue du développement, cela rend la base de code plus difficile à maintenir.

Au départ, j'ai commencé à configurer les styles par bloc et par élément à partir de theme.json . Cependant, j'ai depuis déplacé mon style vers les fichiers CSS. Cela semble plus naturel et j'ai l'avantage supplémentaire de tous les outils auxquels je suis habitué. En ce moment, je ne peux pas imaginer un scénario où je reviendrais.

En plus d'économiser quelques octets de code, je n'ai pas vu beaucoup d'avantages à ajouter des styles pour la plupart des choses via JSON. Peut-être que cela changera à l'avenir, et je serai converti. Pour l'instant, je m'en tiens principalement au CSS.

Autre retour : une couche PHP

Je l'ai déjà dit, mais cela mérite d'être répété. Nous avons besoin d'une couche PHP pour ce système de configuration theme.json . Il y a actuellement un ticket ouvert pour résoudre ce problème.

Il y a deux avantages principaux à un tel système. Avoir une API PHP pour reconstituer la configuration semblera beaucoup plus naturel pour les développeurs de thèmes traditionnels. Je le considère comme un peu une branche d'olivier, une preuve de bonne foi que les développeurs principaux / Gutenberg reconnaissent que de nombreux auteurs de thèmes auront plus de facilité à se familiariser avec les fonctionnalités FSE via un langage de programmation familier.

Le deuxième avantage est qu'il existe un nombre incalculable d'idées de plugins pour étendre les styles globaux, l'édition de sites, etc. s'il existe un moyen simple de se connecter au système JSON de thème et d'écraser les choses. Un simple crochet de filtre rendrait cela indolore.