[add_filter](https:\/\/developer.wordpress.org\/reference\/functions\/add_filter\/)()<\/code>funzione di PHP, abbiamo la funzione Javascript [addFilter](https:\/\/developer.wordpress.org\/block-editor\/packages\/packages-hooks\/#api-usage)()<\/code>.<\/p>\nScriver\u00f2 il codice nella sintassi Javascript ES6, che richiede un compilatore per trasformarlo. Puoi scrivere con la sintassi ES5 ma ti consiglio di usare ES6\/ESNext. Ho un post che spiega come configurare un trasformatore per ES6\/ESNext<\/a>. Presumo anche che tu abbia una certa familiarit\u00e0 con React\/JSX, forse una certa esperienza su come creare i tuoi blocchi Gutenberg personalizzati<\/a>.<\/p>\nCosa puoi filtrare sui blocchi di Gutenberg<\/h2>\n
Non c’\u00e8 molta documentazione negli hook e nei filtri Gutenberg disponibili. Ma allo scopo di aggiungere impostazioni personalizzate e in qualche modo applicarle ai blocchi esistenti; questo \u00e8 quello che ho trovato finora. Mi sono concentrato sull’aggiunta di impostazioni semplici, non su operazioni che richiedono modifiche drastiche dei componenti o comportamenti complessi.<\/p>\n
Ci sono tre passaggi per aggiungere impostazioni personalizzate ai blocchi esistenti:<\/p>\n
\n- Aggiungiamo un filtro
[registerBlockType](https:\/\/developer.wordpress.org\/block-editor\/developers\/block-api\/block-registration\/#registerblocktype)<\/code>sull’array delle impostazioni del blocco esistente. Questo ci consente di aggiungere nuovi attributi attributes<\/code>all’array, consentendoci cos\u00ec di salvare informazioni aggiuntive sul blocco. Dobbiamo salvare la nostra impostazione personalizzata da qualche parte.<\/li>\n- Aggancia al componente del blocco
edit<\/code>(il componente responsabile del rendering del blocco nell’editor). In questo gancio possiamo agganciarci all’Inspector (la barra laterale) e aggiungere i nostri componenti. Possiamo aggiungere una nuova sezione\/riquadro o agganciarci alla sezione "Avanzate" che \u00e8 sempre presente in tutti i blocchi. Poi sta a noi renderizzare gli input delle impostazioni, come input di testo, caselle di controllo o quant’altro.<\/li>\nsave<\/code>Filtra gli oggetti di scena del blocco. Possiamo regolare gli oggetti di scena per il salvataggio, che \u00e8 responsabile sia del salvataggio del blocco che del rendering nel frontend (al di fuori dell’editor). Nel nostro caso vogliamo aggiungere una classe o uno stile inline.<\/li>\n<\/ul>\nPossiamo prendere di mira blocchi specifici o tutti. Abbiamo sempre accesso al tipo di blocco in cui ci troviamo.<\/p>\n
Per dirlo in altre parole: aggiungiamo alcune impostazioni personalizzate in Inspector e le salviamo negli attributi personalizzati che abbiamo aggiunto al blocco. Possiamo quindi influenzare il nome della classe del blocco o lo stile inline (in alcuni casi), a seconda degli attributi salvati. Con i nomi delle classi personalizzate possiamo aggiungere facilmente CSS personalizzati che danno visivamente un effetto alle nostre impostazioni.<\/p>\n
Cosa non possiamo fare (per ora?)<\/h2>\n
Sfortunatamente ci sono alcune cose a cui non possiamo accedere con i filtri sui blocchi esistenti. Per quanto riguarda l’aggiunta di semplici impostazioni personalizzate ai blocchi, queste sono cose comuni che non possiamo influenzare.<\/p>\n
Nessun accesso allo stile in linea del blocco all’interno dell’editor<\/h3>\n
Nei casi in cui le impostazioni influiscono sul design di un blocco, \u00e8 necessario aggiungere uno stile in linea sul nodo di wrapping del blocco. Solo il nome della classe non va bene. Ad esempio, se aggiungi un’impostazione di colore personalizzata e l’utente seleziona un colore personalizzato (da colorpicker), non puoi risolverlo aggiungendo una classe: hai bisogno di uno stile in linea.<\/p>\n
Sfortunatamente sembra che i blocchi predefiniti di WordPress gestiscano lo stile inline nell’editor in modo completamente indipendente senza alcuna opzione di filtraggio o "aggancio". Mostrer\u00f2 un modo per aggirare questo problema nell’ultimo esempio di seguito, ma non \u00e8 l’ideale in tutti i casi.<\/p>\n
Perch\u00e9 importa che il blocco appaia in modo diverso nell’editor rispetto al frontend, potresti chiedere? Il punto centrale di Gutenberg \u00e8 implementare un modo visivo per modificare i contenuti in cui ci\u00f2 che vediamo \u00e8 effettivamente ci\u00f2 che otteniamo. Vogliamo ottenere lo stesso aspetto visivo sia nell’editor che nel frontend.<\/p>\n
Alcuni blocchi non includono il nome della classe nell’editor<\/h3>\n
Come accennato in precedenza, possiamo filtrare il nome della classe di wrapping del blocco poich\u00e9 si tratta di un oggetto che viene passato a tutti i blocchi Gutenberg. Ma sfortunatamente ci sono alcuni blocchi che non applicano affatto la classe del blocco in edit<\/code>. Un esempio \u00e8 il blocco Cover. Ho giocato molto usando i blocchi Cover come "sezioni" per le prime pagine e continuo a riscontrare problemi perch\u00e9 il blocco Cover crea la propria classe all’interno edit<\/code>. Salta completamente la classe "globale" del blocco (che \u00e8 quella a cui abbiamo accesso tramite i filtri).<\/p>\nMa almeno possiamo essere sicuri che i nomi delle classi filtrati vengono sempre applicati in save<\/code>(frontend). Ci\u00f2 avviene automaticamente al di fuori del codice specifico di ogni blocco.<\/p>\nSe sbaglio su qualcuno di quanto sopra, PER FAVORE fatemelo sapere nei commenti qui sotto! Sto imparando continuamente Gutenberg e allo stesso tempo anche Gutenberg si evolve. Spero che a un certo punto quanto sopra sar\u00e0 possibile a un certo punto o che sia possibile, ma mi mancano solo alcune informazioni cruciali!<\/p>\n
Detto questo, iniziamo a esaminare un po’ di codice.<\/p>\n
Esempio 1: aggiungi un campo di attivazione\/disattivazione per nascondere un blocco Cover su dispositivo mobile<\/h2>\n
Supponiamo di sviluppare un tema in cui i blocchi di copertina verranno utilizzati per le "sezioni" sulla prima pagina. E vogliamo fornire all’utente la possibilit\u00e0 di nascondere una determinata sezione dal cellulare. Per risolvere questo problema, possiamo aggiungere un campo di attivazione\/disattivazione nella sezione "Avanzate" nell’Inspector del blocco Cover. Se il campo \u00e8 attivato, il blocco Cover ricever\u00e0 una classe personalizzata aggiuntiva che possiamo indirizzare con CSS e media query.<\/p>\n
A proposito: questo \u00e8 un caso in cui il problema del blocco Cover che non applica i nostri nomi di classe personalizzati nell’editor \u00e8 effettivamente un vantaggio! Immagina se lo facesse; quindi sarebbe impossibile per l’utente modificare il blocco nell’editor se ha uno schermo piccolo!<\/p>\n
Come accennato in precedenza, ci sono tre passaggi per i quali dobbiamo programmare. Abbiamo anche bisogno di aggiungere del PHP per accodare il nostro file Javascript all’editor. Facciamolo prima.<\/p>\n
Aggiunta del nostro script all’editor<\/h3>\n
Agganciamo una funzione all’azione [enqueue_block_editor_assets](https:\/\/developer.wordpress.org\/reference\/hooks\/enqueue_block_editor_assets\/)<\/code>. All’interno della nostra funzione accodiamo uno script, proprio come faremmo normalmente in 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>\nRicorda di modificare il percorso in cui si trova il tuo script! Nota: se stai scrivendo in ES6 con webpack compilando il tuo Javascript, ricorda di impostare il percorso per la build del tuo script, non il sorgente.<\/p>\n
Mi piace aggiungere ‘ wp-edit-post<\/code>‘ come dipendenza allo script per assicurarmi che venga caricato abbastanza tardi.<\/p>\nQuesto \u00e8 tutto il PHP che dobbiamo fare. Il resto \u00e8 scritto nel nostro file Javascript.<\/p>\n
Aggiungi un attributo personalizzato<\/h3>\n
Il primo filtro che useremo \u00e8 l’oggetto delle impostazioni di blocks.registerBlockType<\/code>quali filtri .registerBlockType<\/code><\/p>\nMa prima, un po’ sull’aggiunta di filtri in Javascript. Dal momento che non ho trovato alcuna buona documentazione per questo, lo spiegher\u00f2 un po ‘qui. La funzione addFilter<\/code>si trova nello spazio dei wp.hooks<\/code>nomi e accetta quattro argomenti.<\/p>\naddFilter('hookName', 'namespace', 'functionName', 'priority');<\/code><\/p>\nIl primo parametro, ‘hookName’, \u00e8 il nome del filtro a cui vogliamo agganciarci. Questo \u00e8 l’equivalente del primo parametro quando si utilizza PHP add_filter()<\/code>. Il secondo parametro, ‘namespace’, \u00e8 uno spazio dei nomi personalizzato per il codice. Questo \u00e8 solo per evitare la collisione dei nomi. Puoi praticamente impostare tutto ci\u00f2 che vuoi qui, ma non usare lo spazio dei nomi di WordPress ("wp"). Usa una forma abbreviata del tuo nome o del nome del progetto. Il terzo parametro, ‘functionName’, \u00e8 la funzione agganciata, che \u00e8 la stessa del add_filter()<\/code>secondo argomento di PHP. E infine il quarto parametro, ‘priorit\u00e0’, \u00e8 facoltativo. Ancora una volta, questo \u00e8 lo stesso del add_filter()<\/code>terzo argomento di PHP.<\/p>\nIl processo per i filtri in Javascript \u00e8 lo stesso di PHP. Definiamo una funzione che deve restituire la variabile filtrata. A volte la variabile \u00e8 una stringa, un oggetto o un componente. All’interno della funzione modifichiamo la variabile come meglio crediamo.<\/p>\n
Nel nostro caso vogliamo aggiungere un nuovo attributo attribute<\/code>all’oggetto del blocco. Chiameremo il nuovo attributo hideOnMobile<\/code>e imposteremo il suo tipo su boolean<\/code>. Questo \u00e8 fatto in questo modo:<\/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>\nIn linea #3<\/code>ci assicuriamo di indirizzare solo i blocchi di tipo ‘ core\/cover<\/code>‘. Il secondo argomento da blocks.registerBlockType<\/code>filtrare \u00e8 abbastanza convenientemente il nome del blocco. Quindi aggiungiamo un nuovo oggetto oggetto settings.attributes<\/code>all’oggetto. Infine ci assicuriamo di restituire la variabile filtrata, settings<\/code>.<\/p>\nA questo punto visivamente nulla \u00e8 cambiato in Gutenberg. Ma tutti i blocchi Cover ora hanno un attributo aggiuntivo che possiamo usare per memorizzare le nostre impostazioni.<\/p>\n
Aggiungi impostazione a Impostazioni (pannello Avanzate)<\/h3>\n
Il secondo filtro viene chiamato editor.BlockEdit<\/code>e filtra il componente del blocco edit<\/code>. Questo filtro riceve il componente del blocco originale BlockEdit<\/code>e restituisce un nuovo componente avvolto. Dobbiamo usare wp.compose.createHigherOrderComponent<\/code>per restituire il componente avvolto.<\/p>\nAll’interno del nostro componente ci assicuriamo di eseguire il rendering del componente avvolto BlockEdit<\/code>, a prescindere. Ma se il blocco \u00e8 di tipo Cover ci agganciamo anche al componente InspectorAdvancedControls<\/code>(che \u00e8 il pannello “Avanzate" in Inspector) e aggiungiamo un ToggleControl<\/code>. Scriviamo ToggleControl<\/code>per mostrare il valore e aggiornare l’attributo personalizzato che abbiamo aggiunto in precedenza, 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>\nNon dimenticare di restituire sempre l’originale BlockEdit<\/code>, cosa che facciamo in linea #9<\/code>. Alla riga #10 controlliamo se il tipo di blocco \u00e8 Cover e renderizziamo il InspectorAdvancedControls<\/code>componente. All’interno qui aggiungiamo un ToggleControl<\/code>, che \u00e8 un controllo di input che viene visualizzato come alternanza tra true o false. Impostiamo un’etichetta e colleghiamo il suo valore hideOnMobile<\/code>all’attributo. Se hai gi\u00e0 aggiunto impostazioni a Inspector, questo dovrebbe essere abbastanza semplice per te.<\/p>\nCon il codice sopra, ora dovremmo ottenerlo all’interno del pannello "Avanzate" in Inspector sui blocchi di copertina:<\/p>\n
![\"Aggiungi](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d70271f5a.png\")
<\/a><\/p>\nL’input aggiorner\u00e0 ora il nostro attributo personalizzato hideOnMobile<\/code>. L’ultimo passaggio consiste nel fare qualcosa che dipende dal valore di questo attributo. A partire da ora, l’attributo \u00e8 salvato, ma in realt\u00e0 non influisce su nulla.<\/p>\nAggiungi una classe personalizzata<\/h3>\n
Il passaggio finale consiste nell’aggiungere una classe personalizzata alla classe del blocco. Lo facciamo con il filtro blocks.getSaveContent.extraProps<\/code>. Questo filtro influisce sugli oggetti di scena del componente del blocco save<\/code>. Uno di questi \u00e8 il prop className<\/code>, che sar\u00e0 sempre applicato al frontend. Aggiungiamo semplicemente la nostra classe personalizzata dopo di essa se l’attributo era true<\/code>, quindi la restituiamo. Ho deciso di aggiungere una classe ‘ hide-on-mobile<\/code>‘ ‘, ma puoi chiamarla come preferisci.<\/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>\nQuesto codice \u00e8 abbastanza autoesplicativo. Alla riga #4<\/code>controlliamo se l’attributo hideOnMobile<\/code>esiste ed \u00e8 true<\/code>. In tal caso, aggiungiamo una classe personalizzata alla className<\/code>stringa.<\/p>\nCon tutti e tre i filtri precedenti, ora dovremmo ottenere una classe personalizzata "hide-on-mobile" applicata al nostro blocco Cover ogni volta che l’impostazione \u00e8 attivata.<\/p>\n
![\"Aggiungi](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d70343817.png\")
<\/a><\/p>\nNon resta che aggiungere un po’ di CSS al foglio di stile del frontend del tuo tema. Qualcosa come questo;<\/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>\nEsempio 2: aggiungi il pannello Impostazioni con l’impostazione del colore di sfondo personalizzata per il blocco spaziatore<\/h2>\n
Per il secondo caso d’uso, vogliamo aggiungere impostazioni di colore personalizzate al blocco Spacer. Per impostazione predefinita, il blocco Spacer non ha altre impostazioni oltre alla sua altezza. Supponiamo di voler aggiungere un colore di sfondo che colori l’intera altezza del blocco Spacer. Ci\u00f2 consente all’utente di aggiungere "strisce" vuote e colorate all’interno del proprio contenuto. In questo caso vogliamo aggiungere le impostazioni del colore nel proprio pannello separato in Inspector, come al solito comportamento previsto per le impostazioni del colore.<\/p>\n
Nota: la gestione dei colori \u00e8 un po’ pi\u00f9 complicata in quanto \u00e8 necessario utilizzare un (altro) componente di ordine superiore withColors<\/code>. Poich\u00e9 abbiamo gi\u00e0 bisogno di implementare un componente di ordine superiore nel editor.BlockEdit<\/code>abbiamo bisogno di compose<\/code>pi\u00f9 componenti. Inoltre, dobbiamo aggiungere due attributi per ciascuna impostazione del colore. Uno conterr\u00e0 lo slug della tavolozza dei colori e l’altro conterr\u00e0 il codice colore esadecimale, solo se l’utente ha optato per un colore personalizzato (utilizzato il colorpicker). Questo \u00e8 un comportamento comune quando si lavora con withColors<\/code>. Ho un <a href="https:\/\/wordpress.mediadoma.com\/it\/come-aggiungere-le-impostazioni-del-colore-al-tuo-blocco-gutenberg-personalizzato\/" title="post che spiega l'aggiunta delle impostazioni del colore e withColors<\/code>in dettaglio” >post che spiega l’aggiunta delle impostazioni del colore e withColors<\/code>in dettaglio<\/a> se ti confondi.<\/p>\nIn secondo luogo, in questo caso ci imbatteremo nel problema spiegato sopra; dove non possiamo aggiungere lo stile inline appropriato all’editor. La soluzione che ho scelto in questo caso \u00e8 racchiudere il blocco Spacer all’interno di div<\/code>a nell’editor e applicare le classi e lo stile inline appropriati al wrapping div<\/code>. Ci\u00f2 rende il colore selezionato visibile nell’editor quando il blocco \u00e8 deselezionato. Dopo aver selezionato il blocco, tuttavia, WordPress aggiunge il proprio sfondo grigio chiaro personalizzato al blocco, coprendo il nostro colore di sfondo personalizzato. Un CSS all’editor risolver\u00e0 questo problema. Spiegher\u00f2 di pi\u00f9 alla fine.<\/p>\nI passaggi sono gli stessi dell’esempio sopra. Prima accodiamo il nostro script all’editor in PHP. Quindi in Javascript filtriamo l’ attributes<\/code>oggetto, il edit<\/code>componente Spacer e infine il save<\/code>componente Spacer.<\/p>\nAggiunta del nostro script all’editor<\/h3>\n
Agganciamo una funzione all’azione [enqueue_block_editor_assets](https:\/\/developer.wordpress.org\/reference\/hooks\/enqueue_block_editor_assets\/)<\/code>. All’interno della nostra funzione accodiamo uno script, proprio come faremmo normalmente in 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>\nRicorda di modificare il percorso del tuo script. Mi piace aggiungere ‘ wp-edit-post<\/code>‘ come dipendenza allo script per assicurarmi che venga caricato abbastanza tardi.<\/p>\nQuesto \u00e8 tutto il PHP che dobbiamo fare. Il resto \u00e8 scritto nel nostro file Javascript.<\/p>\n
Aggiungi attributi personalizzati<\/h3>\n
Come nell’esempio sopra, aggiungiamo un filtro blocks.registerBlockType<\/code>per aggiungere elementi oggetto aggiuntivi all’oggetto del blocco attributes<\/code>.<\/p>\nQuando lavoriamo con withColors<\/code>dobbiamo aggiungere due attributi per ogni colore. Il nome del nostro attributo del colore di sfondo \u00e8 backgroundColor<\/code>, il che significa che il secondo attributo deve essere nominato customBackgroundColor<\/code>. Tutto questo \u00e8 spiegato nel mio post sulla gestione delle impostazioni del colore in Gutenberg<\/a>. Entrambi devono essere di tipo string e applicati solo a blocchi di 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>\nAggiungi il pannello ColorSettings a Impostazioni<\/h3>\n
Il secondo passaggio consiste nell’aggiungere un pannello delle impostazioni del colore all’Inspector per il blocco Spacer 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>\nDobbiamo usare compose<\/code>per combinare il componente di ordine superiore restituito da questo filtro e withColors<\/code>. In altre parole, avvolgiamo semplicemente il componente restituito in withColors<\/code>. Come parametro withColors<\/code>forniamo il nostro attributo backgroundColor<\/code>.<\/p>\nAll’interno del componente avvolto ci assicuriamo di restituire sempre BlockEdit<\/code>(linea #9<\/code>e #39<\/code>per blocchi Spacer). Per il blocco di tipo Spacer ci agganciamo anche InspectorControls<\/code>per aggiungere un PanelColorSettings<\/code>colore per la nostra scelta. Questa \u00e8 la procedura standard per aggiungere le impostazioni del colore.<\/p>\nIn linea #17 - 34<\/code>generiamo manualmente la classe e\/o lo stile inline necessari. Quindi in linea #38<\/code>aggiungiamo un div avvolgente BlockEdit<\/code>con quelle classi e stili inline.<\/p>\nIl risultato \u00e8 un nuovo pannello delle impostazioni del colore in Inspector per i blocchi Spacer, completamente funzionante.<\/p>\n
![\"Aggiungi](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d7041a66b.png\")
<\/a><\/p>\n![\"Aggiungi](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-152421-61e4d7052e0c9.gif\")
<\/a><\/p>\n