Reconnaissons que développer pour WordPress est bizarre en ce moment. Que vous soyez nouveau sur WordPress ou que vous ayez travaillé avec lui pendant des éternités, l'introduction des fonctionnalités "Full-Site Editing" (FSE), y compris le Éditeur de blocs (WordPress 5.0) et le Editeur du site (WordPress 5.9), ont bouleversé la façon traditionnelle dont nous construisons les thèmes et plugins WordPress.
Même si cela fait cinq ans que nous avons rencontré l'éditeur de blocs pour la première fois, développer pour lui est difficile car la documentation manque ou est obsolète. C'est plus une déclaration sur la vitesse à laquelle les fonctionnalités FSE évoluent, quelque chose Geoff a déploré dans un post récent.
Exemple : En 2018, un série d'introduction sur le développement de Gutenberg a été publié ici sur CSS-tricks. Les temps ont changé depuis lors et, bien que ce style de développement fonctionne toujours, il est pas recommandé plus (d'ailleurs, le create-guten-block le projet sur lequel il est basé n'est également plus maintenu).
Dans cet article, j'ai l'intention de vous aider à démarrer avec le développement de blocs WordPress d'une manière qui suit la méthodologie actuelle. Donc, oui, les choses pourraient très bien changer après cette publication. Mais je vais essayer de me concentrer dessus d'une manière qui, espérons-le, capture l'essence du développement de blocs, car même si les outils peuvent évoluer avec le temps, les idées de base resteront probablement les mêmes.
L'éditeur Gutenberg : (1) l'outil d'insertion de blocs, (2) la zone de contenu et (3) la barre latérale des paramètres Crédit: Manuel de l'éditeur de blocs WordPress
Que sont les blocs WordPress, exactement ?
Commençons par dissiper une certaine confusion avec ce que nous entendons par des termes tels que blocs. Tout le développement de ces fonctionnalités menant à WordPress 5.0 portait le nom de code «Gutenberg” — vous savez, l'inventeur du presse d'imprimerie.
Depuis lors, "Gutenberg" a été utilisé pour décrire tout ce qui concerne les blocs, y compris l'éditeur de blocs et l'éditeur de site, il est donc devenu alambiqué dans la mesure où certaines personnes méprise le nom. Pour couronner le tout, il y a un Plugin Gutenberg où les fonctionnalités expérimentales sont testées pour une éventuelle inclusion. Et si vous pensez que le fait d'appeler tout cela "l'édition complète du site" résoudrait le problème, il y a aussi des soucis avec ça.
Ainsi, lorsque nous parlons de "blocs" dans cet article, nous entendons des composants permettant de créer du contenu dans l'éditeur de blocs WordPress. Les blocs sont insérés dans une page ou une publication et fournissent la structure d'un type de contenu particulier. WordPress est livré avec une poignée de blocs «de base» pour les types de contenu courants, tels que Paragraphe, Liste, Image, Vidéo et Audio, pour en nommer quelques-uns.
Outre ces blocs de base, nous pouvons également créer des blocs personnalisés. C'est en quoi consiste le développement de blocs WordPress (il existe également des blocs de filtrage pour modifier leur fonctionnalité, mais vous n'en aurez probablement pas besoin pour l'instant).
Que font les blocs
Avant de plonger dans la création de blocs, nous devons d'abord avoir une idée de la façon dont les blocs fonctionnent en interne. Cela nous évitera certainement une tonne de frustration plus tard.
La façon dont j'aime penser à un bloc est plutôt abstraite : pour moi, un bloc est une entité, avec certaines propriétés (appelées attributs), qui représente un certain contenu. Je sais que cela semble assez vague, mais restez avec moi. Un bloc se manifeste essentiellement de deux manières : sous la forme d'une interface graphique dans l'éditeur de blocs ou sous la forme d'un bloc de données dans la base de données.
Lorsque vous ouvrez l'éditeur de blocs WordPress et insérez un bloc, disons un bloc Pullquote, vous obtenez une belle interface. Vous pouvez cliquer sur cette interface et modifier le texte cité. Le panneau Paramètres sur le côté droit de l'interface utilisateur de l'éditeur de blocs fournit des options pour ajuster le texte et définir l'apparence du bloc.
Lorsque vous avez terminé de créer votre pullquote fantaisiste et que vous avez cliqué sur Publier, l'intégralité de la publication est stockée dans la base de données du wp_posts table. Ce n'est pas nouveau à cause de Gutenberg. C'est ainsi que les choses ont toujours fonctionné - WordPress stocke le contenu de publication dans une table désignée dans la base de données. Mais ce qui est nouveau c'est que une représentation du bloc Pullquote fait partie du contenu qui est stocké dans post_content domaine de wp_posts tableau.
A quoi ressemble cette représentation ? Regarde:
It is not an exaggeration to say that peas can be described as nothing less than perfect spheres of joy.
The Encyclopedia of world peas
Ressemble à du HTML simple, n'est-ce pas ? ! Ceci, dans le jargon technique, est le bloc "sérialisé". Remarquez les données JSON dans le commentaire HTML, "textAlign": "right". C'est un attribut - une propriété associée au bloc.
Disons que vous fermez l'éditeur de blocs, puis que vous l'ouvrez à nouveau un peu plus tard. Le contenu de la page pertinente post_content champ est récupéré par l'éditeur de blocs. L'éditeur analyse ensuite le contenu récupéré, et partout où il rencontre ceci :
...
… il se dit à haute voix :
OK, cela me semble être un bloc Pullquote. Hmm.. il a aussi un attribut… J'ai un fichier JavaScript qui m'indique comment construire l'interface graphique d'un bloc Pullquote dans l'éditeur à partir de ses attributs. Je devrais le faire maintenant pour rendre ce bloc dans toute sa splendeur.
En tant que développeur de blocs, votre travail consiste à :
Dites à WordPress que vous souhaitez enregistrer un type de bloc spécifique, avec des détails.
Fournissez le fichier JavaScript à l'éditeur de blocs qui l'aidera à afficher le bloc dans l'éditeur tout en le "sérialisant" pour l'enregistrer dans la base de données.
Fournissez toutes les ressources supplémentaires dont le bloc a besoin pour son bon fonctionnement, par exemple les styles et les polices.
Une chose à noter est que toute cette conversion de données sérialisées en interface graphique - et vice versa - n'a lieu que dans l'éditeur de blocs. Sur le front-end, le contenu est affiché exactement tel qu'il est stocké. Par conséquent, dans un sens, les blocs sont une façon élégante de mettre des données dans la base de données.
J'espère que cela vous donne une certaine clarté sur le fonctionnement d'un bloc.
Premiers pas avec le développement de blocs WordPress
Les blocs ne sont que des plugins
Les blocs ne sont que des plugins. Eh bien, techniquement, vous vous mettre des blocs dans les thèmes et vous vous mettre plusieurs blocs dans un plugin. Mais, le plus souvent, si vous voulez créer un bloc, vous allez créer un plugin. Donc, si vous avez déjà créé un plugin WordPress, vous êtes déjà sur le point de maîtriser la création d'un bloc WordPress.
Mais supposons un instant que vous n'ayez jamais configuré de plugin WordPress, encore moins un bloc. Par où commencer ?
Mise en place d'un bloc
Nous avons couvert ce que sont les blocs. Commençons à mettre les choses en place pour en faire un.
Assurez-vous que Node est installé
Cela vous donnera accès à npm et les npx commandes, où npm installe les dépendances de votre bloc et aide à compiler des choses, tandis que npx exécute des commandes sur des packages sans les installer. Si vous êtes sur macOS, vous avez probablement déjà Node et pouvez utiliser nvm pour mettre à jour les versions. Si vous êtes sous Windows, vous devrez télécharger et installer Node.
Créer un dossier de projet
Maintenant, vous pouvez rencontrer d'autres didacticiels qui sautent directement dans la ligne de commande et vous demandent d'installer un package appelé @wordpress/create-block. Ce package est génial car il crée un dossier de projet entièrement formé avec toutes les dépendances et les outils dont vous avez besoin pour commencer à développer.
Personnellement, je vais dans cette voie lors de la configuration de mes propres blocs, mais faites-moi plaisir un instant parce que je veux passer à travers les éléments d'opinion qu'il introduit et me concentrer uniquement sur les éléments requis pour comprendre l'environnement de développement de base.
Ce sont les fichiers que je voudrais appeler spécifiquement:
readme.txt: C'est un peu comme la face avant du répertoire du plugin, généralement utilisé pour décrire le plugin et fournir des détails supplémentaires sur l'utilisation et l'installation. Si vous soumettez votre bloc au WordPress Directory Plugin, ce fichier permet de remplir la page du plugin. Si vous envisagez de créer un référentiel GitHub pour votre plugin de bloc, vous pouvez également envisager un README.md fichier avec les mêmes informations afin qu'il s'affiche bien ici.
package.json: Ceci définit les packages Node qui sont requis pour le développement. Nous l'ouvrirons quand nous arriverons à l'installation. Dans le développement de plugins WordPress classiques, vous êtes peut-être habitué à travailler avec Composer et un composer.json fichier à la place. C'est l'équivalent de ça.
plugin.php: C'est le fichier principal du plugin et, oui, c'est du PHP classique ! Nous allons mettre notre en-tête de plugin et nos métadonnées ici et les utiliser pour enregistrer le plugin.
En plus de ces fichiers, il y a aussi le src répertoire, qui est censé contenir le code source de notre bloc.
Avoir ces fichiers et le src répertoire est tout ce dont vous avez besoin pour commencer. De ce groupe, notez que nous n'avons techniquement besoin que d'un seul fichier (plugin.php) pour créer le plugin. Les autres fournissent des informations ou sont utilisées pour gérer l'environnement de développement.
Le susmentionné @wordpress/create-block package échafaude ces fichiers (et plus) pour nous. Vous pouvez le considérer comme un outil d'automatisation au lieu d'une nécessité. Quoi qu'il en soit, cela facilite le travail, vous pouvez donc prendre la liberté d'échafauder un bloc avec en exécutant:
npx @wordpress/create-block
Installer les dépendances de bloc
En supposant que les trois fichiers mentionnés dans la section précédente soient prêts, il est temps d'installer les dépendances. Tout d'abord, nous devons spécifier les dépendances dont nous aurons besoin. Nous le faisons en éditant le package.json. Lors de l'utilisation du @wordpress/create-block utilitaire, ce qui suit est généré pour nous (commentaires ajoutés ; JSON ne prend pas en charge les commentaires, supprimez donc les commentaires si vous copiez le code) :
{
// Defines the name of the project
"name": "block-example",
// Sets the project version number using semantic versioning
"version": "0.1.0",
// A brief description of the project
"description": "Example block scaffolded with Create Block tool.",
// You could replace this with yourself
"author": "The WordPress Contributors",
// Standard licensing information
"license": "GPL-2.0-or-later",
// Defines the main JavaScript file
"main": "build/index.js",
// Everything we need for building and compiling the plugin during development
"scripts": {
"build": "wp-scripts build",
"format": "wp-scripts format",
"lint:css": "wp-scripts lint-style",
"lint:js": "wp-scripts lint-js",
"packages-update": "wp-scripts packages-update",
"plugin-zip": "wp-scripts plugin-zip",
"start": "wp-scripts start"
},
// Defines which version of the scripts packages are used (24.1.0 at time of writing)
// https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/
"devDependencies": {
"@wordpress/scripts": "^24.1.0"
}
}
Le @wordpress/scripts package est la principale dépendance ici. Comme vous pouvez le voir, c'est un devDependency ce qui signifie qu'il aide au développement. Comment? Il expose la wp-scripts binaire que nous pouvons utiliser pour compiler notre code, à partir du src répertoire vers le build répertoire, entre autres.
Il existe un certain nombre d'autres packages que WordPress maintient à diverses fins. Par exemple, le @wordpress/components paquet fournit plusieurs préfabriqués UI composants électriques pour l'éditeur de blocs WordPress qui peut être utilisé pour créer des expériences utilisateur cohérentes pour votre bloc qui s'alignent sur les normes de conception WordPress.
Vous n'avez pas réellement need pour installer ces packages, même si vous souhaitez les utiliser. C'est parce que ces @wordpress les dépendances ne sont pas regroupées avec votre code de bloc. Au lieu de cela, n'importe quel import instructions faisant référence au code de packages utilitaires - comme @wordpress/components — servent à construire un fichier « assets », lors de la compilation. De plus, ces instructions d'importation sont converties en instructions mappant les importations aux propriétés d'un objet global. Par exemple, import { __ } from "@wordpress/i18n" est converti en une version minifiée de const __ = window.wp.i18n.__. (window.wp.i18n étant un objet dont la disponibilité est garantie dans le périmètre global, une fois i18n fichier de package est mis en file d'attente).
Lors de l'enregistrement du bloc dans le fichier du plugin, le fichier "assets" est implicitement utilisé pour indiquer à WordPress les dépendances du package pour le bloc. Ces dépendances sont automatiquement mises en file d'attente. Tout cela est pris en charge dans les coulisses, à condition que vous utilisiez le scripts forfait. Cela étant dit, vous pouvez toujours choisir d'installer localement des dépendances pour l'achèvement du code et les informations sur les paramètres dans votre package.json fichier:
Maintenant que package.json est configuré, nous devrions pouvoir installer toutes ces dépendances en accédant au dossier du projet dans la ligne de commande et en exécutant npm install.
Premiers pas avec le développement de blocs WordPress
Ajouter l'en-tête du plugin
Si vous venez du développement de plugins WordPress classiques, vous savez probablement que tous les plugins ont un bloc d'informations dans le fichier de plugin principal qui aide WordPress à reconnaître le plugin et à afficher des informations à son sujet sur l'écran Plugins de l'administrateur WordPress.
Voici ce que @wordpress/create-block généré pour moi dans un plugin appelé de manière créative "Hello World":
<?php
/**
* Plugin Name: Block Example
* Description: Example block scaffolded with Create Block tool.
* Requires at least: 5.9
* Requires PHP: 7.0
* Version: 0.1.0
* Author: The WordPress Contributors
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*
* @package create-block
*/
C'est dans le fichier principal du plugin, que vous pouvez appeler comme vous le souhaitez. Vous pourriez l'appeler quelque chose de générique comme index.php or plugin.phpL’ create-block package l'appelle automatiquement tout ce que vous fournissez comme nom de projet lors de son installation. Depuis que j'ai appelé cet exemple "Block Example", le package nous a donné un block-example.php dossier avec tous ces trucs.
Vous allez vouloir changer certains détails, comme vous faire l'auteur et ainsi de suite. Et tout cela n'est pas nécessaire. Si je roulais cela à partir de "zéro", alors cela pourrait ressembler à quelque chose de plus proche de ceci :
<?php
/**
* Plugin Name: Block Example
* Plugin URI: https://css-tricks.com
* Description: An example plugin for learning WordPress block development.
* Version: 1.0.0
* Author: Arjun Singh
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*/
Nous avons déjà examiné les fichiers requis pour notre bloc. Mais si vous utilisez @wordpress/create-block, vous verrez un tas d'autres fichiers dans le dossier du projet.
build/: Ce dossier a reçu les actifs compilés lors du traitement des fichiers pour une utilisation en production.
node_modules: Cela contient toutes les dépendances de développement que nous avons installées lors de l'exécution npm install.
src/: Ce dossier contient le code source du plugin qui est compilé et envoyé au build annuaire. Nous examinerons chacun des fichiers ici dans un instant.
.editorconfig: contient des configurations pour adapter votre éditeur de code à la cohérence du code.
.gitignore: Il s'agit d'un fichier référentiel standard qui identifie les fichiers locaux qui doivent être exclus du suivi du contrôle de version. Ton node_modules devrait certainement être inclus ici.
package-lock.json: Il s'agit d'un fichier généré automatiquement contenant le suivi des mises à jour des packages requis avec lesquels nous avons installé npm install.
Bloquer les métadonnées
je veux creuser dans src répertoire avec vous, mais se concentrera d'abord sur un seul fichier qu'il contient : block.json. Si vous avez utilisé create-block , il est déjà là pour vous ; sinon, allez-y et créez-le. WordPress s'efforce d'en faire le moyen standard et canonique d'enregistrer un bloc en fournissant des métadonnées qui fournissent le contexte WordPress pour à la fois reconnaître le bloc et le rendre dans l'éditeur de blocs.
Voici ce que @wordpress/create-block généré pour moi:
Il y a en fait un tas d'informations différentes nous pouvons inclure ici, mais tout ce qui est réellement requis est name et les title. Une version super minimale pourrait ressembler à ceci :
$schema définit le formatage du schéma utilisé pour valider le contenu du fichier. Cela semble être une chose obligatoire, mais c'est totalement facultatif car cela permet aux éditeurs de code de valider la syntaxe et de fournir d'autres affordances supplémentaires, comme les conseils d'info-bulle et l'auto-complétion.
apiVersion fait référence à quelle version du Bloquer l'API le plugin utilise. Aujourd'hui, la version 2 est la dernière.
name est une chaîne unique requise qui permet d'identifier le plug-in. Remarquez que j'ai préfixé ceci avec css-tricks/ que j'utilise comme espace de noms pour éviter les conflits avec d'autres plugins qui pourraient avoir le même nom. Vous pouvez choisir d'utiliser quelque chose comme vos initiales à la place (par exemple as/block-example).
version est quelque chose WordPress suggère d'utiliser comme mécanisme de contournement du cache lorsque de nouvelles versions sont publiées.
title est l'autre champ obligatoire, et il définit le nom qui est utilisé partout où le plugin est affiché.
category regroupe le bloc avec d'autres blocs et les affiche ensemble dans l'éditeur de blocs. Les catégories existantes actuelles incluent text, media, design, widgets, themeet une embed, et vous pouvez même créer catégories personnalisées.
icon vous permet de choisir quelque chose parmi Bibliothèque de Dashicons pour représenter visuellement votre bloc dans l'éditeur de blocs. j'utilise le format-quote icon](https://developer.wordpress.org/resource/dashicons/#format-quote) puisque nous créons notre propre sorte de pullquote dans cet exemple. C'est bien que nous puissions tirer parti des icônes existantes plutôt que d'avoir à créer les nôtres, bien que ce soit certainement possible.
editorScript est l'endroit où se trouve le fichier JavaScript principal, index.js, des vies.
Enregistrez le bloc
Une dernière chose avant de toucher au code réel, et c'est d'enregistrer le plugin. Nous venons de configurer toutes ces métadonnées et nous avons besoin d'un moyen pour WordPress de les consommer. De cette façon, WordPress sait où trouver tous les actifs du plugin afin qu'ils puissent être mis en file d'attente pour être utilisés dans l'éditeur de blocs.
L'enregistrement du bloc est un processus en deux temps. Nous devons l'enregistrer à la fois en PHP et en JavaScript. Pour le côté PHP, ouvrez le fichier principal du plugin (block-example.php dans ce cas) et ajoutez ce qui suit juste après l'en-tête du plugin :
C'est ce que create-block utilitaire généré pour moi, c'est pourquoi la fonction est nommée ainsi. Nous pouvons utiliser un nom différent. La clé, encore une fois, est d'éviter les conflits avec d'autres plugins, c'est donc une bonne idée d'utiliser votre espace de noms ici pour le rendre aussi unique que possible :
Pourquoi désigne-t-on le build répertoire si le block.json avec toutes les métadonnées de bloc est dans src? C'est parce que notre code doit encore être compilé. La scripts package traite le code des fichiers du src répertoire et place les fichiers compilés utilisés en production dans le répertoire build répertoire, tout en copier leblock.jsonfilet suite à la cure.
Très bien, passons au côté JavaScript de l'enregistrement du bloc. S'ouvrir src/index.js et assurez-vous qu'il ressemble à ceci :
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
Nous entrons dans le monde de React et JSX ! Cela indique à WordPress de :
Importer le registerBlockType module de la @wordpress/blocks paquet.
Importer des métadonnées depuis block.json.
Importer le Edit et les Save composants à partir de leurs fichiers correspondants. Nous mettrons du code dans ces fichiers plus tard.
Enregistrez le bloc et utilisez le Edit et les Save composants pour rendre le bloc et enregistrer son contenu dans la base de données.
Quoi de neuf avec le edit et les save les fonctions? L'une des nuances du développement de blocs WordPress est de différencier le "back-end" du "front-end" et ces fonctions sont utilisées pour rendre le contenu du bloc dans ces contextes, où edit gère le rendu back-end et save écrit le contenu de l'éditeur de blocs dans la base de données pour afficher le contenu sur le front-end du site.
Un test rapide
Nous pouvons faire un travail rapide pour voir notre bloc fonctionner dans l'éditeur de blocs et rendu sur le front-end. Ouvrons index.js à nouveau et utilisez le edit et les save pour renvoyer un contenu de base illustrant leur fonctionnement :
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
const { name } = metadata;
registerBlockType(name, {
edit: () => {
return (
"Hello from the Block Editor"
);
},
save: () => {
return (
"Hello from the front end"
);
}
});
Il s'agit essentiellement d'une version simplifiée du même code que nous avions auparavant, sauf que nous pointons directement vers les métadonnées dans block.json pour récupérer le nom du bloc, et omis le Edit et les Save composants puisque nous exécutons les fonctions directement à partir d'ici.
Nous pouvons compiler ceci en exécutant npm run build dans la ligne de commande. Après cela, nous avons accès à un bloc appelé "Block Example" dans l'éditeur de blocs :
Si nous déposons le bloc dans la zone de contenu, nous obtenons le message que nous renvoyons de la edit fonction:
Premiers pas avec le développement de blocs WordPress
Si nous enregistrons et publions le message, nous devrions recevoir le message que nous renvoyons du save fonction lors de sa visualisation sur le front-end :
Premiers pas avec le développement de blocs WordPress
Création d'un bloc
On dirait que tout est branché ! Nous pouvons revenir à ce que nous avions dans index.js avant le test maintenant que nous avons confirmé que tout fonctionne :
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
Notez que le edit et les save les fonctions sont liées à deux fichiers existants dans le src répertoire qui @wordpress/create-block généré pour nous et inclut toutes les importations supplémentaires dont nous avons besoin dans chaque fichier. Plus important encore, cependant, ces fichiers établissent le Edit et les Save composants qui contiennent le balisage du bloc.
Balisage principal (src/edit.js)
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Edit() {
return (
{__("Hello from the Block Editor", "block-example")}
);
}
Vous voyez ce que nous avons fait là-bas ? Nous importons des accessoires du @wordpress/block-editor package qui nous permet de générer des classes que nous pourrons utiliser plus tard pour le style. Nous importons également le __ fonction d'internationalisation, pour le traitement des traductions.
Premiers pas avec le développement de blocs WordPress
Balisage frontal (src/save.js)
Cela crée un Save composant et nous allons utiliser à peu près la même chose que src/edit.js avec un texte légèrement différent :
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
Encore une fois, nous obtenons une belle classe que nous pouvons utiliser dans notre CSS :
Premiers pas avec le développement de blocs WordPress
Blocs de style
Nous venons de voir comment utiliser les accessoires de bloc pour créer des classes. Vous lisez cet article sur un site entièrement consacré au CSS, j'ai donc l'impression qu'il me manquerait quelque chose si nous n'abordions pas spécifiquement la manière d'écrire des styles de bloc.
Différencier les styles front-end et back-end
Si vous jetez un oeil à la block.json dans le src répertoire, vous trouverez deux champs liés aux styles :
editorStyle fournit le chemin d'accès aux styles appliqués au backend.
style est le chemin des styles partagés qui sont appliqués à la fois à l'avant et à l'arrière-plan.
Kev Quirk a un article détaillé qui montre son approche pour faire ressembler l'éditeur principal à l'interface utilisateur frontale.
Rappelons que le @wordpress/scripts le paquet copie le block.json fichier lorsqu'il traite le code dans le /src répertoire et place les actifs compilés dans le /build annuaire. C'est le build/block.json fichier utilisé pour enregistrer le bloc. Cela signifie que tout chemin que nous fournissons dans src/block.json doit être écrit par rapport à build/block.json.
Utiliser Sass
Nous pourrions déposer quelques fichiers CSS dans le build répertoire, référencez les chemins dans src/block.json, exécutez le build et appelez-le un jour. Mais cela ne tire pas parti de toute la puissance du @wordpress/scripts processus de compilation, qui est capable de compiler Sass en CSS. Au lieu de cela, nous plaçons nos fichiers de style dans le src répertoire et importez-les en JavaScript.
En faisant cela, nous devons être conscients de la façon dont @wordpress/scripts traite les styles :
Un fichier nommé style.css or style.scss or style.sass, importé dans le code JavaScript, est compilé pour style-index.css.
Tous les autres fichiers de style sont compilés et regroupés dans index.css.
Le @wordpress/scripts utilisations du package Webpack pour le regroupement et @wordpress/scripts utilise l' Plug-in PostCSS pour travailler pour le traitement des styles. PostCSS peut être étendu avec des plugins supplémentaires. La scripts package utilise ceux de Sass, SCSS et Autoprefixer, qui peuvent tous être utilisés sans installer de packages supplémentaires.
En fait, lorsque vous lancez votre bloc initial avec @wordpress/create-block, vous bénéficiez d'une bonne longueur d'avance avec les fichiers SCSS que vous pouvez utiliser pour démarrer :
editor.scss contient tous les styles appliqués à l'éditeur principal.
style.scss contient tous les styles partagés par le front-end et le back-end.
Voyons maintenant cette approche en action en écrivant un petit Sass que nous compilerons dans le CSS de notre bloc. Même si les exemples ne vont pas être très Sass-y, je les écris toujours dans les fichiers SCSS pour démontrer le processus de compilation.
Avant et les styles d'arrière-plan
OK, commençons par les styles appliqués à la fois au recto et au verso. Premièrement, nous devons créer src/style.scss (c'est déjà là si vous utilisez @wordpress/create-block) et assurez-vous de l'importer, ce que nous pouvons faire dans index.js:
import "./style.scss";
Ouvrez src/style.scss et déposez-y quelques styles de base en utilisant la classe qui a été générée pour nous à partir des accessoires de bloc :
C'est tout pour le moment! Lorsque nous exécutons la construction, cela est compilé dans build/style.css et est référencé à la fois par l'éditeur de blocs et le frontal.
Styles d'arrière-plan
Vous devrez peut-être écrire des styles spécifiques à l'éditeur de blocs. Pour cela, créez src/editor.scss (de nouveau, @wordpress/create-block le fait pour vous) et déposez-y quelques styles :
Puis importez-le dans edit.js, qui est le fichier qui contient notre Edit component (nous pouvons l'importer où nous voulons, mais comme ces styles sont pour l'éditeur, il est plus logique d'importer le composant ici) :
import "./editor.scss";
Maintenant quand nous courons npm run build, les styles sont appliqués au bloc dans les deux contextes :
Premiers pas avec le développement de blocs WordPressPremiers pas avec le développement de blocs WordPress
Styles de référence dans block.json
Nous avons importé les fichiers de style dans le edit.js et les index.js, mais rappelez-vous que l'étape de compilation génère pour nous deux fichiers CSS dans le build annuaire: index.css et les style-index.css respectivement. Nous devons référencer ces fichiers générés dans les métadonnées du bloc.
Ajoutons quelques déclarations à la block.json métadonnées :
Courir npm run build encore une fois, installez et activez le plugin sur votre site WordPress, et vous êtes prêt à l'utiliser !
Vous pouvez utiliser npm run start pour exécuter votre build en mode veille, en compilant automatiquement votre code chaque fois que vous modifiez votre code et enregistrez.
Nous grattons la surface
Les blocs réels utilisent la barre latérale Paramètres de l'éditeur de blocs et d'autres fonctionnalités fournies par WordPress pour créer des expériences utilisateur riches. De plus, le fait qu'il existe essentiellement deux versions de notre bloc — edit et les save - vous devez également réfléchir à la façon dont vous organisez votre code pour éviter la duplication de code.
Mais j'espère que cela aidera à démystifier le processus général de création de blocs WordPress. C'est vraiment une nouvelle ère dans le développement de WordPress. C'est difficile d'apprendre de nouvelles façons de faire les choses, mais j'ai hâte de voir comment ça évolue. Des outils comme @wordpress/create-block aide, mais même dans ce cas, il est bon de savoir exactement ce qu'il fait et pourquoi.
Les choses que nous avons couvertes ici vont-elles changer? Le plus probable! Mais au moins, vous avez une base de référence à partir de laquelle nous continuons à regarder les blocs WordPress mûrir, y compris les meilleures pratiques pour les créer.
Bibliographie
Encore une fois, mon objectif ici est de tracer une voie efficace pour entrer dans le développement de blocs en cette saison où les choses évoluent rapidement et la documentation WordPress a un peu de mal à rattraper son retard. Voici quelques ressources que j'ai utilisées pour rassembler cela:
