WordPress
Gutenberg-Blöcke mit PHP und autoRegister erstellen
Eigene Gutenberg-Blöcke galten lange als Sache für JavaScript. Wer eine Infobox, eine Team-Übersicht oder einen Call-to-Action als eigenen Block wollte, richtete zuerst eine Build-Umgebung ein: Node, npm, ein Scaffold, React-Komponenten, ein Kompilierungsschritt. Für komplexe, interaktive Blöcke ergibt dieser Aufwand Sinn. Für einfache Ausgabe-Bausteine stand er oft in keinem Verhältnis zum Ergebnis, und wer vor allem in PHP zuhause war, blieb außen vor.
Wer ohne JavaScript-Toolchain arbeiten wollte, hatte mit Advanced Custom Fields lange einen pragmatischen Ausweg. ACF Pro registriert Blöcke überacf_register_block_type() und rendert sie über ein PHP-Template, komfortabel und etabliert, aber mit Plugin-Abhängigkeit und kostenpflichtiger Lizenz. Eine Core-eigene Lösung fehlte.
Mit WordPress 7.0, erschienen im Mai 2026, ändert sich das. Das Release bringt eine ganze Reihe größerer Neuerungen, vom überarbeiteten Admin-Bereich bis zu neuen KI-Schnittstellen, denen wir einen eigenen Beitrag widmen. Eine davon ist für die tägliche Arbeit mit Blöcken besonders praktisch: Blöcke lassen sich nun vollständig in PHP registrieren, ohne eigenes JavaScript, ohne npm, ohne Build. Möglich macht das eine neue Option namens autoRegister.
Was autoRegister verändert
autoRegister ist ein Eintrag im supports-Array von register_block_type(). Das supports-Array steuert, welche Editor-Funktionen ein Block kennt, etwa Farb- oder Abstandsoptionen. Steht autoRegister auf true und liegt ein render_callback vor, übernimmt WordPress die Editor-Integration selbst. Der Block erscheint im Inserter, die Vorschau im Editor entsteht über ServerSideRender, also über denselben PHP-Code, der später auch das Frontend ausgibt. Eine block.json, ein Editor-Skript oder eine save-Funktion sind nicht nötig.
Zu unterscheiden ist das von wp_register_block_types_from_metadata_collection() , das mit 6.7 und 6.8 kam. Diese Funktion registriert build-basierte Blöcke effizienter über eine blocks-manifest.php, ändert aber nichts daran, dass die Blöcke selbst aus einem JavaScript-Build stammen. autoRegister geht weiter. Hier gibt es den Build gar nicht erst.
Ein Beispiel aus dem Alltag: der Team-Block
Fast jede Website eines Verbands, einer Agentur oder einer Praxis hat eine Team-Seite. Die Mitglieder liegen meist ohnehin als strukturierte Daten vor, etwa in einem Custom Post Type. Ein Block soll sie nur ausgeben, gefiltert nach Abteilung, in einem Kartenraster. Die Redaktion entscheidet über die Darstellung, nicht über die Inhalte.
Das ist der ideale Fall für autoRegister. Der Block bekommt ein paar einfache Einstellungen, die eigentliche Ausgabe entsteht serverseitig aus der Datenquelle.
register_block_type( 'urbanstudio/team', [
'title' => 'Team',
'category' => 'widgets',
'attributes' => [
'abteilung' => [
'type' => 'string',
'enum' => [ 'leitung', 'beratung', 'entwicklung' ],
'label' => 'Abteilung',
'default' => 'leitung',
],
'spalten' => [
'type' => 'integer',
'label' => 'Spalten',
'default' => 3,
],
'rollen' => [
'type' => 'boolean',
'label' => 'Funktionsbezeichnung anzeigen',
'default' => true,
],
],
'supports' => [
'autoRegister' => true,
'spacing' => [ 'margin' => true, 'padding' => true ],
],
'render_callback' => 'urbanstudio_team_render',
] );
Drei Attribute, drei Block Supports, ein render_callback. Den Rest übernimmt WordPress. Die eigentliche Logik liegt in der Render-Funktion. Sie lädt die Mitglieder per WP_Query aus einem Custom Post Type, filtert sie über die Taxonomie abteilung und gibt sie als Liste von Karten aus.
function urbanstudio_team_render( $attributes ) {
$query = new WP_Query( [
'post_type' => 'team_member',
'posts_per_page' => -1,
'orderby' => 'menu_order',
'order' => 'ASC',
'tax_query' => [ [
'taxonomy' => 'abteilung',
'field' => 'slug',
'terms' => $attributes['abteilung'] ?? 'leitung',
] ],
] );
if ( ! $query->have_posts() ) {
return '';
}
$spalten = max( 1, (int) ( $attributes['spalten'] ?? 3 ) );
$rollen = ! empty( $attributes['rollen'] );
$wrapper = get_block_wrapper_attributes( [
'class' => 'us-team',
'style' => '--us-team-cols: ' . $spalten . ';',
] );
$karten = '';
while ( $query->have_posts() ) {
$query->the_post();
$bild = get_the_post_thumbnail( get_the_ID(), 'medium', [ 'loading' => 'lazy' ] );
$name = esc_html( get_the_title() );
$rolle = $rollen
? '<p class="us-team__rolle">' . esc_html( get_post_meta( get_the_ID(), 'rolle', true ) ) . '</p>'
: '';
$karten .= "<li class=\"us-team__karte\">{$bild}<h3>{$name}</h3>{$rolle}</li>";
}
wp_reset_postdata();
return "<div {$wrapper}><ul class=\"us-team__liste\">{$karten}</ul></div>";
}
Drei Stellen sind beachtenswert. Das Attribut abteilung fließt direkt in die Taxonomie-Abfrage und steuert so, welche Mitglieder geladen werden.
get_block_wrapper_attributes() liefert nicht nur die Klassen und Inline-Styles aus den Block Supports, sondern nimmt die gewählte Spaltenzahl als CSS-Variable --us-team-cols ins Frontend mit. Damit reicht eine kurze Regel, um daraus ein Grid zu machen:
.us-team__liste {
display: grid;
grid-template-columns: repeat(var(--us-team-cols, 3), 1fr);
gap: 1.5rem;
list-style: none;
padding: 0;
}
Kein block.json, kein Editor-Skript, kein Build. Was dasteht, läuft.
Bemerkenswert ist das Verhalten im Editor: Wählt die Redaktion eine andere Abteilung, ruft Gutenberg über ServerSideRender den PHP-Code erneut auf und zeigt sofort das tatsächliche Team. Vorschau und Frontend stammen aus derselben Quelle.
Eingabefelder entstehen aus den Attributen
Die Felder in der Sidebar muss niemand von Hand bauen. Bekommt ein Attribut einen label-Key, leitet WordPress aus dem Attributtyp das passende Control ab:
- string wird als Texteingabe dargestellt
- integer oder number wird als Zahleneingabe dargestellt
- boolean wird als Umschalter dargestellt
- string mit zusätzlichem enum wird als Auswahlfeld dargestellt
Beim Team-Block entsteht daraus ein Auswahlmenü für die Abteilung, ein Zahlenfeld für die Spalten und ein Schalter für die Funktionsbezeichnung. Drei Eingaben, kein eigener Editor-Code. Frei gebaute Inspector Controls bleiben dem JavaScript-Weg vorbehalten, für die vier Standardfälle genügt die automatische Generierung.
Styling über Block Supports
Farbe, Abstand und Typografie kommen nicht aus eigenem Code, sondern aus den Block Supports. Wer im supports-Array color oder spacing aktiviert, bekommt die zugehörigen Panels in der Sidebar automatisch. Sinnvoll ist es, die verfügbaren Werte über theme.json auf die Palette des Projekts zu begrenzen. Sonst öffnet der Block genau die gestalterische Freiheit, die ein definierter Baustein eigentlich einhegen soll.
Wann PHP die bessere Option ist
Der Team-Block zeigt beide Seiten. Solange die Mitgliederdaten aus der Datenbank kommen und der Block sie nur konfiguriert und ausgibt, ist PHP-only die schlankere Lösung. Keine Toolchain, keine node_modules, keine Versionspflege einer Build-Umgebung.
Anders sieht es aus, sobald die Redaktion die Mitglieder direkt im Block pflegen soll, mit Foto-Upload, freier Sortierung per Drag-and-drop oder verschachtelten Inhaltselementen. Dann braucht es InnerBlocks, Medien-Verwaltung und eine echte Editor-Oberfläche, und damit JavaScript und einen Build-Prozess, wie ihn der Weg über die native Block API mit React verlangt. Eine brauchbare Faustregel orientiert sich am Anteil reiner Darstellung. Bleibt ein Block im Wesentlichen Ausgabe, trägt PHP. Kommt echte Editor-Logik dazu, lohnt React.
Wichtig ist die Einordnung: autoRegister ersetzt den klassischen JavaScript-Weg nicht. Die WordPress-Core-Notiz beschreibt die Funktion ausdrücklich als Lösung für einfache, serverseitig gerenderte Blöcke, nicht für hochgradig interaktive Editor-Oberflächen.
Damit steht neben dem etablierten Weg über React und die native Block API ein zweiter bereit, der für einfache Blöcke ohne Build auskommt. Die Wahl zwischen ihnen bleibt am Ende eine Infrastrukturentscheidung: Es geht darum, wie viel Apparat eine Aufgabe wirklich rechtfertigt.
Jetzt weiterlesen...
