WordPress 5.8 introduit un système d’opt-in pour les thèmes pour configurer les paramètres de bloc, les styles, les modèles, etc. Cela se fait à travers un nouveau theme.json fichier que les auteurs peuvent mettre à la racine de leurs dossiers thématiques. Anne McCarthy, responsable du programme de sensibilisation FSE, a annoncé une enquête 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 qu’il pourrait être judicieux d’inclure dans Core à l’avenir », a-t-elle écrit dans l’annonce.
L’enquête est ouverte à tous les auteurs thématiques qui ont utilisé theme.json, leur donnant une chance 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 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 des theme.json.
Ce qui suit sont mes réponses aux questions de l’enquête – enfin, la version rangée.
Noter: Il s’agit d’un article centré sur les développeurs qui pourrait ne pas plaire universellement à 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 en utilisant theme.json. Il propose quatre choix (et une option « autre ») :
- J’ai construit et lancé des thèmes de blocs.
- J’ai expérimenté avec des thèmes de blocs de construction.
- j’ai exploré en utilisant
theme.jsonavec un thème classique. - J’ai utilisé un thème de bloc, mais je n’en ai pas encore construit un.
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 sites personnels simples que je maintiens déjà gratuitement — Honnêtement, je dois commencer à charger. Je travaille également sur un thème que j’espère publier publiquement.
Comment ça a commencé et comment ça se passe
La deuxième question demande comment on a commencé avec les thèmes de blocs et theme.json. Les choix sont entre bifurquer un thème existant, en utilisant le Thème vide, ou repartir 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 forger un thème sur lequel j’ai travaillé pour la dernière fois en 2019.
Je prévois de publier ce nouveau thème gratuitement à un moment donné. J’attends principalement ce qui suit :
- Développement de blocs de navigation pour s’installer
- Le bloc Post Author à diviser en blocs plus petits
- Un ensemble robuste de blocs liés aux commentaires
- Publier le bloc Image en vedette pour avoir une option de taille
Je pense que je pourrais de manière réaliste publier une version bêta à vos risques et périls de mon thème aujourd’hui si ces éléments étaient traités.
Modèles et parties de modèle
L’enquête a demandé quels modèles et parties de modèle les thèmes incluent toujours dans leurs thèmes basés sur des blocs. Il y avait un champ de commentaire de forme libre — marche sur la caisse à 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 une époque plus simple 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 que j’ai construit un thème traditionnel basé sur PHP avec plus d’un modèle de premier niveau : index.php. Les pièces dynamiques ont toujours été les entrailles de la chose, qui sont des pièces de gabarit. 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 articles, il lui suffirait de créer un header-page.php ou alors header-post.php modèle dans les thèmes traditionnels. Cependant, comme le système de modèles de blocs est différent, ils doivent maintenant créer deux modèles de niveau supérieur, single.html (poste) et page.html, pour accomplir la même chose.
C’est une « mauvaise chose » car les auteurs de thèmes doivent dupliquer tout le reste du code dans chacun des modèles de niveau supérieur. Il n’y a aucun moyen de charger contextuellement différentes parties de modèle.
Pour répondre à la question : j’utilise presque tous les modèles de haut niveau possibles par nécessité.
J’ai également répondu à la deuxième partie de la question et énuméré mes parties de modèle les plus couramment utilisées (ventilées par hiérarchie):
- Entête
- Contenu
– Boucle
– Barre latérale - Bas de page
Le content-*.html et loop-*.html les parties du modèle sont celles qui présentent le plus de variations.
Définition des couleurs
La section suivante de l’enquête demande comment les auteurs de thèmes définissent leurs limaces de palette de couleurs dans theme.json. Croyez-le ou non, nom des 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 « arrière-plan » et « premier plan ».
Morten Rand Hendriksen a ouvert un ticket en 2018 pour normaliser un schéma de nommage 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 limaces 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. Basculez vers 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 beaucoup à celui du framework CSS Tailwind système d’ombrage. À la place 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 avoir un theme.json Essentiel pour ceux qui voudront peut-être l’essayer.
Autres paramètres JSON du thème
En dehors des couleurs et de la typographie, l’enquête demande quels autres paramètres les auteurs de thèmes ont utilisé. 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 actuellement pas de préréglage est l’espacement global. La plupart des auteurs de thèmes utilisent une valeur unique pour la plupart des marges verticales (espaces blancs entre les blocs et les éléments). Il est également souvent utilisé pour le remplissage vertical et horizontal par défaut.
Je ne sais pas si je veux un préréglage car je ne sais pas comment WordPress l’utilisera. C’est quelque chose qui d’autres ont demandé, et il est presque omniprésent dans l’utilisation. Définir un système entier autour de celui-ci 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 leur theme.json des dossiers. 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, qui permettent 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 en JSON, essentiellement ce dont nous parlons, 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 répartie 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 reculerais.
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 un converti. Pour l’instant, je m’en tiens principalement au CSS.
Autres commentaires : une couche PHP
j’ai l’a dit avant, mais cela mérite d’être répété. Nous avons besoin d’une couche PHP pour cela theme.json système de configuration. Il existe actuellement un ticket ouvert pour remédier à cela.
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 un peu comme un rameau d’olivier, une preuve de bonne foi que les développeurs core/Gutenberg reconnaissent que de nombreux auteurs de thèmes auront plus de facilité à intégrer les fonctionnalités de 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 site, etc. Un simple crochet de filtre rendrait cela indolore.
Comme ça:
Comme Chargement…