Dynamische Blöcke in wenigen Minuten

Ich schreibe diesen Artikel, während ich mich noch auf dem WordCamp Vienna 2026 befinde. Ich habe gerade meinen Flash Talk „Dynamic Blocks from 0 to 100 in 30 Minutes“ gehalten. Die Präsentation soll belegen, dass der Weg vom leeren Ordner zum fertigen Dynamic Block keine 30 Minuten dauert. Er dauert etwa 5. Und in diesem Beitrag fasse ich zusammen, was ich dort erzählt habe.

Die Idee zu meinem Vortrag fängt mit einem Shortcode an. Ich arbeite nebenbei an einem Projekt mit einem Webdesigner, und der hat in einem WordPress-Plugin einen Shortcode ausgeliefert. Ich fragte: Warum nicht als Block? Die Antwort: Ich weiß nicht, wie das geht. Blocks haben den Ruf, kompliziert zu sein. Zu viele Config-Dateien, zu viele Tutorials von 2019, zu viel npm-Magie. Aber stimmt das eigentlich noch?

Warum dynamische Blöcke?

Kurze Grundlage: Ein statischer Block speichert seinen HTML-Output direkt in der Datenbank. Was man im Editor sieht, wird genau so abgelegt. Ein dynamischer Block funktioniert anders. Er speichert nur die Attribute, also die Einstellungen. Das eigentliche HTML wird bei jedem Seitenaufruf von PHP erzeugt. Der Output ist immer frisch. Kein save.js nötig. Nur eine render.php. Für die meisten realen Anwendungsfälle ist das genau richtig.

Warum das noch wichtig ist

Es gibt noch einen zweiten Grund, sich mit den Grundlagen zu beschäftigen. Wer in letzter Zeit AI-Tools benutzt hat, um Blocks zu generieren, hat vielleicht bemerkt: Die verwenden alle dasselbe Tooling. create-block, wp-scripts, block.json, render.php. Selbst wenn ein LLM den Code schreibt, muss man verstehen, was da passiert. Und genau dafür ist dieser Beitrag gedacht.

Drei Befehle. Das war’s.

WordPress hat ein offizielles Scaffolding-Tool: create-block. Drei Befehle und man hat ein funktionierendes Block-Plugin mit modernem Build-Setup:

npx @wordpress/create-block@latest my-block --variant=dynamic
cd my-block
npm start

Keine obskure Konfiguration. Alles wird von wp-scripts übernommen.

Die vier Dateien, die zählen

Was hat create-block gerade erzeugt? Im Kern sind es vier Dateien:

• block.json ist das Manifest, die zentrale „Wahrheit“ des Blockes.
• index.js registriert den Block auf der Client-Seite.
• edit.js ist eine React-Komponente, die steuert, wie der Block im Editor aussieht.
• render.php ist die Datei, die auf dem Frontend die Arbeit macht: serverseitiges Rendering mit PHP.

Es gibt noch ein paar weitere Dateien, Stylesheets zum Beispiel, aber diese vier sind der Kern jedes Dynamic Blocks.

Die eine Zeile, die den Unterschied macht

Wenn man nur eine Sache aus diesem Beitrag mitnimmt, dann diese. In der block.json setzt man die render-Eigenschaft auf die PHP-Datei:

"render": "file:./render.php"

Diese eine Zeile sagt WordPress: Suche keine save-Funktion in JavaScript, rendere diesen Block stattdessen mit PHP. Das ist der gesamte Unterschied zwischen einem statischen und einem dynamischen Block.

React im Editor. PHP im Frontend.

Die edit.js ist der Ort, an dem man das Editor-UI baut. Es ist eine React-Komponente. Drei Dinge, die man sich merken sollte:

1. useBlockProps() immer auf das Root-Element spreaden. Damit wendet WordPress die richtigen Klassen und Styles an.
2. InspectorControls für ein Settings-Panel in der Sidebar verwenden.
3. setAttributes() aufrufen, wenn der Benutzer etwas ändert.

