Bei der Registrierung eines Blocks definiert man mit Hilfe der edit() Funktion, wie der Editor den Block rendert und welche Informationen er anzeigt. Mit Hilfe der save() Funktion, legt man fest, wie die Daten gespeichert und im Frontend dargestellt werden sollen.
Dynamische Blöcke
Zur Erweiterung der ausschließlich in JavaScript geschriebenen Blöcken gibt es die Komponente ServerSideRender, um PHP Render-Callback Funktionen aufzurufen. Die Komponente bekommt das Ergebnis der PHP Funktion als HTML und rendert es anschießend im Block.
Diese Komponente ist Hilfreich, wenn es sich um einen dynamischen Block handelt. Erst beim Aufruf der Seite werden die Daten abgerufen und der Block gerendert. Einsatzgebiete sind zum Beispiel das Anzeigen der neusten Beiträge oder beliebtesten Bilder der Seite in einen Block. Diese Werte können sich ständig ändern, daher macht es Sinn die Werte erst beim Abruf der Seite zu laden. In der Datenbank ist nur ein Platzhalter in Form eines HTML Kommentars abgespeichert, der den Namen des Blocks und die ausgewählten Attribute enthält.
Der Block benötigt also keine save() Funktion, sondern nur ein Render-Callback, der die gespeicherten Attribute als Parameter bekommt und dann den Inhalt beliebig ausgeben kann. In der edit() Funktion wird die oben schon erwähnte ServerSideRender Komponente aufgerufen, um den Inhalt auch im Editor darzustellen.
Der Editor rendert den Block bei jeder Änderung eines Attributes neu. Um die PHP Render-Funktion innerhalb des JavaScript basierten Editors aufzurufen, greift er auf die REST API zurück. Der Block sendet die Attribute an den Endpoint /wp/v2/block-renderer/:block. Dort wird der PHP Render-Callback aufgerufen und diese liefert das gerenderte HTML zurück.
Render Funktion im Backend und Frontend unterscheiden
Doch wie geht man vor, wenn man den Block im Editor und auf der Seite unterschiedlich darstellen möchte? Es wird im beiden Fällen die gleiche Funktion aufgerufen.
Da die REST API das Rendern übernimmt, kann nicht auf die Funktion is_admin() zurückgegriffen werden, da diese Funktion prüft, ob man sich gerade auf einer Seite im Admin-Backend befindet. Wird allerdings eine Anfrage an die REST-API gesendet, ist dies ein eigenständiger Request und dieser Request ist nicht in einer Admin-Seite. Daher gibt die Funktion is_admin() bei REST API Anfragen immer false zurück, egal ob WordPress die Anfrage aus dem Backend sendet oder nicht. Dieses Problem gab es auch schon bei AJAX Anfragen. Florian Brinkmann hat einen Artikel darüber geschrieben wie man trotzdem prüfen kann ob die Abfrage bei AJAX Requests aus dem Front- oder Backend kommt.
Um zu prüfen, ob unser Block im Frontend oder im Backend gerendert wird, müssen wir prüfen, ob die PHP Funktion direkt für das Frontend aufgerufen wurde oder über die REST API im Backend aufgerufen wurde.
Die Prüfung innerhalb des PHP Render-Callbacks kann so aussehen:
if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
return 'Backend';
} else {
return 'Frontend';
};Wenn der Browser eine Anfrage an die REST API sendet, setzt WordPress die Konstante REST_REQUEST auf true. Somit kann man sicher sein, dass der Block nicht im Frontend gerendert wurde, da hier die Funktion direkt aufgerufen wird und in dem Fall diese Konstante nicht definiert ist.
