Benutzerdefinierten Gutenberg-Block erstellen – Teil 9: Dynamische Blöcke und PHP-Rendering

Bisher haben wir die Ausgabe des Blocks in Javascript gerendert. Bei dynamischen Inhalten wie aktuellen Beiträgen oder dem Anzeigen eines Beitrags müssen wir jedoch die Ausgabe des Blocks in PHP rendern. In diesem Beitrag erfahren wir, wie und warum.

Warum müssen wir mit dynamischen Blöcken anders umgehen?

Einige Beispiele sind offensichtlich; Ein Block, der die neuesten Beiträge in einer Kategorie anzeigt, ist dynamisch, da sich die Beiträge im Laufe der Zeit ändern. Sie wählen die Posts im Block nicht aus; Stattdessen haben Sie wahrscheinlich Einstellungen zur Auswahl der Kategorie, welche Informationen für die einzelnen Beiträge angezeigt werden sollen, die Anzahl der Beiträge, die Anzahl der Spalten und so weiter. Jedes Mal, wenn WordPress einen Beitrag mit diesem Block lädt, muss es WordPress zu diesem Zeitpunkt nach den neuesten Beiträgen abfragen. Das Anzeigen desselben Beitrags im darauffolgenden Monat kann zu anderen Ergebnissen führen, obwohl der Beitrag mit dem Block selbst nicht aktualisiert wurde.

Aber die Notwendigkeit dynamischer Blöcke ist manchmal nicht so offensichtlich. Sie können sich vorstellen, dass ein Featured-Post-Block, in dem Sie einen bestimmten Post auswählen, um ihn anzuzeigen, nicht unbedingt dynamisch ist. Aber es könnte sein – und sollte es sein. Denken Sie daran, dass der Titel, der Auszug oder das Beitragsbild des ausgewählten Beitrags jederzeit aktualisiert werden kann – und dies sollte sich in den Blöcken widerspiegeln, die diesen Beitrag enthalten.

Um einen nicht dynamischen Block zum Anzeigen eines einzelnen Beitrags zu erstellen, müssen Sie die Beitrags-ID, ihre URL, die URL des vorgestellten Bilds, die Auszugszeichenfolge oder was auch immer Sie für die Vorschau des Beitrags benötigen, in den Attributen des Blocks speichern. Und hier liegt das Problem. Wenn Sie das hervorgehobene Bild des ausgewählten Beitrags aktualisieren, werden die Attribute des Beitrags mit dem hervorgehobenen Beitragsblock nicht automatisch aktualisiert. Es bleibt mit der URL des alten vorgestellten Bildes gespeichert. Nur wenn Sie den Beitrag mit dem Block bearbeiten und sicherstellen, dass die Attribute mit den aktualisierten Informationen erneut gespeichert werden, zeigt der Block die korrekten aktualisierten Informationen an.

Wann immer wir also mit dynamischen Inhalten zu tun haben – Beiträge, Kategorien oder alles, was sich im Laufe der Zeit ändern könnte – haben wir es mit dynamischen Blöcken zu tun. Und für dynamische Blöcke müssen wir PHP – serverseitigen Code – verwenden, um unseren Block zu rendern, um sicherzustellen, dass er bei jedem Rendern aktualisierte Informationen abruft.

Die geänderte Natur dynamischer Blöcke im Editor

Wenn Sie mit der Entwicklung dynamischer Blöcke beginnen, ändert sich die Art Ihres Blocks innerhalb des Editors. Die Funktion Ihres Blocks editmuss oft auch dynamisch sein. Beispielsweise müssen Sie für einen hervorgehobenen Beitragsblock Beiträge abrufen, aus denen Sie auswählen können, oder für einen neuesten Nachrichtenblock müssen Sie eine Liste mit Kategorien abrufen, aus denen der Benutzer auswählen kann.

Es ist vollständig möglich, Informationen von WordPress aus dem Editor heraus anzufordern, indem AJAX-Anforderungen gestellt werden – entweder mithilfe von Paketen und Komponenten oder manuell mit der WordPress-REST-API. Unabhängig von der Methode, für die Sie sich entscheiden, muss Ihr Block den asynchronen Eingabestrom verarbeiten – den Zeitrahmen, während Sie auf eine Antwort warten.

