Haben Sie sich jemals in der Situation befunden, dass Sie Ihre benutzerdefinierten Einstellungen zu den Gutenberg-Blöcken von WordPress hinzufügen möchten? In diesem Beitrag gehen wir detailliert darauf ein, wie das geht. Sie finden zwei Beispielcodes für Anwendungsfälle aus dem wirklichen Leben beim Hinzufügen benutzerdefinierter Einstellungen zu WordPress-Blöcken.

Denken Sie daran, dass Sie, da Gutenberg-Blöcke Javascript sind, den Code in Javascript schreiben müssen, um sie zu ändern. So wie der PHP-Code von WordPress Hooks und Filter hat, die es Entwicklern von Designs oder Plugins ermöglichen, seinen Code zu ändern, gibt es auch Filter im Javascript-Code von WordPress. Ähnlich wie die PHP- [add_filter](https://developer.wordpress.org/reference/functions/add_filter/)()Funktion haben wir die Javascript-Funktion [addFilter](https://developer.wordpress.org/block-editor/packages/packages-hooks/#api-usage)().

Ich werde den Code in Javascript ES6-Syntax schreiben, was einen Compiler erfordert, um ihn umzuwandeln. Sie können in ES5-Syntax schreiben, aber ich empfehle, sich für ES6/ESNext zu entscheiden. Ich habe einen Beitrag, der erklärt, wie man einen Transformator für ES6/ESNext einrichtet. Ich gehe auch davon aus, dass Sie mit React/JSX vertraut sind, möglicherweise etwas Erfahrung darin, wie Sie Ihre eigenen benutzerdefinierten Gutenberg-Blöcke erstellen.

Was Sie nach Gutenberg-Blöcken filtern können

Es gibt nicht viel Dokumentation in verfügbaren Gutenberg-Hooks und -Filtern. Aber um benutzerdefinierte Einstellungen hinzuzufügen und sie irgendwie auf vorhandene Blöcke anzuwenden; das habe ich bisher gefunden. Ich habe mich darauf konzentriert, einfache Einstellungen hinzuzufügen – nicht Operationen, die drastische Komponentenänderungen oder komplexes Verhalten erfordern.

Es gibt drei Schritte, um benutzerdefinierte Einstellungen zu bestehenden Blöcken hinzuzufügen:

Wir fügen einen Filter zum [registerBlockType](https://developer.wordpress.org/block-editor/developers/block-api/block-registration/#registerblocktype)Einstellungsarray des vorhandenen Blocks hinzu. Dadurch können wir dem attributesArray neue Attribute hinzufügen und so zusätzliche Informationen im Block speichern. Wir müssen unsere benutzerdefinierten Einstellungen irgendwo speichern.
Haken Sie die Komponente des Blocks ein edit(die Komponente, die für das Rendern des Blocks im Editor verantwortlich ist). In diesem Hook können wir uns in den Inspector (die Seitenleiste) einklinken und unsere eigenen Komponenten hinzufügen. Wir können entweder einen neuen Abschnitt/Panel hinzufügen oder uns in den Abschnitt „Erweitert” einklinken, der immer in allen Blöcken vorhanden ist. Dann liegt es an uns, Einstellungseingaben wie Texteingaben, Kontrollkästchen oder so weiter zu rendern.
Filtern Sie die saveRequisiten des Blocks. Wir können die Requisiten für das Speichern anpassen, das sowohl für das Speichern des Blocks als auch für das Rendern im Frontend (außerhalb des Editors) verantwortlich ist. In unserem Fall möchten wir einen Klassen- oder Inline-Stil hinzufügen.

Wir können auf bestimmte Blöcke oder auf alle abzielen. Wir haben immer Zugriff darauf, in welcher Art von Block wir uns befinden.

Mit anderen Worten: Wir fügen einige benutzerdefinierte Einstellungen in Inspector hinzu und speichern sie in benutzerdefinierten Attributen, die wir dem Block hinzugefügt haben. Wir können dann den Klassennamen oder den Inline-Stil des Blocks (in einigen Fällen) abhängig von den gespeicherten Attributen beeinflussen. Mit den benutzerdefinierten Klassennamen können wir ganz einfach benutzerdefiniertes CSS hinzufügen, das unseren Einstellungen visuell einen Effekt verleiht.

Was wir (vorerst) nicht tun können

Leider gibt es einige Dinge, auf die wir mit Filtern auf vorhandene Blöcke nicht zugreifen können. In Bezug auf das Hinzufügen einfacher benutzerdefinierter Einstellungen zu Blöcken sind dies häufige Dinge, auf die wir keinen Einfluss haben.

Kein Zugriff auf den Inline-Stil des Blocks im Editor

In einigen Fällen von Einstellungen, die sich auf das Design eines Blocks auswirken, müssen wir dem Wrapping-Knoten des Blocks einen Inline-Stil hinzufügen. Nur der Klassenname reicht nicht aus. Wenn Sie beispielsweise eine benutzerdefinierte Farbeinstellung hinzufügen und der Benutzer eine benutzerdefinierte Farbe (aus der Farbauswahl) auswählt, können Sie dies nicht lösen, indem Sie eine Klasse hinzufügen – Sie benötigen einen Inline-Stil.

Leider scheinen die Standardblöcke von WordPress den Inline-Stil im Editor völlig unabhängig zu handhaben, ohne die Option zum Filtern oder „Einhängen”. Ich werde im letzten Beispiel unten einen Weg zeigen, dies zu umgehen, aber es ist nicht in allen Fällen ideal.

Warum kümmert es dich, dass der Block im Editor anders aussieht als im Frontend, fragst du dich vielleicht? Der ganze Sinn von Gutenberg besteht darin, eine visuelle Methode zum Bearbeiten von Inhalten zu implementieren, bei der das, was wir sehen, tatsächlich das ist, was wir bekommen. Wir wollen den gleichen visuellen Look sowohl im Editor als auch im Frontend erreichen.

Einige Blöcke enthalten keinen Klassennamen im Editor

Wie oben erwähnt, können wir den Wrapping-Klassennamen des Blocks filtern, da dies eine Eigenschaft ist, die an alle Gutenberg-Blöcke weitergegeben wird. Aber leider gibt es einige Blöcke, die die Klasse des Blocks in überhaupt nicht anwenden edit. Ein Beispiel ist der Cover-Block. Ich habe viel herumgespielt, indem ich Cover-Blöcke als „Abschnitte” für Startseiten verwendet habe, und bin immer wieder auf Probleme gestoßen, weil der Cover-Block seine eigene Klasse darin aufbaut edit. Es überspringt vollständig die Einbeziehung der „globalen” Klasse des Blocks (auf die wir durch Filter zugreifen können).

Aber zumindest können wir sicher sein, dass gefilterte Klassennamen immer im save(Frontend) angewendet werden. Dies geschieht automatisch außerhalb des spezifischen Codes jedes Blocks.

Wenn ich bei einem der oben genannten Punkte falsch liege, lass es mich bitte in den Kommentaren unten wissen! Ich lerne kontinuierlich Gutenberg und gleichzeitig entwickelt sich auch Gutenberg weiter. Ich hoffe, dass das Obige irgendwann möglich sein wird oder dass es möglich ist, aber mir fehlen nur einige entscheidende Informationen!

Lassen Sie uns damit beginnen, uns etwas Code anzusehen.

Beispiel 1: Fügen Sie ein Umschaltfeld hinzu, um einen Cover-Block auf Mobilgeräten auszublenden

Nehmen wir an, wir entwickeln ein Thema, bei dem Cover-Blöcke für „Abschnitte” auf der Titelseite verwendet werden. Und wir möchten dem Benutzer die Möglichkeit geben, einen bestimmten Abschnitt auf dem Handy zu verbergen. Um dies zu lösen, können wir im Abschnitt „Erweitert” im Inspektor des Abdeckblocks ein Umschaltfeld hinzufügen. Wenn das Feld aktiviert ist, erhält der Cover-Block eine zusätzliche benutzerdefinierte Klasse, die wir mit CSS- und Medienabfragen ansprechen können.

Übrigens: Dies ist ein Fall, in dem das Problem, dass der Cover-Block unsere benutzerdefinierten Klassennamen im Editor nicht anwendet, tatsächlich ein Vorteil ist! Stellen Sie sich vor, es wäre so; dann wäre es für den Benutzer unmöglich, den Block im Editor zu bearbeiten, wenn er oder sie einen kleinen Bildschirm hat!

Wie bereits erwähnt, gibt es drei Schritte, für die wir codieren müssen. Wir müssen auch etwas PHP hinzufügen, um unsere Javascript-Datei in den Editor einzureihen. Lassen Sie uns das zuerst tun.

Hinzufügen unseres Skripts zum Editor

Wir hängen eine Funktion an die Aktion an [enqueue_block_editor_assets](https://developer.wordpress.org/reference/hooks/enqueue_block_editor_assets/). Innerhalb unserer Funktion stellen wir ein Skript in die Warteschlange, so wie wir es normalerweise in wp_enqueue_scriptsHook tun würden.


add_action('enqueue_block_editor_assets', function() {
    wp_enqueue_script('awp-gutenberg-filters', get_template_directory_uri(). '/assets/js/gutenberg-filters.js', ['wp-edit-post']);
});

Denken Sie daran, den Pfad an die Stelle Ihres Skripts anzupassen! Hinweis: Wenn Sie in ES6 mit Webpack schreiben, das Ihr Javascript kompiliert, denken Sie daran, den Pfad zum Build Ihres Skripts festzulegen, nicht zur Quelle.

Ich füge wp-edit-postdem Skript gerne „ ” als Abhängigkeit hinzu, um sicherzustellen, dass es spät genug geladen wird.

Das ist alles, was wir für PHP tun müssen. Der Rest wird in unsere Javascript-Datei geschrieben.

Fügen Sie ein benutzerdefiniertes Attribut hinzu

Der erste Filter, den wir verwenden werden, ist blocks.registerBlockTypewhich filtert registerBlockTypedas Einstellungsobjekt von .

Aber zuerst ein bisschen über das Hinzufügen von Filtern in Javascript. Da ich dazu keine gute Dokumentation gefunden habe, erkläre ich es hier ein wenig. Die Funktion addFilterbefindet sich im wp.hooksNamespace und akzeptiert vier Argumente.

addFilter('hookName', 'namespace', 'functionName', 'priority');

Der erste Parameter, „hookName”, ist der Name des Filters, in den wir einklinken möchten. Dies ist das Äquivalent zum ersten Parameter bei Verwendung von PHP add_filter(). Der zweite Parameter, „Namespace”, ist ein benutzerdefinierter Namespace-Name für Ihren Code. Dies dient nur dazu, Namenskollisionen zu vermeiden. Sie können hier so ziemlich alles einstellen, was Sie wollen, verwenden Sie nur nicht den Namensraum von WordPress (‘wp’). Verwenden Sie eine Kurzform Ihres Namens oder Projektnamens. Der dritte Parameter, ‘functionName’, ist die Hook-Funktion – das ist dasselbe wie das add_filter()zweite Argument von PHP. Und schließlich ist der vierte Parameter „priority” optional. Auch dies ist dasselbe wie das add_filter()dritte Argument von PHP.

Der Prozess für Filter in Javascript ist derselbe wie in PHP. Wir definieren eine Funktion, die die gefilterte Variable zurückgeben muss. Manchmal ist die Variable ein String, ein Objekt oder eine Komponente. Innerhalb der Funktion modifizieren wir die Variable nach Belieben.

In unserem Fall möchten wir dem attributeObjekt des Blocks ein neues Attribut hinzufügen. Wir rufen das neue Attribut auf hideOnMobileund setzen seinen Typ auf boolean. Das geht so:


function addCoverAttribute(settings, name) {
    if (typeof settings.attributes !== 'undefined') {
        if (name == 'core/cover') {
            settings.attributes = Object.assign(settings.attributes, {
                hideOnMobile: {
                    type: 'boolean',
                }
            });
        }
    }
    return settings;
}
 
wp.hooks.addFilter(
    'blocks.registerBlockType',
    'awp/cover-custom-attribute',
    addCoverAttribute
);

Bei line #3stellen wir sicher, dass wir nur auf Blöcke vom Typ ‘ core/cover‘ zielen. Das zweite zu blocks.registerBlockTypefilternde Argument ist praktischerweise der Name des Blocks. Dann fügen wir dem settings.attributesObjekt ein neues Objektelement hinzu. Schließlich stellen wir sicher, dass die gefilterte Variable zurückgegeben wird settings.

An dieser Stelle wird optisch nichts an Gutenberg verändert. Aber alle Cover-Blöcke haben jetzt ein zusätzliches Attribut, mit dem wir unsere Einstellung speichern können.

Einstellung zum Inspektor hinzufügen (Erweitert-Bedienfeld)

Der zweite Filter wird aufgerufen und filtert die Komponente editor.BlockEditdes Blocks. editDieser Filter empfängt die BlockEditKomponente des ursprünglichen Blocks und gibt eine neue umschlossene Komponente zurück. Wir müssen verwenden wp.compose.createHigherOrderComponent, um die verpackte Komponente zurückzugeben.

Innerhalb unserer Komponente stellen wir sicher, dass die umschlossene Komponente trotzdem gerendert BlockEditwird. Aber wenn der Block vom Typ Cover ist, hängen wir uns auch an die Komponente InspectorAdvancedControls(das ist das „Advanced”-Panel im Inspector) und fügen eine ToggleControl. Wir schreiben den ToggleControl, um den Wert von anzuzeigen und das zuvor hinzugefügte benutzerdefinierte Attribut zu aktualisieren, hideOnMobile.

Vergessen Sie nicht, immer das Original zurückzusenden BlockEdit, was wir auch tun #9. In Zeile 10 prüfen wir, ob der Typ des Blocks Cover ist, und rendern die InspectorAdvancedControlsKomponente. Hier fügen wir ein hinzu ToggleControl, bei dem es sich um ein Eingabesteuerelement handelt, das als Umschalter zwischen wahr oder falsch angezeigt wird. Wir setzen ein Label und verbinden seinen Wert mit dem hideOnMobileAttribut. Wenn Sie zuvor Einstellungen zu Inspector hinzugefügt haben, sollte dies für Sie ziemlich einfach sein.

Mit dem obigen Code sollten wir dies jetzt im Bereich „Erweitert” in Inspector on Cover blocks erhalten:

Die Eingabe aktualisiert nun unser benutzerdefiniertes Attribut hideOnMobile. Der letzte Schritt besteht darin, abhängig vom Wert dieses Attributs etwas zu tun. Ab sofort wird das Attribut gespeichert, wirkt sich aber nicht wirklich auf irgendetwas aus.

Fügen Sie eine benutzerdefinierte Klasse hinzu

Der letzte Schritt ist das Hinzufügen einer benutzerdefinierten Klasse zur Klasse des Blocks. Das machen wir mit dem Filter blocks.getSaveContent.extraProps. Dieser Filter wirkt sich auf die Requisiten der saveKomponente des Blocks aus. Eine davon ist die Prop className, die immer auf das Frontend angewendet wird. Wir hängen einfach unsere benutzerdefinierte Klasse danach an, wenn das Attribut war true, und geben es dann zurück. Ich habe mich entschieden, eine Klasse ‘ ‘ hinzuzufügen hide-on-mobile, aber Sie können sie nennen, wie Sie möchten.

Dieser Code ist ziemlich selbsterklärend. In Zeile #4prüfen wir, ob das Attribut hideOnMobileexistiert und true. Wenn dies der Fall ist, hängen wir eine benutzerdefinierte Klasse an die classNameZeichenfolge an.

Mit allen oben genannten drei Filtern sollten wir jetzt eine benutzerdefinierte Klasse „Hide-on-Mobile” erhalten, die auf unseren Cover-Block angewendet wird, wenn die Einstellung aktiviert ist.

Alles, was bleibt, ist, dem Frontend-Stylesheet Ihres Themes etwas CSS hinzuzufügen. Etwas wie das;


.wp-block-cover.hide-on-mobile { display: none; }
@media (min-width: 480px) {
    .wp-block-cover.hide-on-mobile { display: block; }
}

Beispiel 2: Inspector-Panel mit benutzerdefinierter Hintergrundfarbeinstellung für Spacer-Block hinzufügen

Für den zweiten Anwendungsfall möchten wir dem Spacer-Block benutzerdefinierte Farbeinstellungen hinzufügen. Standardmäßig hat der Abstandsblock keine anderen Einstellungen außer seiner Höhe. Nehmen wir an, wir möchten eine Hintergrundfarbe hinzufügen, die die volle Höhe des Spacer-Blocks einfärbt. Dadurch kann der Benutzer leere, farbige „Streifen” in seinen Inhalt einfügen. In diesem Fall möchten wir die Farbeinstellungen in einem eigenen separaten Bedienfeld im Inspector hinzufügen, wie es für Farbeinstellungen üblich ist.

Hinweis: Der Umgang mit Farben ist etwas komplizierter, da wir eine (andere) Komponente höherer Ordnung verwenden müssen withColors. Da wir bereits eine Komponente höherer Ordnung implementieren müssen, editor.BlockEditmüssen wir composemehrere Komponenten verwenden. Zusätzlich müssen wir für jede Farbeinstellung zwei Attribute hinzufügen. Einer enthält den Slug der Farbpalette und der andere den Hex-Farbcode – nur wenn der Benutzer sich für eine benutzerdefinierte Farbe entschieden hat (verwendet den Farbwähler). Dies ist alles übliches Verhalten bei der Arbeit mit withColors. Ich habe einen <a href="https://wordpress.mediadoma.com/so-fuegen-sie-farbeinstellungen-zu-ihrem-benutzerdefinierten-gutenberg-block-hinzu/" title="Beitrag, der das Hinzufügen von Farbeinstellungen und withColorsim Detail” >Beitrag, der das Hinzufügen von Farbeinstellungen und withColorsim Detail erklärt, wenn Sie verwirrt sind.

Zweitens werden wir in diesem Fall auf das oben erläuterte Problem stoßen; wo wir den passenden Inline-Stil nicht zum Editor hinzufügen können. Die Lösung, für die ich mich in diesem Fall entschieden habe, besteht darin, den Spacer-Block divim Editor in a einzuschließen und die richtigen Klassen und den richtigen Inline-Stil auf die Umhüllung anzuwenden div. Dadurch wird die ausgewählte Farbe im Editor sichtbar, wenn der Block nicht ausgewählt ist. Bei der Auswahl des Blocks fügt WordPress dem Block jedoch seinen eigenen benutzerdefinierten hellgrauen Hintergrund hinzu, der unsere benutzerdefinierte Hintergrundfarbe abdeckt. Ein CSS für den Editor wird dies beheben. Ich erkläre am Ende mehr.

Die Schritte sind die gleichen wie im obigen Beispiel. Wir reihen unser Skript zuerst in den Editor in PHP ein. Dann filtern wir in Javascript das attributesObjekt, die editKomponente des Spacers und schließlich die saveKomponente des Spacers.

Hinzufügen unseres Skripts zum Editor


add_action('enqueue_block_editor_assets', function() {
    wp_enqueue_script('awp-gutenberg-filters', get_template_directory_uri(). '/assets/js/gutenberg-filters.js', ['wp-edit-post']);
});

Denken Sie daran, den Pfad an Ihr Skript anzupassen. Ich füge wp-edit-postdem Skript gerne „ ” als Abhängigkeit hinzu, um sicherzustellen, dass es spät genug geladen wird.

Das ist alles, was wir für PHP tun müssen. Der Rest wird in unsere Javascript-Datei geschrieben.

Fügen Sie benutzerdefinierte Attribute hinzu

Wie im obigen Beispiel fügen wir einen Filter blocks.registerBlockTypehinzu, um zusätzliche Objektelemente zum Objekt des Blocks hinzuzufügen attributes.

Wenn wir mit arbeiten withColors, müssen wir für jede Farbe zwei Attribute hinzufügen. Der Name unseres Attributs für die Hintergrundfarbe ist backgroundColor, was bedeutet, dass das zweite Attribut benannt werden muss customBackgroundColor. Dies alles wird in meinem Beitrag über den Umgang mit Farbeinstellungen in Gutenberg erklärt. Beide sollten vom Typ String sein und nur auf Blöcke vom Typ Spacer angewendet werden.


function addSpacerAttributes(settings, name) {
    if (typeof settings.attributes !== 'undefined') {
        if (name == 'core/spacer') {
            settings.attributes = Object.assign(settings.attributes, {
                backgroundColor: {
                    type: 'string',
                },
                customBackgroundColor: {
                    type: 'string'
                }
            });
        }
    }
    return settings;
}
 
wp.hooks.addFilter(
    'blocks.registerBlockType',
    'awp/spacer-background-attribute',
    addSpacerAttributes
);

Farbeinstellungen-Bedienfeld zum Inspektor hinzugefügt

Der zweite Schritt ist das Hinzufügen eines Farbeinstellungsfensters zum Inspektor für den Spacer-Block durch Filtern von editor.BlockEdit.

Wir müssen verwenden compose, um die von diesem Filter zurückgegebene Komponente höherer Ordnung und zu kombinieren withColors. Mit anderen Worten, wir packen die zurückgegebene Komponente einfach in withColors. Als Parameter withColorsliefern wir unser Attribut backgroundColor.

Innerhalb des gewickelten Bauteils achten wir darauf, dass es immer zurückkehrt BlockEdit(Linie #9und #39für Abstandsblöcke). Bei Blöcken vom Typ Spacer haken wir auch ein, um unsere Farbauswahl InspectorControlszu ergänzen. PanelColorSettingsDies ist das Standardverfahren zum Hinzufügen von Farbeinstellungen.

Bei line #17 - 34generieren wir manuell den notwendigen Klassen- und/oder Inline-Stil. Dann #38fügen wir bei line ein Wrapping-Div BlockEditmit diesen Klassen und Inline-Stilen hinzu.

Das Ergebnis ist ein neues, voll funktionsfähiges Farbeinstellungsfeld im Inspector für Spacer-Blöcke.

Die Auswahl einer Palettenfarbe oder einer benutzerdefinierten Farbe wird tatsächlich im Wrapping-Div im Editor beeinflusst. Aber Sie können es nur sehen, wenn Sie den Spacer-Block abwählen!

Dies geschieht, weil WordPress bei der Auswahl eines Abstandsblocks sein eigenes Styling anwendet. Wir werden es am Ende beheben, zuerst müssen wir nur die gleiche Klasse und/oder den gleichen Inline-Stil auch im Frontend anwenden.

Fügen Sie zum Speichern eine benutzerdefinierte Klasse und einen Inline-Stil hinzu

Schließlich müssen wir blocks.getSaveContent.extraPropsdie erforderliche Klasse und/oder das Inline-Styling für das Frontend filtern und anwenden. Auch dies ist sehr ähnlich zu dem, was wir in Beispiel 1 oben gemacht haben. Wenn eine Palettenfarbe ausgewählt wurde, müssen wir einen Klassennamen hinzufügen, der den WordPress-Standards für Farbeinstellungen entspricht („ has-<PALETTESLUG>-background-color“). Wenn eine benutzerdefinierte Farbe ausgewählt wurde, müssen wir den Inline-Stil mit der Hex-Farbe hinzufügen.

Hinweis: Wenn Sie häufig mit Klassennamen umgehen müssen, empfehle ich, die classnamesBibliothek zu importieren. Dies wird in Gutenberg stark genutzt, da es das Festlegen der richtigen Klassennamen erheblich vereinfacht. Der folgende Code geht davon aus, dass Sie dies nicht getan haben, und setzt den Klassennamen manuell zusammen.


function applySpacerBackground(props, blockType, attributes) {
    if (blockType.name == 'core/spacer') {
        const { backgroundColor, customBackgroundColor } = attributes;
 
        // For improved class name handling, use classnames library. Or do it manually like..
        let className = (props.className != undefined)? props.className: '';
        if (backgroundColor != undefined) {
            className += ' has-' + backgroundColor + '-background-color';
        }
        props.className = className;
        if (customBackgroundColor != undefined) {
            Object.assign(props, { style: { ...props.style, backgroundColor: customBackgroundColor }});
        }
    }
    return props;
}
 
wp.hooks.addFilter(
    'blocks.getSaveContent.extraProps',
    'awp/spacer-apply-class',
    applySpacerBackground
);

Mit dem obigen Code rendert das Frontend jetzt perfekt Abstandsblöcke mit unserer benutzerdefinierten Farbauswahl!

Die letzte (optionale) Lösung besteht darin, dem Editor etwas CSS hinzuzufügen. Sie müssen entweder Inline-CSS oder ein Editor-Stylesheet hinzufügen. Beispielsweise könnten Sie ein Stylesheet in denselben PHP-Hook einreihen, den wir zum Einreihen unserer Javascript-Datei verwendet haben. Ich werde nicht ins Detail gehen, wie man das macht; aber das CSS, das Sie brauchen, sieht so aus wie das folgende. Alles, was es tut, ist, die Spacer background-colorauf die geerbte Farbe zu setzen (sie wird von unserem Wrapping-Div geerbt), wenn der Block ausgewählt wird:


.block-library-spacer__resize-container.is-selected { 
    background-color: inherit; 
}

PS: Beachten Sie, dass sich dies in Zukunft ändern kann. Gutenberg entwickelt sich immer noch stark.

Fazit

In diesem Beitrag haben wir zwei Methoden zum Implementieren benutzerdefinierter Einstellungen für vorhandene WordPress Gutenberg-Blöcke kennengelernt. Es ist für einfache Einstellungen, die vielleicht nur ein Klassen- oder Inline-Styling erfordern, uneingeschränkt möglich. Wir haben uns die Vorbehalte angesehen, die hoffentlich in späteren Gutenberg-Versionen behoben werden!

Aufnahmequelle: awhitepixel.com