Einleitung
Technisch betrachtet gibt es in WordPress zwei unterschiedliche Typen von Blöcken: Statische und dynamische Blöcke. Doch was ist der Unterschied? Wann nutzt man welchen?
Statische Blöcke
Ein statischer Block speichert neben seinem Inhalt und seinen Attributen auch sein Layout (HTML) in die Datenbank.
Zum Registrieren unseres Blocks nutzen wir sowohl für statische als auch für dynamische Blöcke die registerBlockType Funktion. Auch die darin aufgerufene edit Funktion, die festlegt, wie der Block im Editor angezeigt wird, funktioniert für beide Block-Typen gleich.
Die save Funktion definiert den Block, wie er in die Datenbank gespeichert wird, sie unterscheidet sich für beide Block-Typen.
In diesem einfachen Beispiel haben wir einen statischen Block, der nur aus einem Wrapper-Element besteht und selbst Blöcke beinhalten kann.
registerBlockType(metadata, {
// ...
save: () => {
const blockProps = useBlockProps.save();
const innerBlocksProps = useInnerBlocksProps.save();
return (
<div {...blockProps}>
<div {...innerBlocksProps} />
</div>
);
},
});Code-Sprache: JavaScript (javascript)Nehmen wir an, wir füllen unseren Block mit einem Absatz-Block in dem „Hallo Welt“ steht, dann würde in der Datenbank folgendes gespeichert werden:
<!-- wp:luther/alert-statisch -->
<div class="wp-block-luther-alert-statisch">
<div>
<!-- wp:paragraph -->
<p>Hallo Welt</p>
<!-- /wp:paragraph -->
</div>
</div>
<!-- /wp:luther/alert-statisch -->Code-Sprache: HTML, XML (xml)Schöner, aber für dieses Beispiel unübersichtlicher, wäre es sicherlich hier die BlockProps zu kombinieren: „Combining the block props and the inner blocks props“
Dynamische Blöcke
Im Unterschied zu statischen Blöcken speichert ein dynamischer Block nur seinen Inhalt (InnerBlocks) und seine Attribute in der Datenbank, nicht aber sein HTML-Layout. Die save Funktion Speicher gibt darum auch nur die InnerBlocks zurück.
registerBlockType(metadata, {
// ...
save: () => <InnerBlocks.Content />
});Code-Sprache: JavaScript (javascript)Sollte unser Block keine InnerBlocks haben, sollte die save Funktion nur null zurückgeben. save: () => null. Daran erkennt Gutenberg, dass nur die Attribute gespeichert werden sollen.
Fügen wir wieder unseren Absatz-Block ein, in dem „Hallo Welt“ steht, wird Folgendes in der Datenbank gespeichert:
<!-- wp:custom/alert-dynamisch -->
<!-- wp:paragraph -->
<p>Hallo Welt</p>
<!-- /wp:paragraph -->
<!-- /wp:custom/alert-dynamisch -->Code-Sprache: HTML, XML (xml)Im Gegensatz zum statischen Beispiel oben findet sich kein HTML für unseren Block. Nur der Absatz-Block, der selbst ein statischer Block ist, speichert sein HTML-Layout.
Dynamische Blöcke im Frontend
Bisher gibt unser dynamischer Block noch kein HTML im Frontend aus, darum benötigen wir nun noch eine serverseitige Funktion (php), die diese Aufgabe, anstelle der save Funktion bei statischen Blöcken, übernimmt. In unserem register_block_type Aufruf fügen wir dazu eine render_callback Funktion hinzu.
<?php
register_block_type(__DIR__, array(
"render_callback" => "custom_alert_dynamisch_block_render_callback"
));Code-Sprache: PHP (php)Dieses dynamische Beispiel gibt das gleiche HTML aus wie die save Funktion im oberen statischen Beispiel:
<?php
function custom_alert_dynamisch_block_render_callback($attributes, $content) {
$wrapper_attributes = get_block_wrapper_attributes();
ob_start();
?>
<div <?php echo $wrapper_attributes; ?>>
<div>
<?php echo $content; ?>
</div>
<?php
return ob_get_clean();
}Code-Sprache: PHP (php)Die hier genutzte Funktion get_block_wrapper_attributes ist überaus praktisch und übernimmt die Aufgabe, die useBlockProps.save in statischen Blöcken übernimmt.
Vorteile statischer Blöcke
WordPress selbst nutzt, wann immer möglich, statische Blöcke. Diese sind zum einen performanter, weil sie nicht bei jedem Aufruf der Webseite neu zusammen gesetzt werden müssen und zum anderen eleganter, weil man häufig in der save Funktion Code aus der edit Funktion übernehmen kann.
Manchmal ist es allerdings nicht möglich, einen Block statisch zu bauen. Nehmen wir z.B. den „Letzte Beiträge“-Block. Wenn dieser seinen Inhalt statisch in der Datenbank speichern würde, würden immer die gleichen Beiträge angezeigt werden, auch wenn es inzwischen neuen Beiträge gibt. Darum ist dieser Block als dynamischer Block geschrieben (Hier der Code).
Die Idee von WordPress ist, möglichst statische Blöcke zu schreiben und nur wenn nicht anders möglich, dynamische Blöcke.
Nachteile statischer Blöcke
Ein großer Nachteil von statischen Blöcken ist, dass sie weniger flexibel für spätere Änderungen sind.
Nehmen wir an, du hast einen Block gebaut, den dein Kunde schon an vielen Stellen seiner Webseite nutzt. Nun möchtest du diesen barrierefrei machen und ein HTML-Attribut in den Block hinzufügen. Wenn du die Änderung in der save Funktion des statischen Blocks vornimmst, bekommt der Nutzer im Editor folgenden Fehler: „Dieser Block enthält unerwarteten oder ungültigen Inhalt“
Der Grund: Das HTML, wie es in der Datenbank steht, stimmt nicht mehr mit dem der neuen save Funktion überein. In den meisten Fällen reicht es hier den Button „Blockwiederherstellung versuchen“ zu klicken, jedoch musst du (oder dein Kunde) das dann an allen Stellen machen, wo der Block bisher genutzt wird.
Der von WordPress vorgesehene „Workaround“ ist für den Block einen Transform anzulegen. Ein Transform definiert unterschiedliche Versionen des Blocks und hilft Gutenberg, die Umwandlung vorzunehmen. So bekommt der Nutzer keine Fehlermeldung mehr. Wann immer jetzt eine Seite mit dem veränderten Block speichert wird, wird die neue Version (in diesem Fall mit HTML-Attribut) in der Datenbank gespeichert.
Ein Problem bleibt jedoch: Auf allen Seiten, die noch nicht erneut gespeichert wurden, bleibt das HTML-Layout das alte. So kann es passieren, dass im Frontend auf manchen Seiten noch die alte Version und auf manchen Seiten schon die neue Version zu sehen ist.
Details zu Transforms findest du im Block Editor Handbuch. Ich nutze diese Möglichkeit praktisch nie.
Fazit
Für meine Projekte für Kunden nutze ich aufgrund der höheren Flexibilität nur noch dynamische Blöcke. Der Aufwand beim Erstellen ist ein wenig höher, aber spätere Anpassungen sind deutlich problemloser. Weil ich ein Cache-Plugin (WP Rocket) nutze, dass die Seiten als HTML-Dateien zwischenspeichert, habe ich außerdem keine Performanceeinbußen.
Als ich bei 10Up gelesen habe, dass dynamische Blöcke für ihre Projekte der „preferred approach“ sind, hat mich das weiter darin bestätigt.