Les thèmes basés sur des blocs ne sont pas compliqués. Leur structure est presque suffisamment simple pour que les développeurs n’aient probablement pas besoin d’un outil pour générer un thème vide. Cependant, pour ceux qui ne connaissent pas la façon dont les thèmes sont construits pour la prochaine fonctionnalité d’édition de site complet (FSE), un passe-partout est un bon point de départ.

le Expériences thématiques le référentiel a maintenant un nouveau Thème vide. Parallèlement, il s’agit d’un outil de ligne de commande pour générer une copie de ce thème avec un nom, un auteur et un URI personnalisés.

L’idée n’est pas nouvelle. Il existe des tonnes de tels outils pour générer un thème à l’état sauvage. Cependant, il est temps pour de nouveaux outils qui se concentrent sur la thématisation par blocs.

Pour les auteurs de thèmes qui souhaitent générer un nouveau thème basé sur des blocs, ils doivent cloner une copie du référentiel des expériences de thème. Accédez ensuite à ce dossier via leur outil de ligne de commande et tapez la commande suivante:

php new-empty-theme.php

À partir de là, il suffit de répondre à quelques questions et de laisser l’outil faire le travail de création d’un nouveau dossier de thème.

Creuser dans le thème généré

Le thème généré n’est pas grand-chose à regarder. Cependant, c’est un thème qui fonctionne dans le nouveau système d’édition de site complet. Après l’activation, les auteurs de thèmes peuvent commencer à bricoler le thème via l’écran de l’éditeur de site (nécessite le plugin Gutenberg).

Thème vide généré dans la fonction Site Editor du plugin WordPress Gutenberg.
Thème généré dans l’éditeur de site.

Il y a une exception à ce que ce soit un travail thème. Le chargement de la partie du modèle d’en-tête est actuellement interrompu. Bien sûr je a ouvert un ticket pour ce problème, qui devrait être facile à résoudre pour l’équipe de développement.

La structure des fichiers et des dossiers est mince par rapport aux thèmes traditionnels. Il contient le strict nécessaire pour qu’un thème soit opérationnel dans l’éditeur de site. Les fichiers et dossiers suivants sont inclus:

  • /assets
    alignments-front.css
  • /block-template-parts
    header.html
  • /block-templates
    index.html
    singular.html
  • experimental-theme.json
  • functions.php
  • index.php
  • readme.md
  • style.css

Même ceux-ci seront probablement réduits à l’avenir. le experimental-theme.json le fichier sera finalement renommé en theme.json.

Le courant alignments-front.css c’est près de 80 lignes de code standard pour gérer les différents alignements de blocs. Il n’est pas nécessaire que chaque auteur de thème recrée tout ce code, ce qui ne devrait pas beaucoup changer entre les thèmes. C’est pourquoi il existe un ticket ouvert pour Gutenberg fournir des styles d’alignement sur l’extrémité avant. Les auteurs de thèmes pourront l’écraser. Cependant, moins les auteurs de thèmes de code doivent affronter de fichiers et de lignes, mieux c’est.

Le standard index.php le modèle est vide. Cela ne sera plus utile pour créer des thèmes maintenant que les modèles basés sur des blocs sont stockés dans le /block-templates et /block-template-parts Dossiers. style.css ne contient que les informations sur le thème. Les thèmes FSE utiliseront principalement theme.json pour configurer les styles par défaut.

Dans les mois et années à venir, les auteurs de thèmes travailleront principalement dans le theme.json fichier et bloquer les dossiers de modèles. Le jury ne se demande toujours pas si l’écosystème thématisé acceptera volontiers ce changement. En même temps, il est rafraîchissant de voir le démêlage du développement du thème. Le thème traditionnel d’aujourd’hui a créé des bases de code gigantesques dans le but de suivre les fonctionnalités souhaitées par les utilisateurs. Un changement dans la façon dont les développeurs créent des thèmes était inévitable et nécessaire.

Mon seul choix avec le thème généré est l’inclusion de la fonction de configuration de thème enfichable dans le functions.php file, qui est en quelque sorte devenu un pilier des thèmes développés au fil des ans. Il existe des API pour activer ou désactiver tout dans de telles fonctions de configuration, et il n’y a aucune raison pour que les thèmes enfants les écrasent en gros.

Si les choses se passent comme prévu, même la fonction de configuration de thème standard peut être sur le billot. Ces fonctions sont généralement une liste d’appels à add_theme_support(). Le plan à long terme est que les fonctionnalités actuelles prises en charge par les thèmes soient activées par défaut pour les thèmes basés sur des blocs ou configurables via le theme.json fichier.


Source link