Et si les développeurs WordPress vivaient dans un monde où nous pourrions créer des modèles basés sur PHP qui produiraient des données sur le front-end et géreraient les champs modifiables via l’éditeur de blocs ? Ou, nous avions un système où nous pouvions créer des blocs sans étape de construction ?
Bien qu’il existe de nombreuses raisons pour lesquelles l’éditeur WordPress moderne ne convient pas encore à tout le monde, une pierre d’achoppement a été la création de composants d’interface personnalisés. L’écosystème a une longue histoire de création de solutions sur mesure pour les clients utilisant PHP. Il s’agit pour la plupart de boîtes méta personnalisées et de champs de formulaire dans l’écran de l’éditeur classique. Lorsque WordPress 5.0 a été lancé avec son éditeur de blocs, il a bouleversé le monde, laissant souvent les agences et les indépendants sans moyen d’aller de l’avant sans consacrer d’énormes ressources à l’apprentissage de React pour créer des blocs ou interagir avec le nouvel écran d’édition.
La solution? Respectez ce que vous savez. C’était moins cher et semblait déjà bien faire le travail.
Alors que nous parlons de la fenêtre de support pour l’éditeur classique plugin, le projet WordPress a besoin de personnes pour fournir des outils à ce segment de l’écosystème s’il envisage un jour de les emmener avec lui. Des solutions telles que ACF Pro et Genesis Custom Blocks ont comblé certaines des lacunes techniques. Cependant, l’expérience utilisateur peut être médiocre lors de l’utilisation du rendu côté serveur dans l’éditeur de blocs. Cette méthode fonctionne bien pour certains types de blocs, mais pas pour tous. Nous devons faire un pas de plus.
Mark Jaquith, développeur principal de WordPress, a partagé quelques questions d’Helen Hou-Sandí, une autre développeur principal, autour de cette idée et d’un concept de base sur à quoi cela pourrait ressembler:
Hou-Sandí a suivi avec un article détaillé sur le concept, mais elle a souligné qu’il ne s’agit que d’une phase exploratoire.
« L’éditeur de blocs WordPress basé sur React (parfois appelé Gutenberg) est un outil puissant pour l’édition WYSIWYG qui continue de se situer quelque part entre un ralentisseur et un barrage routier pour les développeurs WordPress de longue date qui ont historiquement été plus centrés sur PHP ”, a-t-elle écrit dans le post.
Si vous êtes un développeur WordPress, il y a de fortes chances que vous pensiez, Oui, j’ai heurté quelques-uns de ces ralentisseurs et je me suis écrasé plusieurs fois contre ce barrage routier. C’est une nouvelle peu probable pour vous. Ce qui pourrait commencer à gagner les cœurs et les esprits, c’est de reconnaître et de comprendre où réside une grande partie du problème pour le développement personnalisé.
« En tirant parti des parties familières des modèles basés sur PHP et en créant un pont qui démontre la puissance de React lorsqu’il est combiné avec le balisage et le style déjà effectués pour le front-end, nous pouvons dédupliquer le code, aider à démystifier le rôle critique de JavaScript dans la modernisation de WordPress et servir de rampe d’accès aux développeurs centrés sur PHP pour créer des expériences d’édition de prévisualisation en direct 1:1 convaincantes et agréables », a écrit Hou-Sandí.
Tout cela se résume essentiellement au processus d’écriture d’un code de modèle qui fonctionne à la fois sur le front-end et l’éditeur sans toutes les complexités de la configuration et des blocs de construction actuels. C’est une perspective passionnante, comme en témoignent les nombreux likes, retweets et réponses au tweet de Jaquith.
Hou-Sandí a souligné que le processus de réflexion actuel consiste principalement à faciliter la transition pour les solutions de blocage client personnalisées et pas nécessairement pour WordPress lui-même. Cependant, cela ne signifie pas que cette solution ou une solution similaire pourrait ne pas faire partie de l’avenir de la plate-forme principale.
Chef de projet Gutenberg Matías Ventura a répondu à Ben Gillbanks dans le même fil Twitter que c’était définitivement quelque chose qu’ils envisageaient. « D’un point de vue central, nous devions nous assurer que les primitives et l’interactivité ne sont pas compromises, mais il n’y a aucune raison pour que cela implique une chaîne d’outils JS complète pour des blocs plus simples. Il est important d’abaisser la barrière d’entrée.
Comme plusieurs autres, Gillbanks pensait qu’un tel système aurait facilité la transition pour les développeurs centrés sur PHP dès le début. Cependant, le projet n’était pas prêt pour cela à l’époque, selon Ventura.
« Il est difficile de faire quelque chose comme ça depuis le début jusqu’à ce que les API cibles de compilation soient suffisamment robustes », a-t-il tweeté. « Nous arrivons à un point où de nombreuses propriétés interactives sont regroupées en primitives et composants, ce qui rend une approche de modélisation plus attrayante. »
Le développeur d’automattic Riad Benguella a partagé une solution similaire la semaine dernière, lançant le Projet en blocs sur GitHub. Avec son approche, les développeurs utilisent le block.json pour créer le modèle ou le composant de vue et exécutez-le via une simple étape de construction pour générer le code du bloc.
Bien qu’il ne soit pas trop tôt pour espérer et rêver, il est peut-être un peu prématuré de commencer sérieusement à se demander si de tels outils atterriront dans le cœur de WordPress. Cependant, voir certains des principaux développeurs WordPress et Gutenberg parler au moins ouvertement de solutions mérite une attention particulière.