[add_filter](https:\/\/developer.wordpress.org\/reference\/functions\/add_filter\/)()<\/code>, tenemos la funci\u00f3n de Javascript [addFilter](https:\/\/developer.wordpress.org\/block-editor\/packages\/packages-hooks\/#api-usage)()<\/code>.<\/p>\nEscribir\u00e9 el c\u00f3digo en la sintaxis de Javascript ES6, que requiere un compilador para transformarlo. Puede escribir en la sintaxis de ES5, pero recomiendo ir a ES6\/ESNext. Tengo una publicaci\u00f3n que explica c\u00f3mo configurar un transformador para ES6\/ESNext<\/a>. Tambi\u00e9n asumo que tiene cierta familiaridad con React\/JSX, posiblemente alguna experiencia en c\u00f3mo crear sus propios bloques de Gutenberg personalizados<\/a>.<\/p>\nQu\u00e9 puedes filtrar en los bloques de Gutenberg<\/h2>\n
No hay mucha documentaci\u00f3n en los ganchos y filtros de Gutenberg disponibles. Pero con el prop\u00f3sito de agregar configuraciones personalizadas y aplicarlas de alguna manera a los bloques existentes; esto es lo que he encontrado hasta ahora. Me he centrado en agregar configuraciones simples, no operaciones que requieren cambios dr\u00e1sticos en los componentes o un comportamiento complejo.<\/p>\n
Hay tres pasos para agregar configuraciones personalizadas a los bloques existentes:<\/p>\n
\n- Agregamos un filtro en la
[registerBlockType](https:\/\/developer.wordpress.org\/block-editor\/developers\/block-api\/block-registration\/#registerblocktype)<\/code>matriz de configuraci\u00f3n del bloque existente. Esto nos permite agregar nuevos atributos a la attributes<\/code>matriz, lo que nos permite guardar informaci\u00f3n adicional en el bloque. Necesitamos guardar nuestra configuraci\u00f3n personalizada en alg\u00fan lugar.<\/li>\n- Eng\u00e1nchese al componente del bloque
edit<\/code>(el componente responsable de representar el bloque en el editor). En este gancho podemos conectarnos al Inspector (la barra lateral) y agregar nuestros propios componentes. Podemos agregar una nueva secci\u00f3n\/panel, o podemos conectarnos a la secci\u00f3n "Avanzada" que siempre est\u00e1 presente en todos los bloques. Luego, depende de nosotros representar las entradas de configuraci\u00f3n, como entradas de texto, casillas de verificaci\u00f3n o lo que sea.<\/li>\nsave<\/code>Filtra los accesorios del bloque. Podemos ajustar los accesorios para guardar, que es responsable tanto de guardar el bloque como de mostrarlo en la interfaz (fuera del editor). En nuestro caso, queremos agregar una clase o un estilo en l\u00ednea.<\/li>\n<\/ul>\nPodemos apuntar a bloques espec\u00edficos o apuntar a todos. Siempre tenemos acceso al tipo de bloque en el que estamos.<\/p>\n
Para decirlo en otras palabras: agregamos algunas configuraciones personalizadas en Inspector y las guardamos en atributos personalizados que hemos agregado al bloque. Luego podemos influir en el nombre de la clase del bloque o en el estilo en l\u00ednea (en algunos casos), seg\u00fan los atributos guardados. Con los nombres de clase personalizados, podemos agregar f\u00e1cilmente CSS personalizado que le da un efecto visual a nuestra configuraci\u00f3n.<\/p>\n
Lo que no podemos hacer (\u00bfpor ahora?)<\/h2>\n
Desafortunadamente, hay algunas cosas a las que no podemos acceder con filtros en bloques existentes. En lo que respecta a agregar configuraciones personalizadas simples a los bloques, estas son cosas comunes que no podemos afectar.<\/p>\n
Sin acceso al estilo en l\u00ednea del bloque dentro del editor<\/h3>\n
En casos de configuraciones que afectan el dise\u00f1o de un bloque, necesitamos agregar un estilo en l\u00ednea en el nodo de ajuste del bloque. Solo el nombre de la clase no servir\u00e1. Por ejemplo, si agrega una configuraci\u00f3n de color personalizada y el usuario selecciona un color personalizado (del selector de colores), no puede resolver esto agregando una clase; necesita un estilo en l\u00ednea.<\/p>\n
Desafortunadamente, parece que los bloques predeterminados de WordPress manejan el estilo en l\u00ednea en el editor de forma completamente independiente sin opci\u00f3n de filtrado o "enganche". Mostrar\u00e9 una forma de evitar esto en el \u00faltimo ejemplo a continuaci\u00f3n, pero no es ideal en todos los casos.<\/p>\n
\u00bfPor qu\u00e9 le importa que el bloque se vea diferente en el editor que en la interfaz? El objetivo de Gutenberg es implementar una forma visual de editar contenido donde lo que vemos es en realidad lo que obtenemos. Queremos lograr el mismo aspecto visual tanto en el editor como en la interfaz.<\/p>\n
Algunos bloques no incluyen el nombre de la clase en el editor<\/h3>\n
Como se mencion\u00f3 anteriormente, podemos filtrar el nombre de la clase de ajuste del bloque, ya que se trata de un accesorio que se pasa a todos los bloques de Gutenberg. Pero, desafortunadamente, hay algunos bloques que no aplican la clase del bloque en absoluto en edit<\/code>. Un ejemplo es el bloque Cover. He jugado mucho con los bloques de portada como "secciones" para las portadas, y sigo teniendo problemas porque el bloque de portada crea su propia clase dentro de edit<\/code>. Se salta por completo incluir la clase \u00abglobal" del bloque (que es a la que tenemos acceso a trav\u00e9s de filtros).<\/p>\nPero al menos podemos estar seguros de que los nombres de clase filtrados siempre se aplican en save<\/code>(frontend). Esto sucede autom\u00e1ticamente fuera del c\u00f3digo espec\u00edfico de cada bloque.<\/p>\nSi me equivoco acerca de cualquiera de los anteriores, \u00a1POR FAVOR h\u00e1gamelo saber en los comentarios a continuaci\u00f3n! Estoy continuamente aprendiendo Gutenberg y, al mismo tiempo, Gutenberg tambi\u00e9n evoluciona. Espero que en alg\u00fan momento lo anterior sea posible en alg\u00fan momento o que sea posible, \u00a1pero solo me falta informaci\u00f3n crucial!<\/p>\n
Con eso fuera del camino, comencemos a buscar algo de c\u00f3digo.<\/p>\n
Ejemplo 1: agregue un campo de alternancia para ocultar un bloque de portada en un dispositivo m\u00f3vil<\/h2>\n
Supongamos que estamos desarrollando un tema en el que los bloques de portada se utilizar\u00e1n para las "secciones" en la p\u00e1gina principal. Y queremos brindarle al usuario la posibilidad de ocultar una determinada secci\u00f3n del dispositivo m\u00f3vil. Para resolver esto, podemos agregar un campo de alternancia en la secci\u00f3n "Avanzado" en el Inspector del bloque Portada. Si el campo est\u00e1 activado, el bloque Portada obtendr\u00e1 una clase personalizada adicional a la que podemos apuntar con CSS y consultas de medios.<\/p>\n
Por cierto: \u00a1este es un caso en el que el problema de que el bloque de portada no aplica nuestros nombres de clase personalizados en el editor es realmente un beneficio! Imag\u00ednese si lo hiciera; \u00a1entonces ser\u00eda imposible para el usuario editar el bloque en el editor si tiene una pantalla peque\u00f1a!<\/p>\n
Como se mencion\u00f3 anteriormente, hay tres pasos que debemos codificar. Tambi\u00e9n necesitamos agregar algo de PHP para poner en cola nuestro archivo Javascript en el editor. Hagamos eso primero.<\/p>\n
Agregando nuestro script al editor<\/h3>\n
Enganchamos una funci\u00f3n a la acci\u00f3n [enqueue_block_editor_assets](https:\/\/developer.wordpress.org\/reference\/hooks\/enqueue_block_editor_assets\/)<\/code>. Dentro de nuestra funci\u00f3n, ponemos en cola un script, tal como lo har\u00edamos normalmente en 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>\n\u00a1Recuerde ajustar la ruta a donde est\u00e1 su secuencia de comandos! Nota: si est\u00e1 escribiendo en ES6 con un paquete web compilando su Javascript, recuerde establecer la ruta a la compilaci\u00f3n de su secuencia de comandos, no la fuente.<\/p>\n
Me gusta agregar ‘ wp-edit-post<\/code>‘ como una dependencia al script para asegurar que se cargue lo suficientemente tarde.<\/p>\nEso es todo el PHP que necesitamos hacer. El resto est\u00e1 escrito en nuestro archivo Javascript.<\/p>\n
Agregar un atributo personalizado<\/h3>\n
El primer filtro que usaremos es el objeto de configuraci\u00f3n de los blocks.registerBlockType<\/code>filtros .registerBlockType<\/code><\/p>\nPero primero, un poco sobre agregar filtros en Javascript. Como no he encontrado ninguna buena documentaci\u00f3n para esto, lo explicar\u00e9 un poco aqu\u00ed. La funci\u00f3n addFilter<\/code>est\u00e1 en el espacio de wp.hooks<\/code>nombres y acepta cuatro argumentos.<\/p>\naddFilter('hookName', 'namespace', 'functionName', 'priority');<\/code><\/p>\nEl primer par\u00e1metro, ‘hookName’, es el nombre del filtro al que queremos engancharnos. Este es el equivalente al primer par\u00e1metro cuando se usa PHP add_filter()<\/code>. El segundo par\u00e1metro, ‘espacio de nombres’, es un nombre de espacio de nombres personalizado para su c\u00f3digo. Esto es solo para evitar la colisi\u00f3n de nombres. Puede configurar pr\u00e1cticamente cualquier cosa que desee aqu\u00ed, simplemente no use el espacio de nombres de WordPress (‘wp’). Utilice una forma abreviada de su nombre o nombre del proyecto. El tercer par\u00e1metro, ‘functionName’, es la funci\u00f3n enganchada, que es lo mismo que el add_filter()<\/code>segundo argumento de PHP. Y finalmente el cuarto par\u00e1metro, ‘prioridad’, es opcional. Nuevamente, esto es lo mismo que el add_filter()<\/code>tercer argumento de PHP.<\/p>\nEl proceso de filtros en Javascript es el mismo que en PHP. Definimos una funci\u00f3n que necesita devolver la variable filtrada. A veces, la variable es una cadena, un objeto o un componente. Dentro de la funci\u00f3n modificamos la variable como mejor nos parezca.<\/p>\n
En nuestro caso, queremos agregar un nuevo atributo al attribute<\/code>objeto del bloque. Llamaremos al nuevo atributo hideOnMobile<\/code>y estableceremos su tipo en boolean<\/code>. Esto se hace as\u00ed:<\/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>\nEn la l\u00ednea #3<\/code>, nos aseguramos de apuntar solo a bloques de tipo ‘ core\/cover<\/code>‘. El segundo argumento para blocks.registerBlockType<\/code>filtrar es convenientemente el nombre del bloque. Luego agregamos un nuevo elemento de objeto al settings.attributes<\/code>objeto. Finalmente nos aseguramos de devolver la variable filtrada, settings<\/code>.<\/p>\nEn este punto visualmente nada ha cambiado en Gutenberg. Pero todos los bloques Cover ahora tienen un atributo adicional que podemos usar para almacenar nuestra configuraci\u00f3n.<\/p>\n
Agregar configuraci\u00f3n a Inspector (panel Avanzado)<\/h3>\n
El segundo filtro se llama y filtra el componente editor.BlockEdit<\/code>del bloque. edit<\/code>Este filtro recibe el componente del bloque original BlockEdit<\/code>y devuelve un nuevo componente envuelto. Necesitamos usar wp.compose.createHigherOrderComponent<\/code>para devolver el componente envuelto.<\/p>\nDentro de nuestro componente, nos aseguramos de representar el componente envuelto BlockEdit<\/code>, independientemente. Pero si el bloque es de tipo Cover, tambi\u00e9n enganchamos el componente InspectorAdvancedControls<\/code>(que es el panel "Avanzado" en Inspector) y agregamos un archivo ToggleControl<\/code>. Escribimos ToggleControl<\/code>para mostrar el valor y actualizar el atributo personalizado que agregamos 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>\nNo olvides devolver siempre el original BlockEdit<\/code>, cosa que hacemos en line #9<\/code>. En la l\u00ednea #10 verificamos si el tipo de bloque es Cover y renderizamos el InspectorAdvancedControls<\/code>componente. Dentro de aqu\u00ed agregamos un ToggleControl<\/code>, que es un control de entrada que se muestra como un interruptor entre verdadero o falso. Establecemos una etiqueta y conectamos su valor al hideOnMobile<\/code>atributo. Si ha agregado configuraciones a Inspector anteriormente, esto deber\u00eda ser bastante sencillo para usted.<\/p>\nCon el c\u00f3digo anterior, ahora deber\u00edamos obtener esto dentro del panel "Avanzado" en los bloques Inspector on Cover:<\/p>\n
![\"Agregue](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d70271f5a.png\")
<\/a><\/p>\nLa entrada ahora actualizar\u00e1 nuestro atributo personalizado hideOnMobile<\/code>. El \u00faltimo paso es hacer algo dependiendo del valor de este atributo. A partir de ahora, el atributo se guarda, pero en realidad no afecta nada.<\/p>\nAgregar una clase personalizada<\/h3>\n
El paso final es agregar una clase personalizada a la clase del bloque. Esto lo hacemos con el filtro blocks.getSaveContent.extraProps<\/code>. Este filtro afecta a los accesorios del save<\/code>componente del bloque. Uno de ellos es el prop className<\/code>, que siempre se aplicar\u00e1 al frontend. Simplemente agregamos nuestra clase personalizada despu\u00e9s si el atributo era true<\/code>, y luego lo devolvemos. He decidido agregar una clase ‘ hide-on-mobile<\/code>‘, pero puedes llamarla como quieras.<\/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 es bastante autoexplicativo. En l\u00ednea #4<\/code>comprobamos si el atributo hideOnMobile<\/code>existe y es true<\/code>. Si es as\u00ed, agregamos una clase personalizada a la className<\/code>cadena.<\/p>\nCon los tres filtros anteriores, ahora deber\u00edamos aplicar una clase personalizada ‘ocultar en el m\u00f3vil’ a nuestro bloque de portada siempre que la configuraci\u00f3n est\u00e9 activada.<\/p>\n
![\"Agregue](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d70343817.png\")
<\/a><\/p>\nTodo lo que queda es agregar algo de CSS a la hoja de estilo de la interfaz de usuario de su tema. Algo como esto;<\/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>\nEjemplo 2: agregue el panel Inspector con una configuraci\u00f3n de color de fondo personalizada para el bloque espaciador<\/h2>\n
Para el segundo caso de uso, queremos agregar configuraciones de color personalizadas al bloque espaciador. Por defecto, el bloque espaciador no tiene otras configuraciones adem\u00e1s de su altura. Supongamos que queremos agregar un color de fondo que coloree la altura completa del bloque espaciador. Eso permite al usuario agregar "rayas" vac\u00edas y de colores dentro de su contenido. En este caso, queremos agregar la configuraci\u00f3n de color en su propio panel separado en Inspector, seg\u00fan el comportamiento habitual esperado para la configuraci\u00f3n de color.<\/p>\n
Nota: el manejo de los colores es un poco m\u00e1s complicado ya que necesitamos usar un (otro) componente de orden superior withColors<\/code>. Debido a que ya necesitamos implementar un componente de orden superior en el editor.BlockEdit<\/code>que necesitamos compose<\/code>m\u00faltiples componentes. Adem\u00e1s, necesitamos agregar dos atributos para cada configuraci\u00f3n de color. Uno contendr\u00e1 el slug de la paleta de colores y el otro contendr\u00e1 el c\u00f3digo de color hexadecimal, solo si el usuario ha optado por un color personalizado (us\u00f3 el selector de color). Todo esto es un comportamiento com\u00fan cuando se trabaja con withColors<\/code>. Tengo una <a href="https:\/\/wordpress.mediadoma.com\/es\/como-agregar-configuraciones-de-color-a-su-bloque-de-gutenberg-personalizado\/" title="publicaci\u00f3n que explica c\u00f3mo agregar configuraciones de color y withColors<\/code>en detalle\u00bb >publicaci\u00f3n que explica c\u00f3mo agregar configuraciones de color y withColors<\/code>en detalle<\/a> si te confundes.<\/p>\nEn segundo lugar, en este caso nos encontraremos con el problema explicado anteriormente; donde no podemos agregar el estilo en l\u00ednea apropiado al editor. La soluci\u00f3n por la que he optado en este caso es envolver el bloque espaciador dentro de un div<\/code>en el editor y aplicar las clases adecuadas y el estilo en l\u00ednea al envoltorio div<\/code>. Esto hace que el color seleccionado sea visible en el editor cuando el bloque no est\u00e1 seleccionado. Sin embargo, al seleccionar el bloque, WordPress agrega su propio fondo gris claro personalizado al bloque, cubriendo nuestro color de fondo personalizado. Un CSS al editor arreglar\u00e1 esto. Explicar\u00e9 m\u00e1s al final.<\/p>\nLos pasos son los mismos que en el ejemplo anterior. Encolamos nuestro script al editor en PHP primero. Luego en Javascript filtramos el attributes<\/code>objeto, el edit<\/code>componente de Spacer y finalmente el save<\/code>componente de Spacer.<\/p>\nAgregando nuestro script al editor<\/h3>\n
Enganchamos una funci\u00f3n a la acci\u00f3n [enqueue_block_editor_assets](https:\/\/developer.wordpress.org\/reference\/hooks\/enqueue_block_editor_assets\/)<\/code>. Dentro de nuestra funci\u00f3n, ponemos en cola un script, tal como lo har\u00edamos normalmente en 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>\nRecuerde ajustar la ruta a su script. Me gusta agregar ‘ wp-edit-post<\/code>‘ como una dependencia al script para asegurar que se cargue lo suficientemente tarde.<\/p>\nEso es todo el PHP que necesitamos hacer. El resto est\u00e1 escrito en nuestro archivo Javascript.<\/p>\n
Agregar atributos personalizados<\/h3>\n
Como en el ejemplo anterior, agregamos un filtro blocks.registerBlockType<\/code>para agregar elementos de objetos adicionales al objeto del bloque attributes<\/code>.<\/p>\nCuando trabajamos con withColors<\/code>necesitamos agregar dos atributos para cada color. El nombre de nuestro atributo de color de fondo es backgroundColor<\/code>, lo que significa que el segundo atributo debe tener el nombre customBackgroundColor<\/code>. Todo esto se explica en mi publicaci\u00f3n sobre el manejo de la configuraci\u00f3n de color en Gutenberg<\/a>. Ambos deben ser de tipo string, y solo aplicados a bloques de 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>\nAgregue el panel ColorSettings al Inspector<\/h3>\n
El segundo paso es agregar un panel de configuraci\u00f3n de color al Inspector para el bloque espaciador 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>\nNecesitamos usar compose<\/code>para combinar el componente de orden superior devuelto por este filtro y withColors<\/code>. En otras palabras, simplemente envolvemos el componente devuelto en withColors<\/code>. Como par\u00e1metro withColors<\/code>proporcionamos nuestro atributo backgroundColor<\/code>.<\/p>\nDentro del componente envuelto nos aseguramos de regresar siempre BlockEdit<\/code>(l\u00ednea #9<\/code>y #39<\/code>para bloques espaciadores). Para el bloque de tipo espaciador, tambi\u00e9n enganchamos InspectorControls<\/code>para agregar un PanelColorSettings<\/code>para nuestra elecci\u00f3n de color. Este es el procedimiento est\u00e1ndar para agregar configuraciones de color.<\/p>\nEn l\u00ednea #17 - 34<\/code>generamos manualmente la clase necesaria y\/o el estilo en l\u00ednea. Luego, en la l\u00ednea #38<\/code>, agregamos un div envolvente BlockEdit<\/code>con esas clases y estilos en l\u00ednea.<\/p>\nEl resultado es un nuevo panel de configuraci\u00f3n de color en Inspector para bloques espaciadores, totalmente funcional.<\/p>\n
![\"Agregue](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d7041a66b.png\")
<\/a><\/p>\n![\"Agregue](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d7052e0c9.gif\")
<\/a><\/p>\n