[add_filter](https:\/\/developer.wordpress.org\/reference\/functions\/add_filter\/)()<\/code>, temos a fun\u00e7\u00e3o Javascript [addFilter](https:\/\/developer.wordpress.org\/block-editor\/packages\/packages-hooks\/#api-usage)()<\/code>.<\/p>\nEstarei escrevendo o c\u00f3digo na sintaxe Javascript ES6, que requer um compilador para transform\u00e1-lo. Voc\u00ea pode escrever na sintaxe ES5, mas eu recomendo ir para ES6\/ESNext. Eu tenho um post que explica como configurar um transformador para ES6\/ESNext<\/a>. Eu tamb\u00e9m suponho que voc\u00ea tenha alguma familiaridade com React\/JSX, possivelmente alguma experi\u00eancia em como criar seus pr\u00f3prios blocos Gutenberg personalizados<\/a>.<\/p>\nO que voc\u00ea pode filtrar em blocos Gutenberg<\/h2>\n
N\u00e3o h\u00e1 muita documenta\u00e7\u00e3o em ganchos e filtros Gutenberg dispon\u00edveis. Mas com o prop\u00f3sito de adicionar configura\u00e7\u00f5es personalizadas e de alguma forma aplic\u00e1-las em blocos existentes; isso \u00e9 o que eu encontrei at\u00e9 agora. Concentrei-me em adicionar configura\u00e7\u00f5es simples \u2013 n\u00e3o em opera\u00e7\u00f5es que exigem mudan\u00e7as dr\u00e1sticas de componentes ou comportamento complexo.<\/p>\n
H\u00e1 tr\u00eas etapas para adicionar configura\u00e7\u00f5es personalizadas a blocos existentes:<\/p>\n
\n[registerBlockType](https:\/\/developer.wordpress.org\/block-editor\/developers\/block-api\/block-registration\/#registerblocktype)<\/code>Adicionamos um filtro no array de configura\u00e7\u00f5es do bloco existente. Isso nos permite adicionar novos atributos ao attributes<\/code>array, permitindo assim salvar informa\u00e7\u00f5es adicionais no bloco. Precisamos salvar nossa configura\u00e7\u00e3o personalizada em algum lugar.<\/li>\n- Conecte-se ao componente do bloco
edit<\/code>(o componente respons\u00e1vel por renderizar o bloco no editor). Neste gancho, podemos nos conectar ao Inspetor (a barra lateral) e adicionar nossos pr\u00f3prios componentes. Podemos adicionar uma nova se\u00e7\u00e3o\/painel, ou podemos nos conectar \u00e0 se\u00e7\u00e3o "Avan\u00e7ado" que est\u00e1 sempre presente em todos os blocos. Ent\u00e3o cabe a n\u00f3s renderizar as entradas de configura\u00e7\u00e3o, como entradas de texto, caixas de sele\u00e7\u00e3o ou outros enfeites.<\/li>\nsave<\/code>Filtre os adere\u00e7os do bloco. Podemos ajustar as props para save, que \u00e9 respons\u00e1vel tanto por salvar o bloco quanto renderiz\u00e1-lo no frontend (fora do editor). No nosso caso, queremos adicionar uma classe ou estilo embutido.<\/li>\n<\/ul>\nPodemos segmentar blocos espec\u00edficos ou segmentar todos. Sempre temos acesso ao tipo de bloco em que estamos.<\/p>\n
Em outras palavras: adicionamos algumas configura\u00e7\u00f5es personalizadas no Inspector e as salvamos em atributos personalizados que adicionamos ao bloco. Podemos ent\u00e3o influenciar o nome da classe do bloco ou o estilo inline (em alguns casos), dependendo dos atributos salvos. Com os nomes de classe personalizados, podemos facilmente adicionar CSS personalizado que visualmente d\u00e1 um efeito \u00e0s nossas configura\u00e7\u00f5es.<\/p>\n
O que n\u00e3o podemos fazer (por enquanto?)<\/h2>\n
Infelizmente, existem algumas coisas que n\u00e3o podemos acessar com filtros em blocos existentes. No que diz respeito \u00e0 adi\u00e7\u00e3o de configura\u00e7\u00f5es personalizadas simples aos blocos, essas s\u00e3o coisas comuns que n\u00e3o podemos afetar.<\/p>\n
Sem acesso ao estilo embutido do bloco dentro do editor<\/h3>\n
Em casos de configura\u00e7\u00f5es que afetam o design de um bloco, precisamos adicionar estilo inline no n\u00f3 de encapsulamento do bloco. Apenas o nome da classe n\u00e3o serve. Por exemplo, se voc\u00ea adicionar uma configura\u00e7\u00e3o de cor personalizada e o usu\u00e1rio selecionar uma cor personalizada (do colorpicker), voc\u00ea n\u00e3o poder\u00e1 resolver isso adicionando uma classe \u2013 voc\u00ea precisa de um estilo embutido.<\/p>\n
Infelizmente, parece que os blocos padr\u00e3o do WordPress lidam com o estilo inline no editor de forma totalmente independente, sem op\u00e7\u00e3o de filtragem ou “liga\u00e7\u00e3o". Mostrarei uma maneira de contornar isso no \u00faltimo exemplo abaixo, mas n\u00e3o \u00e9 ideal em todos os casos.<\/p>\n
Por que se importar que o bloco pare\u00e7a diferente no editor versus no frontend, voc\u00ea pode perguntar? O objetivo de Gutenberg \u00e9 implementar uma maneira visual de editar conte\u00fado onde o que vemos \u00e9 realmente o que obtemos. Queremos alcan\u00e7ar a mesma apar\u00eancia visual tanto no editor quanto no frontend.<\/p>\n
Alguns blocos n\u00e3o incluem o nome da classe no editor<\/h3>\n
Como mencionado acima, podemos filtrar o nome da classe de encapsulamento do bloco, pois este \u00e9 um prop que \u00e9 passado para todos os blocos do Gutenberg. Mas, infelizmente, existem alguns blocos que n\u00e3o aplicam a classe do bloco em edit<\/code>. Um exemplo \u00e9 o bloco Cover. Eu brinquei muito usando blocos Cover como “se\u00e7\u00f5es” para frontpages e continuo tendo problemas porque o bloco Cover constr\u00f3i sua pr\u00f3pria classe dentro do edit<\/code>. Ele pula completamente a classe “global” do bloco (que \u00e9 a que temos acesso por meio de filtros).<\/p>\nMas pelo menos podemos ter certeza de que os nomes das classes filtradas s\u00e3o sempre aplicados em save<\/code>(frontend). Isso acontece automaticamente fora do c\u00f3digo espec\u00edfico de cada bloco.<\/p>\nSe eu estiver errado sobre qualquer um dos itens acima, por favor, deixe-me saber nos coment\u00e1rios abaixo! Estou continuamente aprendendo Gutenberg e, ao mesmo tempo, Gutenberg evolui tamb\u00e9m. Espero que em algum momento o acima seja poss\u00edvel em algum momento ou que seja poss\u00edvel, mas estou perdendo algumas informa\u00e7\u00f5es cruciais!<\/p>\n
Com isso fora do caminho, vamos come\u00e7ar a analisar algum c\u00f3digo.<\/p>\n
Exemplo 1: adicionar um campo de altern\u00e2ncia para ocultar um bloco de capa no celular<\/h2>\n
Vamos supor que estamos desenvolvendo um tema onde os blocos de capa ser\u00e3o usados \u200b\u200bpara “se\u00e7\u00f5es” na primeira p\u00e1gina. E queremos fornecer ao usu\u00e1rio a possibilidade de ocultar uma determinada se\u00e7\u00e3o do celular. Para resolver isso, podemos adicionar um campo de altern\u00e2ncia na se\u00e7\u00e3o “Avan\u00e7ado” no Inspetor do bloco de capa. Se o campo estiver ativado, o bloco Cover obter\u00e1 uma classe personalizada adicional que podemos direcionar com CSS e consultas de m\u00eddia.<\/p>\n
A prop\u00f3sito: Este \u00e9 um caso em que o problema do bloco de capa n\u00e3o aplicar nossos nomes de classe personalizados no editor \u00e9 realmente um benef\u00edcio! Imagine se tivesse; ent\u00e3o seria imposs\u00edvel para o usu\u00e1rio editar o bloco no editor se ele tiver uma tela pequena!<\/p>\n
Como mencionado anteriormente, h\u00e1 tr\u00eas etapas para as quais precisamos codificar. Tamb\u00e9m precisamos adicionar algum PHP para enfileirar nosso arquivo Javascript no editor. Vamos fazer isso primeiro.<\/p>\n
Adicionando nosso script ao editor<\/h3>\n
Conectamos uma fun\u00e7\u00e3o \u00e0 a\u00e7\u00e3o [enqueue_block_editor_assets](https:\/\/developer.wordpress.org\/reference\/hooks\/enqueue_block_editor_assets\/)<\/code>. Dentro de nossa fun\u00e7\u00e3o n\u00f3s enfileiramos um script, assim como normalmente far\u00edamos no 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>\nLembre-se de ajustar o caminho para onde seu script est\u00e1! Nota: Se voc\u00ea estiver escrevendo em ES6 com webpack compilando seu Javascript, lembre-se de definir o caminho para a constru\u00e7\u00e3o do seu script, n\u00e3o a fonte.<\/p>\n
Eu gosto de adicionar ‘ wp-edit-post<\/code>‘ como uma depend\u00eancia ao script para garantir que ele carregue tarde o suficiente.<\/p>\nIsso \u00e9 todo o PHP que precisamos fazer. O resto est\u00e1 escrito em nosso arquivo Javascript.<\/p>\n
Adicionar um atributo personalizado<\/h3>\n
O primeiro filtro que usaremos \u00e9 qual o objeto de configura\u00e7\u00f5es dos blocks.registerBlockType<\/code>filtros .registerBlockType<\/code><\/p>\nMas primeiro, um pouco sobre como adicionar filtros em Javascript. Como n\u00e3o encontrei nenhuma documenta\u00e7\u00e3o boa para isso, vou explicar um pouco aqui. A fun\u00e7\u00e3o addFilter<\/code>est\u00e1 no wp.hooks<\/code>namespace e aceita quatro argumentos.<\/p>\naddFilter('hookName', 'namespace', 'functionName', 'priority');<\/code><\/p>\nO primeiro par\u00e2metro, ‘hookName’, \u00e9 o nome do filtro ao qual queremos nos conectar. Este \u00e9 o equivalente ao primeiro par\u00e2metro ao usar PHP’s add_filter()<\/code>. O segundo par\u00e2metro, ‘namespace’, \u00e9 um nome de namespace personalizado para seu c\u00f3digo. Isso \u00e9 apenas para evitar a colis\u00e3o de nomes. Voc\u00ea pode definir o que quiser aqui, apenas n\u00e3o use o namespace do WordPress (‘wp’). Use uma forma abreviada de seu nome ou nome do projeto. O terceiro par\u00e2metro, ‘functionName’, \u00e9 a fun\u00e7\u00e3o hooked \u2013 que \u00e9 o mesmo que o add_filter()<\/code>segundo argumento do PHP. E, finalmente, o quarto par\u00e2metro, ‘prioridade’, \u00e9 opcional. Novamente, isso \u00e9 o mesmo que o add_filter()<\/code>terceiro argumento do PHP.<\/p>\nO processo para filtros em Javascript \u00e9 o mesmo que em PHP. Definimos uma fun\u00e7\u00e3o que precisa retornar a vari\u00e1vel filtrada. \u00c0s vezes, a vari\u00e1vel \u00e9 uma string, um objeto ou um componente. Dentro da fun\u00e7\u00e3o, modificamos a vari\u00e1vel conforme acharmos adequado.<\/p>\n
No nosso caso queremos adicionar um novo atributo ao attribute<\/code>objeto do bloco. Chamaremos o novo atributo hideOnMobile<\/code>e definiremos seu tipo como boolean<\/code>. Isso \u00e9 feito assim:<\/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>\nNa linha #3<\/code>, certificamo-nos de segmentar apenas blocos do tipo ‘ core\/cover<\/code>‘. O segundo argumento para blocks.registerBlockType<\/code>filtrar \u00e9 convenientemente o nome do bloco. Em seguida, adicionamos um novo item de objeto ao settings.attributes<\/code>objeto. Por fim, certificamo-nos de retornar a vari\u00e1vel filtrada, settings<\/code>.<\/p>\nNeste ponto, visualmente, nada \u00e9 alterado em Gutenberg. Mas todos os blocos Cover agora t\u00eam um atributo adicional que podemos usar para armazenar nossa configura\u00e7\u00e3o.<\/p>\n
Adicionar configura\u00e7\u00e3o ao Inspetor (painel Avan\u00e7ado)<\/h3>\n
O segundo filtro \u00e9 chamado editor.BlockEdit<\/code>e filtra o componente do bloco edit<\/code>. Este filtro recebe o componente do bloco original BlockEdit<\/code>e retorna um novo componente encapsulado. Precisamos usar wp.compose.createHigherOrderComponent<\/code>para retornar o componente encapsulado.<\/p>\nDentro do nosso componente, certificamo-nos de renderizar o componente encapsulado BlockEdit<\/code>, independentemente. Mas se o bloco for do tipo Cover, tamb\u00e9m conectamos ao componente InspectorAdvancedControls<\/code>(que \u00e9 o painel “Avan\u00e7ado” no Inspector) e adicionamos um arquivo ToggleControl<\/code>. Escrevemos o ToggleControl<\/code>para mostrar o valor e atualizar o atributo personalizado que adicionamos anteriormente, 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\u00e3o se esque\u00e7a de devolver sempre o original BlockEdit<\/code>, o que fazemos na linha #9<\/code>. Na linha #10 verificamos se o tipo do bloco \u00e9 Cover e renderizamos o InspectorAdvancedControls<\/code>componente. Dentro daqui adicionamos um ToggleControl<\/code>, que \u00e9 um controle de entrada que \u00e9 exibido como uma altern\u00e2ncia entre true ou false. Definimos um r\u00f3tulo e conectamos seu valor ao hideOnMobile<\/code>atributo. Se voc\u00ea adicionou configura\u00e7\u00f5es ao Inspetor antes, isso deve ser bastante simples para voc\u00ea.<\/p>\nCom o c\u00f3digo acima, agora devemos obter isso dentro do painel “Avan\u00e7ado” nos blocos Inspector on Cover:<\/p>\n
![\"Adicionar](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d70271f5a.png\")
<\/a><\/p>\nA entrada agora atualizar\u00e1 nosso atributo personalizado hideOnMobile<\/code>. O \u00faltimo passo \u00e9 fazer algo dependendo do valor deste atributo. A partir de agora, o atributo \u00e9 salvo, mas na verdade n\u00e3o afeta nada.<\/p>\nAdicionar uma classe personalizada<\/h3>\n
A etapa final \u00e9 adicionar uma classe personalizada \u00e0 classe do bloco. Fazemos isso com o filtro blocks.getSaveContent.extraProps<\/code>. save<\/code>Este filtro afeta os adere\u00e7os do componente do bloco. Um deles \u00e9 o prop className<\/code>, que sempre ser\u00e1 aplicado no frontend. Simplesmente anexamos nossa classe personalizada depois dela se o atributo for true<\/code>, e depois a retornamos. Decidi adicionar uma classe ‘ hide-on-mobile<\/code>‘, mas voc\u00ea pode cham\u00e1-la como quiser.<\/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>\nEste c\u00f3digo \u00e9 bastante autoexplicativo. Na linha #4<\/code>verificamos se o atributo hideOnMobile<\/code>existe e \u00e9 true<\/code>. Nesse caso, anexamos uma classe personalizada \u00e0 className<\/code>string.<\/p>\nCom todos os tr\u00eas filtros acima, agora devemos obter uma classe personalizada ‘hide-on-mobile’ aplicada ao nosso bloco Cover sempre que a configura\u00e7\u00e3o for ativada.<\/p>\n
![\"Adicionar](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d70343817.png\")
<\/a><\/p>\nTudo o que resta \u00e9 adicionar um pouco de CSS \u00e0 folha de estilo do frontend do seu tema. Algo assim;<\/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>\nExemplo 2: Adicionar painel Inspetor com configura\u00e7\u00e3o de cor de fundo personalizada para bloco Espa\u00e7ador<\/h2>\n
Para o segundo caso de uso, queremos adicionar configura\u00e7\u00f5es de cores personalizadas ao bloco Espa\u00e7ador. Por padr\u00e3o, o bloco Espa\u00e7ador n\u00e3o possui outras configura\u00e7\u00f5es al\u00e9m de sua altura. Vamos supor que queremos adicionar uma cor de fundo que colora a altura total do bloco Espa\u00e7ador. Isso permite que o usu\u00e1rio adicione “faixas” vazias e coloridas dentro de seu conte\u00fado. Nesse caso, queremos adicionar as configura\u00e7\u00f5es de cores em seu pr\u00f3prio painel separado no Inspetor, conforme o comportamento normal esperado para as configura\u00e7\u00f5es de cores.<\/p>\n
Nota: O manuseio de cores \u00e9 um pouco mais complicado, pois precisamos usar um (outro) componente de ordem superior withColors<\/code>. Porque j\u00e1 precisamos implementar um componente de ordem superior no editor.BlockEdit<\/code>que precisamos para compose<\/code>v\u00e1rios componentes. Al\u00e9m disso, precisamos adicionar dois atributos para cada configura\u00e7\u00e3o de cor. Um conter\u00e1 o slug da paleta de cores e o outro conter\u00e1 o c\u00f3digo de cor hexadecimal \u2013 somente se o usu\u00e1rio tiver optado por uma cor personalizada (usado o colorpicker). Esse \u00e9 um comportamento comum ao trabalhar com withColors<\/code>. Eu tenho um <a href="https:\/\/wordpress.mediadoma.com\/pt-pt\/como-adicionar-configuracoes-de-cores-ao-seu-bloco-gutenberg-personalizado\/" title="post que explica como adicionar configura\u00e7\u00f5es de cores e withColors<\/code>em detalhes” >post que explica como adicionar configura\u00e7\u00f5es de cores e withColors<\/code>em detalhes<\/a> se voc\u00ea ficar confuso.<\/p>\nEm segundo lugar, neste caso, nos depararemos com a quest\u00e3o explicada acima; onde n\u00e3o podemos adicionar o estilo inline apropriado ao editor. A solu\u00e7\u00e3o que optei neste caso \u00e9 envolver o bloco Spacer dentro de a div<\/code>no editor e aplicar as classes apropriadas e o estilo inline ao wrapper div<\/code>. Isso torna a cor selecionada vis\u00edvel no editor quando o bloco \u00e9 desmarcado. Ao selecionar o bloco, no entanto, o WordPress adiciona seu pr\u00f3prio plano de fundo cinza claro personalizado ao bloco, cobrindo nossa cor de plano de fundo personalizada. Um CSS para o editor corrigir\u00e1 isso. Vou explicar mais no final.<\/p>\nOs passos s\u00e3o os mesmos do exemplo acima. Enfileiramos nosso script para o editor em PHP primeiro. Ent\u00e3o em Javascript filtramos o attributes<\/code>objeto, o edit<\/code>componente do Espa\u00e7ador e finalmente o save<\/code>componente do Espa\u00e7ador.<\/p>\nAdicionando nosso script ao editor<\/h3>\n
Conectamos uma fun\u00e7\u00e3o \u00e0 a\u00e7\u00e3o [enqueue_block_editor_assets](https:\/\/developer.wordpress.org\/reference\/hooks\/enqueue_block_editor_assets\/)<\/code>. Dentro de nossa fun\u00e7\u00e3o n\u00f3s enfileiramos um script, assim como normalmente far\u00edamos no 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>\nLembre-se de ajustar o caminho ao seu script. Eu gosto de adicionar ‘ wp-edit-post<\/code>‘ como uma depend\u00eancia ao script para garantir que ele carregue tarde o suficiente.<\/p>\nIsso \u00e9 todo o PHP que precisamos fazer. O resto est\u00e1 escrito em nosso arquivo Javascript.<\/p>\n
Adicionar atributos personalizados<\/h3>\n
Como no exemplo acima, adicionamos um filtro blocks.registerBlockType<\/code>para adicionar itens de objeto adicionais ao objeto do bloco attributes<\/code>.<\/p>\nAo trabalhar com withColors<\/code>, precisamos adicionar dois atributos para cada cor. O nome do nosso atributo de cor de fundo \u00e9 backgroundColor<\/code>, o que significa que o segundo atributo deve ser nomeado customBackgroundColor<\/code>. Tudo isso \u00e9 explicado no meu post sobre como lidar com configura\u00e7\u00f5es de cores em Gutenberg<\/a>. Ambos devem ser do tipo string, e aplicados apenas a blocos do tipo 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>\nAdicionar painel ColorSettings ao Inspetor<\/h3>\n
A segunda etapa \u00e9 adicionar um painel de configura\u00e7\u00f5es de cores ao Inspetor para o bloco Espa\u00e7ador filtrando 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>\nPrecisamos usar compose<\/code>para combinar o componente de ordem superior retornado desse filtro e withColors<\/code>. Em outras palavras, n\u00f3s simplesmente envolvemos o componente retornado em withColors<\/code>. Como par\u00e2metro para withColors<\/code>n\u00f3s fornecemos nosso atributo backgroundColor<\/code>.<\/p>\nDentro do componente encapsulado, sempre retornamos BlockEdit<\/code>(linha #9<\/code>e #39<\/code>para blocos espa\u00e7adores). Para blocos do tipo Espa\u00e7ador, tamb\u00e9m conectamos InspectorControls<\/code>para adicionar um PanelColorSettings<\/code>para nossa escolha de cor. Este \u00e9 o procedimento padr\u00e3o de adi\u00e7\u00e3o de configura\u00e7\u00f5es de cores.<\/p>\nNa linha #17 - 34<\/code>geramos manualmente a classe necess\u00e1ria e\/ou o estilo inline. Em seguida, na linha #38<\/code>, adicionamos uma div envolvente BlockEdit<\/code>com essas classes e estilos embutidos.<\/p>\nO resultado \u00e9 um novo painel de configura\u00e7\u00f5es de cores no Inspector for Spacer blocks, totalmente funcional.<\/p>\n
![\"Adicionar](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d7041a66b.png\")
<\/a><\/p>\n![\"Adicionar](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d7052e0c9.gif\")
<\/a><\/p>\n