Es gibt mehrere Methoden und Muster, um einen dynamischen Block für Gutenberg zu erstellen. Am häufigsten verwenden Sie ein Reaktionsmuster, das als Komponenten höherer Ordnung bezeichnet wird und für das WordPress zahlreiche Funktionen und Komponenten bereitstellt.

Im nächsten Tutorial-Teil sehen wir uns an, wie Posts und Kategorien in unserem Block abgerufen werden. Im Moment müssen wir lernen, wie wir PHP dazu bringen, unseren Block zu rendern.

Bereiten Sie unseren Block für das PHP-Rendering vor

Der Hauptteil, den wir in Javascript tun müssen, ist, die saveFunktion des Blocks return zu machen null. Sie könnten die ursprüngliche Ausgabe beibehalten, aber sobald wir WordPress anweisen, PHP zum Rendern des Blocks zu verwenden, wird dies ignoriert. Um uns und anderen klar zu machen, dass die Ausgabe des Blocks nicht in Javascript behandelt wird, ändern wir die saveFunktion.

Vergessen Sie nicht, dass das Ändern der Speicherfunktion dazu führt, dass alle vorhandenen Blöcke kaputt gehen. Fügen Sie den Block erneut hinzu. Der Block sollte genauso funktionieren wie zuvor; mit den Einstellungen und Aktualisierung der Attribute. Es wird jetzt einfach nichts im Frontend ausgegeben. Der Kommentarblock wird vorhanden sein und alle Attribute in JSON speichern, aber kein sichtbares HTML wird gerendert.

Jedoch; Wenn eines Ihrer Attribute die sourceEigenschaft verwendet, müssen Sie dies ändern. Dies wird bei Blöcken, die mit PHP gerendert werden, nicht unterstützt, da sie direkt aus der Ausgabe des Speicherns geparst werden – worauf wir jetzt zurückkommen null. Wir verwenden source auf dem zweiten RichTextin unserem Block – für den Absatz. An diesem Punkt speichert der Editor RichTextüberhaupt nicht, was Sie hier eingeben.

Wenn Sie also auch noch sourcedas myRichTextAttribut verwenden, müssen wir die Eigenschaften sourceund entfernen selector, um sicherzustellen, dass die Attribute gespeichert und nicht von der saveFunktion geparst werden:

