La ronde #8 du programme de sensibilisation Full Site Editing (FSE) a commencé hier. Au lieu de l’appel centré sur l’utilisateur pour tester les fonctionnalités de l’interface utilisateur, la responsable du programme, Anne McCarthy, demande aux volontaires de se plonger dans le code. La nouvelle aventure consiste à tester les fichiers theme.json.
Le twist risque de limiter le vivier de bénévoles habituels. Cependant, cela pourrait l’ouvrir à un public qui était peut-être resté en marge des tests précédents : les développeurs de thèmes.
Avant de sauter la tête la première sur les fichiers JSON du thème, nous devrions probablement tous nous retrouver sur la même page.
J’ai appelé theme.json le point de basculement entre l’ancien WordPress et le nouveau WordPress. Lorsque la version 5.0 de la plate-forme principale a été lancée fin 2018, il s’agissait d’un pas en avant révolutionnaire, mais pas en surface. Un nouvel éditeur n’est qu’un nouvel éditeur. Certains vont adorer ; d’autres le détesteront. Et, c’était plus souvent maladroit qu’autrement. Pour la plupart, WordPress était toujours WordPress.
Le logiciel de base devait subir un bouleversement. Les nouvelles technologies non seulement démocratisaient l’édition à leur manière, mais elles apportaient également ce même concept à la conception.
L’introduction de blocs était simplement fondamentale. Le nouvel éditeur était un outil imparfait, donnant souvent l’impression que la cheville ronde proverbiale était enfoncée dans un trou carré.
La seule façon de vivre la vision initiale du projet Gutenberg était de continuer à combler le fossé entre ce que l’utilisateur voit dans l’administrateur et ce qui est affiché sur le front-end. C’est à cela que sert le fichier theme.json. C’est un traducteur qui permet aux utilisateurs, aux thèmes et à WordPress de parler tous la même langue.
Qu’est-ce que cela signifie exactement?
Du point de vue d’un utilisateur, il voit toutes sortes de contrôles pour changer ses blocs. La couleur, la taille de la police, l’alignement et d’autres options sont des outils qui leur permettent de personnaliser leur contenu.
Personnaliser une carte de profil pour mon chat à l’aide des options de blocage.
Il y a de sérieuses limitations avec ce qui est possible dans le système actuel. Les auteurs de thèmes peuvent enregistrer une poignée d’options. En dehors de cela, les systèmes de thèmes et de blocs peuvent donner l’impression qu’ils sont opposés les uns aux autres pour le contrôle.
C’est là qu’intervient le fichier theme.json. Il permet aux thèmes et à WordPress d’être sur la même page, créant ainsi un système standardisé qui améliore l’expérience utilisateur.
Ce fichier qui réside dans le dossier racine d’un thème donne le pouvoir de configurer des dizaines de préréglages (par exemple, les options de couleur et de police), les propriétés CSS personnalisées et les styles par défaut pour les blocs et les éléments HTML.
Il donne également aux utilisateurs le pouvoir d’activer ou de désactiver des fonctionnalités spécifiques. Par exemple, les développeurs peuvent désactiver la possibilité pour les utilisateurs de définir une taille de police personnalisée, mais donner accès à leur échelle de choix parfaite qui s’adapte au rythme vertical de la conception.
Cependant, il ira au-delà de la simple configuration de blocs dans l’éditeur de contenu. Lorsque le système de styles globaux sera lancé avec l’éditeur de site à l’avenir, les utilisateurs personnaliseront de nombreux préréglages et écraseront les styles de bloc par défaut. Parce que tout le monde parle la même langue, moins de conflits surviennent.
Comme l’a souligné la designer Tammie Lister dans son article pour Ephermeral Themes, Theme.json inspire, les thèmes ont été bloqués. Le logiciel, la communauté, a mis trop de responsabilités sur les épaules des utilisateurs au fil des ans. Ils ont dû innover et construire les systèmes qui auraient dû provenir de WordPress. Non seulement la plate-forme principale devait être renversée, mais le système de conception méritait une refonte.
« Je suis très conscient que dire » premier processus de thème majeur à noyau » depuis des années est tout à fait une déclaration « , a écrit Lister. « Theme.json pour moi, c’est ça. Je ne dis pas cela en ignorant les itérations et les améliorations, WordPress est un projet qui coule avec l’énergie de celles-ci. Cependant, les thèmes étaient sous assistance respiratoire coincés dans un pays alors que le reste du développement frontal avançait. Ce n’était pas pour certains d’essayer de changer cela, surtout quand ils le faisaient, le moment n’était pas bon et comme cela ne venait pas du noyau, c’était toujours un changement plus difficile.
Il est temps pour une nouvelle ère de conception frontale. Mais, d’abord, nous devons tester.
Thème de test JSON
Fichier theme.json du monde réel.
Plus j’avançais dans cet appel à tests, plus je réalisais que cela ne me convenait pas. Au cours des deux derniers mois, j’ai déjà travaillé à partir du fichier theme.json. Je connais la plupart des petites bizarreries et je vois les lacunes. Les astuces pour travailler avec cela me semblent une seconde nature.
J’ai effectué toutes les étapes débutants et intermédiaires des dizaines et des dizaines de fois. J’ai déjà déposé des tickets pour tous les problèmes que j’ai rencontrés. Ou, quelqu’un d’autre m’a déjà battu au poing.
Ces étapes de cette série de tests ont besoin d’un regard neuf. Les meilleurs commentaires viendront des auteurs de thèmes qui verront les problèmes à travers une paire de lentilles différentes. Si vous êtes dans ce groupe, il n’y a pas de temps comme le présent pour tester et donner votre avis.
L’étape avancée appelle à recréer un thème classique à l’aide de theme.json. Il est préférable de s’en tenir à quelque chose de simple. Sinon, vous pourriez envisager une expérience de plusieurs semaines. McCarthy recommande Twenty Twenty ou Storefront. J’ai déjà joué cette chanson et dansé aussi. Mon projet de test était un vieux thème que j’ai vidé et transformé en thème de bloc.
Il y a une question primordiale sur laquelle je reviens sans cesse. C’est que les auteurs de thèmes doivent travailler à partir d’un fichier JSON.
Je comprends le « pourquoi » derrière l’utilisation de JSON. C’est un format universel que l’on peut faire passer de JavaScript à PHP. Les API tierces peuvent le comprendre.
Cependant, je suis actuellement assis sur plus de 900 lignes de code dans mon theme.json. J’ai entendu quelques autres auteurs de thèmes qui ont fait un travail approfondi avec des nombres similaires. Je m’attends à ce qu’il ne fasse que grandir.
Le « nombre de lignes » n’est pas nécessairement une mesure où un total spécifique est un point de division entre « bon » ou « mauvais ». Le problème est que les commentaires ne sont pas autorisés dans les fichiers JSON. L’une des pierres angulaires d’un développement solide est la documentation du code. Sauter la documentation de quelques dizaines de lignes n’est pas si mal. Cependant, lorsque vous dépassez 900, les choses peuvent devenir incontrôlables.
De plus, à un moment donné, vous commencez à vouloir diviser les morceaux en leurs propres groupes. Cette quantité de code demande une meilleure organisation.
La chose qui manque actuellement est une couche PHP à utiliser par les auteurs de thèmes. N’oubliez pas que JSON est un format universel. Il est facile de convertir PHP en JSON et vice-versa. La création de cette couche pour les auteurs de thèmes accomplirait deux choses :
- Ils peuvent organiser ce qui sera probablement des milliers de lignes de code
- La transition vers le nouveau système sera plus facile
Ce dernier point est probablement le plus important. PHP est le langage de la thématisation depuis que la thématisation existe. Les développeurs le savent et l’utilisent à l’aise, et WordPress devrait les rencontrer au milieu. Si nous comblons les lacunes, c’est celle qui doit être comblée avant que davantage de possibilités de configuration ne soient ajoutées et que les fichiers theme.json montent en flèche dans des mastodontes lourds de 5 000 lignes.
Comme ça :
J’aime le chargement.