[add_filter](https:\/\/developer.wordpress.org\/reference\/functions\/add_filter\/)()<\/code>fonction PHP, nous avons la fonction Javascript [addFilter](https:\/\/developer.wordpress.org\/block-editor\/packages\/packages-hooks\/#api-usage)()<\/code>.<\/p>\nJ’\u00e9crirai le code dans la syntaxe Javascript ES6, qui n\u00e9cessite un compilateur pour le transformer. Vous pouvez \u00e9crire dans la syntaxe ES5 mais je vous recommande d’opter pour ES6\/ESNext. J’ai un article qui explique comment configurer un transformateur pour ES6\/ESNext<\/a>. Je suppose \u00e9galement que vous avez une certaine familiarit\u00e9 avec React\/JSX, peut-\u00eatre une certaine exp\u00e9rience dans la cr\u00e9ation de vos propres blocs Gutenberg personnalis\u00e9s<\/a>.<\/p>\nCe que vous pouvez filtrer sur les blocs Gutenberg<\/h2>\n
Il n’y a pas beaucoup de documentation sur les crochets et les filtres Gutenberg disponibles. Mais dans le but d’ajouter des param\u00e8tres personnalis\u00e9s et de les appliquer d’une mani\u00e8re ou d’une autre sur des blocs existants\u00a0; c’est ce que j’ai trouv\u00e9 jusqu’\u00e0 pr\u00e9sent. Je me suis concentr\u00e9 sur l’ajout de param\u00e8tres simples, et non sur des op\u00e9rations qui n\u00e9cessitent des changements drastiques de composants ou un comportement complexe.<\/p>\n
Il y a trois \u00e9tapes pour ajouter des param\u00e8tres personnalis\u00e9s aux blocs existants\u00a0:<\/p>\n
\n- Nous ajoutons un filtre sur le
[registerBlockType](https:\/\/developer.wordpress.org\/block-editor\/developers\/block-api\/block-registration\/#registerblocktype)<\/code>tableau de param\u00e8tres du bloc existant. Cela nous permet d’ajouter de nouveaux attributs au attributes<\/code>tableau, nous permettant ainsi d’enregistrer des informations suppl\u00e9mentaires sur le bloc. Nous devons enregistrer notre param\u00e8tre personnalis\u00e9 quelque part.<\/li>\n- Accrochez-vous au composant du bloc
edit<\/code>(le composant responsable du rendu du bloc dans l’\u00e9diteur). Dans ce crochet, nous pouvons nous accrocher \u00e0 l’inspecteur (la barre lat\u00e9rale) et ajouter nos propres composants. Nous pouvons soit ajouter une nouvelle section\/un nouveau panneau, soit nous accrocher \u00e0 la section "Avanc\u00e9" qui est toujours pr\u00e9sente dans tous les blocs. Ensuite, c’est \u00e0 nous de rendre les entr\u00e9es de param\u00e8tres, telles que les entr\u00e9es de texte, les cases \u00e0 cocher ou autres.<\/li>\nsave<\/code>Filtrez les accessoires du bloc. Nous pouvons ajuster les accessoires pour la sauvegarde, qui est responsable \u00e0 la fois de la sauvegarde du bloc et de son rendu en frontend (en dehors de l’\u00e9diteur). Dans notre cas, nous voulons ajouter une classe ou un style en ligne.<\/li>\n<\/ul>\nNous pouvons cibler un ou plusieurs blocs sp\u00e9cifiques ou tout cibler. Nous avons toujours acc\u00e8s au type de bloc auquel nous nous trouvons.<\/p>\n
Pour le dire en d’autres termes\u00a0: nous ajoutons des param\u00e8tres personnalis\u00e9s dans l’inspecteur et les enregistrons dans les attributs personnalis\u00e9s que nous avons ajout\u00e9s au bloc. Nous pouvons ensuite influencer le nom de la classe du bloc ou le style en ligne (dans certains cas), en fonction des attributs enregistr\u00e9s. Avec les noms de classe personnalis\u00e9s, nous pouvons facilement ajouter un CSS personnalis\u00e9 qui donne visuellement un effet \u00e0 nos param\u00e8tres.<\/p>\n
Ce qu’on ne peut pas faire (pour l’instant ?)<\/h2>\n
Malheureusement, il y a certaines choses auxquelles nous ne pouvons pas acc\u00e9der avec des filtres sur des blocs existants. En ce qui concerne l’ajout de param\u00e8tres personnalis\u00e9s simples aux blocs, ce sont des choses courantes que nous ne pouvons pas affecter.<\/p>\n
Pas d’acc\u00e8s au style en ligne du bloc dans l’\u00e9diteur<\/h3>\n
Dans certains cas de param\u00e8tres affectant la conception d’un bloc, nous devons ajouter un style en ligne sur le n\u0153ud d’habillage du bloc. Juste le nom de la classe ne suffira pas. Par exemple, si vous ajoutez un param\u00e8tre de couleur personnalis\u00e9 et que l’utilisateur s\u00e9lectionne une couleur personnalis\u00e9e (\u00e0 partir du s\u00e9lecteur de couleurs), vous ne pouvez pas r\u00e9soudre ce probl\u00e8me en ajoutant une classe – vous avez besoin d’un style en ligne.<\/p>\n
Malheureusement, il semble que les blocs par d\u00e9faut de WordPress g\u00e8rent le style en ligne dans l’\u00e9diteur de mani\u00e8re totalement ind\u00e9pendante, sans possibilit\u00e9 de filtrage ou de \u00abconnexion \u00bb. Je vais montrer un moyen de contourner cela dans le dernier exemple ci-dessous, mais ce n’est pas id\u00e9al dans tous les cas.<\/p>\n
Pourquoi se soucier que le bloc ait un aspect diff\u00e9rent dans l’\u00e9diteur par rapport \u00e0 l’interface, vous pouvez demander\u00a0? L’int\u00e9r\u00eat de Gutenberg est de mettre en \u0153uvre une mani\u00e8re visuelle d’\u00e9diter le contenu o\u00f9 ce que nous voyons est r\u00e9ellement ce que nous obtenons. Nous voulons obtenir le m\u00eame aspect visuel \u00e0 la fois dans l’\u00e9diteur et dans l’interface.<\/p>\n
Certains blocs n’incluent pas le nom de la classe dans l’\u00e9diteur<\/h3>\n
Comme mentionn\u00e9 ci-dessus, nous pouvons filtrer le nom de la classe d’emballage du bloc car il s’agit d’un prop qui est transmis \u00e0 tous les blocs Gutenberg. Mais malheureusement, certains blocs n’appliquent pas du tout la classe du bloc dans edit<\/code>. Un exemple est le bloc Cover. J’ai beaucoup jou\u00e9 en utilisant les blocs Cover comme "sections" pour les pages d’accueil, et je continue \u00e0 rencontrer des probl\u00e8mes car le bloc Cover construit sa propre classe \u00e0 l’int\u00e9rieur de edit<\/code>. Il ignore compl\u00e8tement la classe "globale" du bloc (qui est celle \u00e0 laquelle nous avons acc\u00e8s via des filtres).<\/p>\nMais au moins, nous pouvons \u00eatre s\u00fbrs que les noms de classe filtr\u00e9s sont toujours appliqu\u00e9s dans save<\/code>(frontend). Cela se produit automatiquement en dehors du code sp\u00e9cifique de chaque bloc.<\/p>\nSi je me trompe sur l’un des points ci-dessus, S’IL VOUS PLA\u00ceT, faites-le moi savoir dans les commentaires ci-dessous! J’apprends continuellement Gutenberg, et en m\u00eame temps Gutenberg \u00e9volue \u00e9galement. J’esp\u00e8re qu’\u00e0 un moment donn\u00e9 ce qui pr\u00e9c\u00e8de sera possible \u00e0 un moment donn\u00e9 ou que c’est possible, mais il me manque juste des informations cruciales\u00a0!<\/p>\n
Avec cela \u00e0 l’\u00e9cart, commen\u00e7ons \u00e0 examiner du code.<\/p>\n
Exemple\u00a01\u00a0: Ajouter un champ bascule pour masquer un bloc Couverture sur mobile<\/h2>\n
Supposons que nous d\u00e9veloppions un th\u00e8me o\u00f9 les blocs de couverture seront utilis\u00e9s pour les "sections" sur la page d’accueil. Et nous voulons offrir \u00e0 l’utilisateur la possibilit\u00e9 de masquer une certaine section du mobile. Pour r\u00e9soudre ce probl\u00e8me, nous pouvons ajouter un champ de basculement dans la section "Avanc\u00e9" de l’inspecteur du bloc Cover. Si le champ est activ\u00e9, le bloc Couverture obtiendra une classe personnalis\u00e9e suppl\u00e9mentaire que nous pouvons cibler avec des requ\u00eates CSS et multim\u00e9dia.<\/p>\n
Au fait\u00a0: il s’agit d’un cas o\u00f9 le probl\u00e8me du bloc Cover qui n’applique pas nos noms de classe personnalis\u00e9s dans l’\u00e9diteur est en fait un avantage\u00a0! Imaginez si c’\u00e9tait le cas; alors il serait impossible pour l’utilisateur d’\u00e9diter le bloc dans l’\u00e9diteur s’il a un petit \u00e9cran !<\/p>\n
Comme mentionn\u00e9 pr\u00e9c\u00e9demment, il y a trois \u00e9tapes pour lesquelles nous devons coder. Nous devons \u00e9galement ajouter du PHP pour mettre en file d’attente notre fichier Javascript dans l’\u00e9diteur. Faisons cela d’abord.<\/p>\n
Ajout de notre script \u00e0 l’\u00e9diteur<\/h3>\n
Nous accrochons une fonction \u00e0 l’action [enqueue_block_editor_assets](https:\/\/developer.wordpress.org\/reference\/hooks\/enqueue_block_editor_assets\/)<\/code>. Dans notre fonction, nous mettons un script en file d’attente, comme nous le ferions habituellement dans wp_enqueue_scripts<\/code>hook.<\/p>\nadd_action('enqueue_block_editor_assets', function() {\n wp_enqueue_script('awp-gutenberg-filters', get_template_directory_uri(). '\/assets\/js\/gutenberg-filters.js', ['wp-edit-post']);\n});<\/code><\/pre>\nN’oubliez pas d’ajuster le chemin d’acc\u00e8s \u00e0 l’endroit o\u00f9 se trouve votre script\u00a0! Remarque: Si vous \u00e9crivez dans ES6 avec webpack compilant votre Javascript, n’oubliez pas de d\u00e9finir le chemin vers la construction de votre script, pas la source.<\/p>\n
J’aime ajouter ‘ wp-edit-post<\/code>‘ comme d\u00e9pendance au script pour m’assurer qu’il se charge suffisamment tard.<\/p>\nC’est tout le PHP que nous devons faire. Le reste est \u00e9crit dans notre fichier Javascript.<\/p>\n
Ajouter un attribut personnalis\u00e9<\/h3>\n
Le premier filtre que nous utiliserons est l’objet de param\u00e8tres des blocks.registerBlockType<\/code>filtres .registerBlockType<\/code><\/p>\nMais d’abord, un peu sur l’ajout de filtres en Javascript. Comme je n’ai pas trouv\u00e9 de bonne documentation pour cela, je vais l’expliquer un peu ici. La fonction addFilter<\/code>est dans l’ espace de wp.hooks<\/code>noms et accepte quatre arguments.<\/p>\naddFilter('hookName', 'namespace', 'functionName', 'priority');<\/code><\/p>\nLe premier param\u00e8tre, ‘hookName’, est le nom du filtre auquel nous voulons nous accrocher. C’est l’\u00e9quivalent du premier param\u00e8tre lors de l’utilisation de PHP add_filter()<\/code>. Le deuxi\u00e8me param\u00e8tre, ‘namespace’, est un nom d’espace de noms personnalis\u00e9 pour votre code. C’est juste pour \u00e9viter la collision de noms. Vous pouvez \u00e0 peu pr\u00e8s d\u00e9finir tout ce que vous voulez ici, mais n’utilisez pas l’espace de noms de WordPress (‘wp’). Utilisez une forme abr\u00e9g\u00e9e de votre nom ou du nom du projet. Le troisi\u00e8me param\u00e8tre, ‘functionName’, est la fonction hook\u00e9e – qui est la m\u00eame que le add_filter()<\/code>deuxi\u00e8me argument de PHP. Et enfin le quatri\u00e8me param\u00e8tre, ‘priorit\u00e9’, est facultatif. Encore une fois, c’est la m\u00eame chose que le add_filter()<\/code>troisi\u00e8me argument de PHP.<\/p>\nLe processus pour les filtres en Javascript est le m\u00eame qu’en PHP. Nous d\u00e9finissons une fonction qui doit renvoyer la variable filtr\u00e9e. Parfois, la variable est une cha\u00eene, un objet ou un composant. \u00c0 l’int\u00e9rieur de la fonction, nous modifions la variable comme bon nous semble.<\/p>\n
Dans notre cas, nous voulons ajouter un nouvel attribut \u00e0 l’ attribute<\/code>objet du bloc. Nous appellerons le nouvel attribut hideOnMobile<\/code>et d\u00e9finirons son type sur boolean<\/code>. Cela se fait comme ceci :<\/p>\nfunction addCoverAttribute(settings, name) {\n if (typeof settings.attributes !== 'undefined') {\n if (name == 'core\/cover') {\n settings.attributes = Object.assign(settings.attributes, {\n hideOnMobile: {\n type: 'boolean',\n }\n });\n }\n }\n return settings;\n}\n\u00a0\nwp.hooks.addFilter(\n 'blocks.registerBlockType',\n 'awp\/cover-custom-attribute',\n addCoverAttribute\n);<\/code><\/pre>\n\u00c0 la ligne, #3<\/code>nous nous assurons de cibler uniquement les blocs de type ‘ core\/cover<\/code>‘. Le deuxi\u00e8me argument \u00e0 blocks.registerBlockType<\/code>filtrer est assez commod\u00e9ment le nom du bloc. Nous ajoutons ensuite un nouvel objet \u00e0 l’ settings.attributes<\/code>objet. Enfin, nous nous assurons de renvoyer la variable filtr\u00e9e, settings<\/code>.<\/p>\n\u00c0 ce stade, visuellement, rien n’a chang\u00e9 \u00e0 Gutenberg. Mais tous les blocs de couverture ont maintenant un attribut suppl\u00e9mentaire que nous pouvons utiliser pour stocker notre r\u00e9glage.<\/p>\n
Ajouter un param\u00e8tre \u00e0 l’inspecteur (panneau Avanc\u00e9)<\/h3>\n
Le deuxi\u00e8me filtre est appel\u00e9 editor.BlockEdit<\/code>et filtre le composant du bloc edit<\/code>. Ce filtre re\u00e7oit le composant du bloc d’origine BlockEdit<\/code>et renvoie un nouveau composant envelopp\u00e9. Nous devons utiliser wp.compose.createHigherOrderComponent<\/code>pour retourner le composant envelopp\u00e9.<\/p>\n\u00c0 l’int\u00e9rieur de notre composant, nous nous assurons de rendre le composant envelopp\u00e9 BlockEdit<\/code>, peu importe. Mais si le bloc est de type Cover, nous nous accrochons \u00e9galement au composant InspectorAdvancedControls<\/code>(qui est le panneau "Avanc\u00e9" dans Inspector) et ajoutons un fichier ToggleControl<\/code>. Nous \u00e9crivons le ToggleControl<\/code>pour afficher la valeur de et mettons \u00e0 jour l’attribut personnalis\u00e9 que nous avons ajout\u00e9 pr\u00e9c\u00e9demment, hideOnMobile<\/code>.<\/p>\nconst coverAdvancedControls = wp.compose.createHigherOrderComponent((BlockEdit) => {\n return (props) => {\n const { Fragment } = wp.element;\n const { ToggleControl } = wp.components;\n const { InspectorAdvancedControls } = wp.blockEditor;\n const { attributes, setAttributes, isSelected } = props;\n return (<Fragment>\n <BlockEdit {...props} \/>\n {isSelected && (props.name == 'core\/cover') && \n <InspectorAdvancedControls>\n <ToggleControl\n label={wp.i18n.__('Hide on mobile', 'awp')}\n checked={!!attributes.hideOnMobile}\n onChange={(newval) => setAttributes({ hideOnMobile: !attributes.hideOnMobile })}\n \/>\n <\/InspectorAdvancedControls>\n }\n <\/Fragment>\n );\n };\n}, 'coverAdvancedControls');\n\u00a0\nwp.hooks.addFilter(\n 'editor.BlockEdit',\n 'awp\/cover-advanced-control',\n coverAdvancedControls\n);<\/code><\/pre>\nN’oubliez pas de toujours retourner l’original BlockEdit<\/code>, ce que nous faisons \u00e0 line #9<\/code>. \u00c0 la ligne 10, nous v\u00e9rifions si le type de bloc est Cover et rendons le InspectorAdvancedControls<\/code>composant. \u00c0 l’ int\u00e9rieur, nous ajoutons un ToggleControl<\/code>, qui est un contr\u00f4le d’entr\u00e9e qui s’affiche sous la forme d’une bascule entre vrai ou faux. Nous d\u00e9finissons une \u00e9tiquette et connectons sa valeur \u00e0 l’ hideOnMobile<\/code>attribut. Si vous avez d\u00e9j\u00e0 ajout\u00e9 des param\u00e8tres \u00e0 Inspector, cela devrait \u00eatre assez simple pour vous.<\/p>\nAvec le code ci-dessus, nous devrions maintenant obtenir ceci dans le panneau "Avanc\u00e9" de l’inspecteur sur les blocs de couverture\u00a0:<\/p>\n
![\"Ajouter](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d70271f5a.png\")
<\/a><\/p>\nL’entr\u00e9e va maintenant mettre \u00e0 jour notre attribut personnalis\u00e9 hideOnMobile<\/code>. La derni\u00e8re \u00e9tape consiste \u00e0 faire quelque chose en fonction de la valeur de cet attribut. \u00c0 l’heure actuelle, l’attribut est enregistr\u00e9, mais n’affecte en fait rien.<\/p>\nAjouter une classe personnalis\u00e9e<\/h3>\n
La derni\u00e8re \u00e9tape consiste \u00e0 ajouter une classe personnalis\u00e9e \u00e0 la classe du bloc. Nous faisons cela avec le filtre blocks.getSaveContent.extraProps<\/code>. Ce filtre affecte les accessoires du composant du bloc save<\/code>. L’un d’eux est le prop className<\/code>, qui sera toujours appliqu\u00e9 au frontend. Nous ajoutons simplement notre classe personnalis\u00e9e apr\u00e8s si l’attribut \u00e9tait true<\/code>, puis nous le renvoyons. J’ai d\u00e9cid\u00e9 d’ajouter une classe ‘ hide-on-mobile<\/code>‘, mais vous pouvez l’appeler comme vous le souhaitez.<\/p>\nfunction coverApplyExtraClass(extraProps, blockType, attributes) {\n const { hideOnMobile } = attributes;\n\u00a0\n if (typeof hideOnMobile !== 'undefined' && hideOnMobile) {\n extraProps.className = extraProps.className + ' hide-on-mobile';\n }\n return extraProps;\n}\n\u00a0\nwp.hooks.addFilter(\n 'blocks.getSaveContent.extraProps',\n 'awp\/cover-apply-class',\n coverApplyExtraClass\n);<\/code><\/pre>\nCe code est assez explicite. \u00c0 la ligne, #4<\/code>nous v\u00e9rifions si l’attribut hideOnMobile<\/code>existe et est true<\/code>. Si tel est le cas, nous ajoutons une classe personnalis\u00e9e \u00e0 la className<\/code>cha\u00eene.<\/p>\nAvec les trois filtres ci-dessus, nous devrions maintenant obtenir une classe personnalis\u00e9e "hide-on-mobile" appliqu\u00e9e \u00e0 notre bloc Cover chaque fois que le param\u00e8tre est activ\u00e9.<\/p>\n
![\"Ajouter](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d70343817.png\")
<\/a><\/p>\nIl ne reste plus qu’\u00e0 ajouter du CSS \u00e0 la feuille de style frontale de votre th\u00e8me. Quelque chose comme \u00e7a;<\/p>\n
.wp-block-cover.hide-on-mobile { display: none; }\n@media (min-width: 480px) {\n .wp-block-cover.hide-on-mobile { display: block; }\n}<\/code><\/pre>\nExemple 2\u00a0: Ajouter un panneau Inspecteur avec un param\u00e8tre de couleur d’arri\u00e8re-plan personnalis\u00e9 pour le bloc Spacer<\/h2>\n
Pour le deuxi\u00e8me cas d’utilisation, nous voulons ajouter des param\u00e8tres de couleur personnalis\u00e9s au bloc Spacer. Par d\u00e9faut, le bloc Spacer n’a pas d’autres param\u00e8tres que sa hauteur. Supposons que nous voulions ajouter une couleur d’arri\u00e8re-plan qui colorie toute la hauteur du bloc Spacer. Cela permet \u00e0 l’utilisateur d’ajouter des "bandes" vides et color\u00e9es \u00e0 l’int\u00e9rieur de son contenu. Dans ce cas, nous souhaitons ajouter les param\u00e8tres de couleur dans son propre panneau s\u00e9par\u00e9 dans l’inspecteur, conform\u00e9ment au comportement habituel attendu pour les param\u00e8tres de couleur.<\/p>\n
Remarque\u00a0: La gestion des couleurs est un peu plus compliqu\u00e9e car nous devons utiliser un (autre) composant d’ordre sup\u00e9rieur withColors<\/code>. Parce que nous devons d\u00e9j\u00e0 impl\u00e9menter un composant d’ordre sup\u00e9rieur dans le editor.BlockEdit<\/code>nous avons besoin de compose<\/code>plusieurs composants. De plus, nous devons ajouter deux attributs pour chaque param\u00e8tre de couleur. L’un contiendra le slug de la palette de couleurs et l’autre contiendra le code de couleur hexad\u00e9cimal – uniquement si l’utilisateur a opt\u00e9 pour une couleur personnalis\u00e9e (utilis\u00e9 le s\u00e9lecteur de couleurs). C’est un comportement courant lorsque vous travaillez avec withColors<\/code>. J’ai un <a href="https:\/\/wordpress.mediadoma.com\/fr\/comment-ajouter-des-parametres-de-couleur-a-votre-bloc-gutenberg-personnalise\/" title="article qui explique l'ajout de param\u00e8tres de couleur et withColors<\/code>en d\u00e9tail\u00a0\u00bb >article qui explique l’ajout de param\u00e8tres de couleur et withColors<\/code>en d\u00e9tail<\/a> si vous \u00eates confus.<\/p>\nDeuxi\u00e8mement, nous allons dans ce cas rencontrer le probl\u00e8me expliqu\u00e9 ci-dessus; o\u00f9 nous ne pouvons pas ajouter le style en ligne appropri\u00e9 \u00e0 l’\u00e9diteur. La solution pour laquelle j’ai opt\u00e9 dans ce cas est d’envelopper le bloc Spacer \u00e0 l’int\u00e9rieur d’un div<\/code>dans l’\u00e9diteur et d’appliquer les classes et le style en ligne appropri\u00e9s au wraping div<\/code>. Cela rend la couleur s\u00e9lectionn\u00e9e visible dans l’\u00e9diteur lorsque le bloc est d\u00e9s\u00e9lectionn\u00e9. Cependant, lors de la s\u00e9lection du bloc, WordPress ajoute son propre arri\u00e8re-plan gris clair personnalis\u00e9 au bloc, couvrant notre couleur d’arri\u00e8re-plan personnalis\u00e9e. Un CSS \u00e0 l’\u00e9diteur r\u00e9soudra ce probl\u00e8me. J’expliquerai plus \u00e0 la fin.<\/p>\nLes \u00e9tapes sont les m\u00eames que dans l’exemple ci-dessus. Nous mettons d’abord notre script en file d’attente dans l’\u00e9diteur en PHP. Ensuite en Javascript on filtre l’ attributes<\/code>objet, le edit<\/code>composant du Spacer et enfin le save<\/code>composant du Spacer.<\/p>\nAjout de notre script \u00e0 l’\u00e9diteur<\/h3>\n
Nous accrochons une fonction \u00e0 l’action [enqueue_block_editor_assets](https:\/\/developer.wordpress.org\/reference\/hooks\/enqueue_block_editor_assets\/)<\/code>. Dans notre fonction, nous mettons un script en file d’attente, comme nous le ferions habituellement dans wp_enqueue_scripts<\/code>hook.<\/p>\nadd_action('enqueue_block_editor_assets', function() {\n wp_enqueue_script('awp-gutenberg-filters', get_template_directory_uri(). '\/assets\/js\/gutenberg-filters.js', ['wp-edit-post']);\n});<\/code><\/pre>\nN’oubliez pas d’ajuster le chemin d’acc\u00e8s \u00e0 votre script. J’aime ajouter ‘ wp-edit-post<\/code>‘ comme d\u00e9pendance au script pour m’assurer qu’il se charge suffisamment tard.<\/p>\nC’est tout le PHP que nous devons faire. Le reste est \u00e9crit dans notre fichier Javascript.<\/p>\n
Ajouter des attributs personnalis\u00e9s<\/h3>\n
Comme dans l’exemple ci-dessus, nous ajoutons un filtre sur blocks.registerBlockType<\/code>afin d’ajouter des \u00e9l\u00e9ments d’objet suppl\u00e9mentaires \u00e0 l’objet du bloc attributes<\/code>.<\/p>\nLorsque vous travaillez avec, withColors<\/code>nous devons ajouter deux attributs pour chaque couleur. Le nom de notre attribut de couleur d’arri\u00e8re-plan est backgroundColor<\/code>, ce qui signifie que le deuxi\u00e8me attribut doit \u00eatre nomm\u00e9 customBackgroundColor<\/code>. Tout cela est expliqu\u00e9 dans mon article sur la gestion des param\u00e8tres de couleur dans Gutenberg<\/a>. Les deux doivent \u00eatre de type string et appliqu\u00e9s uniquement aux blocs de type Spacer.<\/p>\nfunction addSpacerAttributes(settings, name) {\n if (typeof settings.attributes !== 'undefined') {\n if (name == 'core\/spacer') {\n settings.attributes = Object.assign(settings.attributes, {\n backgroundColor: {\n type: 'string',\n },\n customBackgroundColor: {\n type: 'string'\n }\n });\n }\n }\n return settings;\n}\n\u00a0\nwp.hooks.addFilter(\n 'blocks.registerBlockType',\n 'awp\/spacer-background-attribute',\n addSpacerAttributes\n);<\/code><\/pre>\nAjouter le panneau ColorSettings \u00e0 l’inspecteur<\/h3>\n
La deuxi\u00e8me \u00e9tape consiste \u00e0 ajouter un panneau de param\u00e8tres de couleur \u00e0 l’inspecteur pour le bloc Spacer en filtrant editor.BlockEdit<\/code>.<\/p>\nconst spacerInspectorControls = wp.compose.compose(\n wp.blockEditor.withColors({backgroundColor: 'background-color'}),\n\u00a0\n wp.compose.createHigherOrderComponent((BlockEdit) => {\n return (props) => {\n\u00a0\n if (props.name !== 'core\/spacer') {\n return(<BlockEdit {...props} \/>);\n }\n\u00a0\n const { Fragment } = wp.element;\n const { InspectorControls, PanelColorSettings } = wp.blockEditor;\n const { attributes, setAttributes, isSelected } = props;\n const { backgroundColor, setBackgroundColor } = props;\n\u00a0\n let newClassName = (attributes.className != undefined)? attributes.className: '';\n let newStyles = {...props.style};\n if (backgroundColor != undefined) {\n if (backgroundColor.class == undefined) {\n newStyles.backgroundColor = backgroundColor.color;\n } else {\n newClassName += ' ' + backgroundColor.class;\n }\n }\n const newProps = {\n ...props,\n attributes: {\n ...attributes,\n className: newClassName\n },\n style: newStyles\n }\n\u00a0\n return (<Fragment>\n <div style={newStyles} className={newClassName}>\n <BlockEdit {...newProps} \/>\n {isSelected && (props.name == 'core\/spacer') && \n <InspectorControls>\n <PanelColorSettings \n title={wp.i18n.__('Color Settings', 'awp')}\n colorSettings={[\n {\n value: backgroundColor.color,\n onChange: setBackgroundColor,\n label: wp.i18n.__('Background color', 'awp')\n }\n ]}\n \/>\n <\/InspectorControls>\n }\n <\/div>\n <\/Fragment>\n );\n };\n}, 'spacerInspectorControls'));\n\u00a0\nwp.hooks.addFilter(\n 'editor.BlockEdit',\n 'awp\/spacer-inspector-control',\n spacerInspectorControls\n);<\/code><\/pre>\nNous devons utiliser compose<\/code>pour combiner le composant d’ordre sup\u00e9rieur renvoy\u00e9 par ce filtre et withColors<\/code>. En d’autres termes, nous encapsulons simplement le composant renvoy\u00e9 dans withColors<\/code>. En param\u00e8tre, withColors<\/code>nous fournissons notre attribut backgroundColor<\/code>.<\/p>\n\u00c0 l’int\u00e9rieur du composant envelopp\u00e9, nous nous assurons de toujours revenir BlockEdit<\/code>(ligne #9<\/code>et #39<\/code>pour les blocs Spacer). Pour les blocs de type Spacer, nous nous accrochons \u00e9galement InspectorControls<\/code>pour ajouter un PanelColorSettings<\/code>pour notre choix de couleur. Il s’agit de la proc\u00e9dure standard d’ajout de param\u00e8tres de couleur.<\/p>\n\u00c0 la ligne, #17 - 34<\/code>nous g\u00e9n\u00e9rons manuellement la classe n\u00e9cessaire et\/ou le style en ligne. Ensuite, \u00e0 la ligne, #38<\/code>nous ajoutons un div enveloppant BlockEdit<\/code>avec ces classes et ces styles en ligne.<\/p>\nLe r\u00e9sultat est un nouveau panneau de param\u00e8tres de couleur dans l’inspecteur pour les blocs Spacer, enti\u00e8rement fonctionnel.<\/p>\n
![\"Ajouter](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d7041a66b.png\")
<\/a><\/p>\n![\"Ajouter](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d7052e0c9.gif\")
<\/a><\/p>\n