attributes: {
    ...
    myRichText: {
        type: 'string',
    },
    ...

Danach ist unser Block bereit zum Rendern in PHP. Wir können die Javascript-Dateien belassen (vergessen Sie nicht, sie zu erstellen) und der Rest wird in PHP erledigt.

Rendern von Blöcken in PHP

Um WordPress anzuweisen, die Ausgabe des Blocks in PHP zu rendern, fügen wir der Funktion ein neues Argument hinzu register_block_type(). Wir müssen den Schlüssel render_callbackmit einem Wert der Funktion, die er ausführen soll, zum Array hinzufügen.

Die PHP-Renderfunktion

Lassen Sie uns die Funktion awp_myfirstblock_renderweiter unten in functions.php(oder wo auch immer Sie Ihren PHP-Code eingefügt haben) definieren. Unsere Funktion erhält zwei Parameter; wir rufen sie an $attrund $content.

function awp_myfirstblock_render($attr, $content) {
    // return the block's output here
}

Der Parameter $attrist ein assoziatives Array mit allen gespeicherten Attributen. Der zweite Parameter, $content, ist für Blöcke innerhalb unseres Blocks. Dies ist nur relevant für Blöcke, die verschachtelte Blöcke unterstützen – was zum Beispiel Columns oder Cover tun.

Die Funktion sollte nie echoetwas aus. Alle Ausgaben müssen zurückgegeben werden, also müssen Sie eine Zeichenfolge erstellen und am Ende zurückgeben.

Bei Attributen ist es wichtig, sich daran zu erinnern, dass nur gespeicherte Attribute im ersten Parameter der Funktion erscheinen. Wenn ein Attribut nie tatsächlich geändert und gespeichert wurde – dh sich nur auf sein verlässt default– wird das Attribut überhaupt nicht für unsere PHP-Funktion berücksichtigt.

Sie müssen dieses Problem entweder immer überprüfen if (isset($attr['...']))oder auf die bevorzugte Weise behandeln: die Attribute in unserem register_block_type()Aufruf definieren. Wir können einen weiteren Schlüssel bereitstellen, attributes, und seinen Wert auf ein Array mit allen Attributen setzen, die wir aus unserem Block extrahieren möchten. Die Struktur sollte identisch mit der sein, die Sie in Javascript definiert haben, aber anstelle eines Javascript-Objekts benötigen Sie sie in einem PHP-Array. Es kann etwas umständlich sein, dieselben Attribute neu zu definieren, aber mit einem intelligenten Code-Editor sollte es ziemlich schnell gehen, sie in PHP zu kopieren, einzufügen und mehrzeilig zu bearbeiten.

Hinzufügen der Attribute für unsere Renderfunktion

Lassen Sie uns das neue attributesElement hinzufügen register_block_type()und genau dieselben Attribute einfügen, die wir in unserer Javascript-Datei definiert haben:

Denken Sie daran, dass der Parameter defaultIhrer Funktion immer alle Attribute enthalten sollte, wenn Sie a für alle Attribute definieren. $attrZum Beispiel textAlignmentexistiert das obige Attribut nur in, $attrwenn es geändert wurde – und Sie müssen überprüfen isset($attr['textAlignment']).

Leider gibt es im Moment zwei Dinge, die Sie mit PHP block render nicht in den Griff bekommen. Eines ist die classNameRequisite – also müssen Sie die Wrapping-Klasse (wenn Sie es wollen) selbst bauen. Die andere ist die supportEigenschaft für die Blockausrichtung. Momentan unterstützt WordPress diese Eigenschaft in dynamischen Blöcken nicht. Wir werden den Wert der gewählten Blockausrichtung nicht erhalten, es sei denn, wir ändern ihn in ein Attribut und handhaben ihn manuell in Javascript.

Die HTML-Ausgabe der Funktion liegt ganz bei Ihnen!

Anfordern von PHP-Rendering aus dem Editor heraus

Es ist möglich, das PHP-Rendering unseres Blocks im Editor anzufordern. Dies ist nützlich, wenn Sie die Ausgabe des Blocks im Editor in der Vorschau anzeigen möchten. Wir können dies mit einer Komponente tun, die ServerSideRenderaus dem wp.editorPaket aufgerufen wird.

Als Requisiten ServerSideRendermüssen Sie alle Attribute definieren, die Sie weitergeben möchten. Als Minimum müssen Sie dem Prop den Namen des Blocks mitteilen block, damit WordPress weiß, nach welcher Rendermethode gesucht werden muss. Diese steht Ihnen in props.nameder editFunktion zur Verfügung. Sie müssen auch alle Attribute angeben, die Sie in der Requisite benötigen attributes. Wenn Sie möchten, können Sie hier auch benutzerdefinierte Variablen außerhalb von Attributen hinzufügen. Denken Sie daran, dass dies nur für den internen Editor und nicht für das Frontend funktioniert.

Sie können ServerSideRenderdie Funktion des Blocks nicht verwenden save. Ihre saveFunktion muss trotzdem zurückkehren null.

Lassen Sie uns ServerSideRenderin unserem Block implementieren, um es in der Praxis zu sehen.

Verwenden von ServerSideRender für den Blockvorschau-/Bearbeitungsmodus

Wenn Sie dem vorherigen Schritt gefolgt sind, in dem wir einen Umschalter für den Vorschau-/Bearbeitungsmodus für unseren Block erstellt haben, können wir jetzt verwenden ServerSideRender, um die Vorschau des Blocks von PHP aus zu rendern, wenn wir in den Vorschaumodus umschalten.

Zuerst müssen wir uns daran erinnern, ServerSideRenderoben zu destrukturieren:

const { ServerSideRender } = wp.editor;

Wenn Sie sich an den vorherigen Schritt erinnern, haben wir die Komponenten Disabledund/oder verwendet Placeholder, um die Vorschau zu halten. Das Problem bei der Verwendung Placeholderbesteht darin, dass wir unerwünschtes Styling auf unsere Ausgabe anwenden. PlaceholderLassen Sie uns durch ersetzen ServerSideRender. Sie können die DisabledKomponente beibehalten, um sicherzustellen, dass kein Inhalt angeklickt oder gezogen werden kann.

Beim Code zum Rendern des Blocks, wenn das Attribut editModefalsch ist, machen wir Folgendes:

Jetzt rendert unsere benutzerdefinierte Schaltfläche in der Symbolleiste die Ausgabe von PHP, wenn wir in den Vorschaumodus wechseln. Die Ausgabe sollte identisch sein, wenn der Beitrag im Frontend angezeigt wird. Dies ist eine gute Angewohnheit, um sicherzustellen, dass die Ausgabe in Editor und Frontend identisch ist.

Beispiel: Dynamischer Block, der einen ausgewählten Beitrag anzeigt

Die Ausgabe in Ihrer PHP-Renderfunktion kann beliebig sein und Sie haben vollen Zugriff auf alle WordPress-Funktionen. Nehmen Sie einen Block an, in dem eine Beitrags-ID in einem Attribut gespeichert wird. In der render_callbackPHP-Funktion können Sie den Beitrag aus der ID abfragen und dessen Informationen ausgeben. Es sollte ziemlich selbsterklärend sein, wie das geht, aber hier ist ein kurzes Beispiel.

NB: In diesem Beispiel fügen wir einfach eine Texteingabe zum Editor hinzu, um eine Beitrags-ID manuell einzugeben. Dies ist keine sehr intuitive und benutzerfreundliche Lösung für die Auswahl eines Beitrags – aber das lernen wir im nächsten Schritt. Der Fokus liegt hier auf dem PHP-Teil des Renderns des ausgewählten Beitrags.

Lassen Sie uns ein Attribut selectedPostIdvom Typ Zahl hinzufügen:

attributes: {
    selectedPostId: {
        type: 'number'
    }
}

Und irgendwo innerhalb der editFunktion unseres Blocks fügen wir eine TextControlKomponente hinzu. Es kann sein, wo immer Sie wollen – innerhalb des Blocks oder im Inspektor.

Beachten Sie, dass ich besonders darauf achte, sicherzustellen, dass die Eingabe das Attribut korrekt als Zahl speichert, indem ich es mit in eine ganze Zahl umwandele parseInt(). Obwohl wir den Typ prop typeauf numbersetzen, um eine Zahleneingabe zu rendern, wird der geänderte Wert immer noch als Zeichenfolge interpretiert. WordPress speichert Ihr Attribut nicht, wenn es das falsche Format hat.

Vergessen Sie nicht, das neue Attribut zu Ihrer ServerSideRenderKomponente hinzuzufügen, falls Sie eines haben:

Der PHP-Teil

Das sollte sich um den Javascript-Teil gekümmert haben. Kommen wir zu PHP. Zuerst müssen wir das neue Attribut selectedPostIdzum attributesArray hinzufügen in register_block_type():

In der render_callbackFunktion können wir nun mit auf die Post-ID zugreifen $attr['selectedPostId']. Wir können damit einen einfachen Vorgang ausführen get_post()und die Daten der Post ausgeben; sein link und titel:

Dies ist ein sehr einfaches Beispiel, das als Sprungbrett für Sie gedacht ist, um fortgeschritteneren und benutzerdefinierten Code zu schreiben.

Nachdem wir nun wissen, wie man mit dem Rendern dynamischer Blöcke umgeht, besteht der nächste Schritt darin, zu lernen, wie man auch den Editor-Teil intuitiver gestaltet. Im nächsten Schritt konzentrieren wir uns darauf, wie man Beiträge aus dem Block-Editor heraus abfragt und dem Benutzer eine bessere Möglichkeit bietet, einen Beitrag auszuwählen.