Il y a quelques jours, je suis tombé sur une petite bibliothèque de blocs. Comme toujours, j’étais intéressé de voir ce que ce nouveau plugin a apporté à la table. Cela me surprendrait-il avec un blocage qui n’a jamais été fait auparavant ? Cela présenterait-il une nouvelle approche de certaines vieilles idées ? Ou s’agirait-il du même ancien ensemble de blocs que tous les autres ensembles de blocs ? Indépendamment de ce qu’il offrait, j’étais excité de l’essayer tout de même.
En cliquant sur la description pour en savoir plus, j’ai été immédiatement déçu. Le plugin indiquait spécifiquement qu’il avait été conçu pour un seul thème. Je ne pouvais pas l’utiliser avec mon thème préféré.
Ce n’était pas la première fois que je rencontrais ce problème. D’autres auteurs de thèmes ont construit leurs propres ensembles de blocs dans le passé. Le plugin n’apportait rien de particulièrement nouveau à la communauté WordPress. Il y avait moins d’une poignée de blocs qui avaient déjà été faits auparavant dans de nombreux autres plugins.
Le problème était que cela semblait trop familier.
Au fil des ans, la communauté WordPress a créé un ensemble de règles non écrites concernant ce qui appartient à un thème par rapport à ce qui appartient à un plugin. Les types de publication personnalisés, les taxonomies et les codes abrégés sont territoire du plugin. Dans une certaine mesure, les widgets devraient également être exclusifs aux plugins. Cependant, en raison de la façon dont ils sont gérés sous le capot, il y avait toujours un argument selon lequel il était acceptable que les thèmes les enregistrent.
Cet argument thème vs plugin dure depuis au moins une décennie. En raison du fonctionnement des thèmes, de tels arguments ont été une bataille perdue d’avance. Sauf dans quelques cas extrêmes, les thèmes peuvent faire tout ce qu’un plugin peut faire. Cependant, il a toujours été censé y avoir une distinction nette entre les deux. Les thèmes étaient destinés à gérer la conception frontale d’un site Web. Les plugins étaient pour tout le reste.
Aujourd’hui, le projet WordPress et son système de blocs progressent vers la consolidation de cette distinction.
En raison de l’héritage de WordPress d’avoir diverses parties qui ne s’emboîtaient pas tout à fait dans le passé, il a créé une culture de développeurs créant des solutions internes. Presque toutes les grandes sociétés de développement de thèmes ont leurs propres plugins pour surmonter les lacunes de la plate-forme. La majeure partie du blâme pour cela incombe au projet WordPress. Cependant, le passage du projet aux blocs crée un système standardisé qui gère tout, d’un paragraphe au conteneur global du site. Avec la normalisation à tous les niveaux, il y aura de moins en moins besoin de ces solutions personnalisées de chaque entreprise thématique.
Le système de blocs a tracé une ligne claire dans le sable. Il a supprimé le besoin de codes courts – un bon débarras – et éliminera bientôt les widgets. Les blocs devraient mettre ces vieilles questions au lit.
Pour plus de clarté, il y a peu de différence entre regrouper des blocs avec un thème et créer un plugin séparé qui ne fonctionne qu’avec un thème spécifique. Le résultat est le même. Un tel plugin empêcherait un utilisateur de s’en tenir à ce thème s’il s’appuyait du tout sur le plugin. Peu de gens conservent indéfiniment le même design frontal.
Le but est de permettre aux utilisateurs de changer de thème à volonté tout en ayant accès à leur contenu et à leurs blocs.
Ces plugins de blocs spécifiques à un thème pensent aux blocs de la mauvaise manière. Lorsqu’un utilisateur installe un plugin de bloc, on s’attend à ce qu’il puisse utiliser ces blocs quel que soit leur thème.
La solution pour les thèmes est d’utiliser le bloc motifs ou modes. Supposons que vous vouliez créer un curseur ou un carrousel en tant qu’auteur de thème. Il existe plusieurs solutions pour cela. La première et la plus simple consiste simplement à recommander un plugin aux utilisateurs ou à créer votre propre plugin qui fonctionne avec n’importe quel thème. Vous pouvez également facilement ajouter un style de curseur pour le bloc Galerie. Lorsque l’utilisateur le sélectionne, il transforme la galerie en un curseur.
Ou, supposons que votre thème doit offrir une grande section de héros avec un bouton d’appel à l’action. Un bloc personnalisé n’est pas nécessaire dans cette situation. Les auteurs de thèmes peuvent presque exclusivement le faire en créant un modèle personnalisé avec des blocs existants.
La solution n’est pas de regrouper le bloc dans le thème ou de créer un plugin qui ne fonctionne qu’avec ce thème.
La beauté du système de blocs est que la plupart des pièces sont déjà en place et qu’elles peuvent être réarrangées, regroupées et stylisées de manière illimitée.
Aujourd’hui, il existe des centaines de plugins spécifiques à un thème. Cela s’explique en partie par le fait que les themers travaillaient autour des directives de révision de thème WordPress.org. Cela s’explique en partie par le fait que certains développeurs n’ont pas pensé de manière suffisamment créative aux solutions. Mais la plus grande partie est due au fait que WordPress n’a pas standardisé la manière de créer des éléments sur l’ensemble de la plate-forme. Une grande partie de cela a changé et continuera de changer à mesure que l’édition du site complet franchira l’horizon en 2021. Il y aura des chemins clairs pour les thèmes et les plugins.
Cependant, si les entreprises thématiques continuent de créer des blocs spécifiques à un thème, nous ne faisons que traîner le bagage que le système de blocs est censé laisser derrière nous.
Comme ça:
Comme Chargement…