Das ist das Pattern. Wenn man es einmal gesehen hat, kann man jedes Editor-UI bauen.

render.php: Immer frisch.

Die render.php läuft bei jedem Seitenaufruf. Man bekommt das $attributes-Array mit allem, was der Benutzer im Editor konfiguriert hat. Man verwendet get_block_wrapper_attributes() für das korrekte Wrapper-Markup. Und man benutzt natürlich immer Escaping für die Ausgaben. Immer.

Drei Dinge. Das ist alles, was man für eine render.php wissen muss.

Block Supports: Nicht bauen, was WordPress schon mitbringt

Anstatt eigene Color Picker, Font-Size-Controls oder Spacing-UIs zu bauen, deklariert man einfach in der block.json, was man braucht:

"supports": {
  "color": true,
  "typography": { "fontSize": true },
  "spacing": { "padding": true, "margin": true }
}

WordPress generiert die Controls im Editor und wendet die Styles im Frontend automatisch an. Das Rad muss man hier nicht neu erfinden.

Attribute: Das Gedächtnis des Blocks

Attribute sind die Art, wie ein Block sich merkt, was der Benutzer konfiguriert hat. Man definiert sie in der block.json mit einem Typ und einem Standardwert: string, boolean, integer, array, object.

Und bei Dynamic Blocks der beste Teil: Sie werden automatisch an die render.php weitergegeben. Man muss nichts manuell verbinden.

Zwei Befehle für den Alltag

Der tägliche Workflow besteht aus zwei Befehlen. npm start für die Entwicklung: Dateien werden überwacht und bei jeder Änderung neu kompiliert. npm run build, wenn man ausliefern will: optimierter, minifizierter Output.

Beides wird von wp-scripts angetrieben. Null Konfiguration nötig.

Kein JavaScript? Kein Problem.

Man kann einen Block auch komplett in PHP registrieren. Mit register_block_type() und einem render_callback. Kein Build-Schritt, kein npm, kein node_modules. Der Block erscheint im Editor via ServerSideRender, und die gesamte Logik bleibt in PHP. Für einfachere Anwendungsfälle ist das eine solide Option.

Bonus 1: Zero JavaScript. Ernsthaft.

WordPress 7.0 bringt das autoRegister-Flag. Wenn man autoRegister in den Supports auf true setzt, erscheint der PHP-only Block automatisch im Editor. Aber das wirklich Spannende: WordPress generiert Inspector Controls aus den Attribut-Definitionen. Ein string wird zum Textfeld, ein boolean zum Toggle, ein enum zum Dropdown. Kein JavaScript. Überhaupt keins.

register_block_type( 'my-plugin/example', [
    'title'           => 'My Block',
    'attributes'      => [ /* ... */ ],
    'render_callback' => function ( $attributes ) {
        return '<div>' . esc_html( $attributes['title'] ) . '</div>';
    },
    'supports' => [ 'autoRegister' => true ],
] );

PHP-Entwickler, willkommen zurück.

Bonus 2: Ein Aufruf für alle Blocks

Wenn ein Plugin mehrere Blocks enthält, muss man seit WordPress 6.8 nicht mehr jeden einzeln registrieren. Man generiert eine Manifest-Datei mit wp-scripts und registriert dann alle Blocks mit einem einzigen Funktionsaufruf:

wp_register_block_types_from_metadata_collection(
    __DIR__ . '/build',
    __DIR__ . '/build/blocks-manifest.php'
);

Neues Block-Verzeichnis anlegen, Build laufen lassen, fertig. Es wird automatisch erkannt. Kein Vergessen mehr, einen Block irgendwo in der PHP-Datei zu registrieren.

Scaffold. Customize. Build. Repeat.

Das ist der Workflow. Man scaffoldet mit create-block. Man passt edit.js, render.php und block.json an. Man baut mit npm run build. Und dann macht man es für den nächsten Block nochmal.