Gutenberg-Blöcke und REST API

Begriffe vorab

• REST API: Schnittstelle, über die Programme Daten per HTTP abrufen und ändern.
• Endpunkt (Route): eine konkrete URL der Schnittstelle.
• Attribut: ein gespeicherter Wert eines Blocks.
• Dynamischer Block: Block, der beim Aufruf serverseitig gerendert wird.

Der Block-Editor (Gutenberg) baut Inhalte aus Blöcken. Eigene Blöcke werden mit JavaScript (React) und PHP entwickelt. Die Entwicklungsumgebung liefert das Paket @wordpress/scripts, gestartet über npm start (Entwicklung) und npm run build (Produktion).

block.json

Die Datei block.json beschreibt einen Block zentral: Name, Titel, Kategorie, Attribute und Assets.

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 3,
  "name": "mein-plugin/hinweis",
  "title": "Hinweis",
  "category": "text",
  "attributes": { "text": { "type": "string" } },
  "editorScript": "file:./index.js",
  "style": "file:./style-index.css",
  "render": "file:./render.php"
}

Die Registrierung erfolgt in PHP:

add_action( 'init', function () {
	register_block_type( __DIR__ . '/build/hinweis' );
} );

Statische und dynamische Blöcke

• Statische Blöcke speichern ihr fertiges HTML in der Datenbank (Funktion save).
• Dynamische Blöcke rendern bei jedem Aufruf serverseitig, per render.php oder render_callback. Ideal für Inhalte, die sich ändern, etwa eine Liste neuer Beiträge.

Interactivity API

Für Frontend-Interaktivität ohne eigenes Framework gibt es die Interactivity API. Sie nutzt HTML-Direktiven wie data-wp-interactive und data-wp-on--click und einen Store im Modul-JavaScript.

REST API

WordPress stellt Inhalte unter /wp-json/ bereit, zum Beispiel /wp-json/wp/v2/posts. Eigene Endpunkte registrierst du auf rest_api_init.

add_action( 'rest_api_init', function () {
	register_rest_route( 'mein-plugin/v1', '/buecher', array(
		'methods'             => 'GET',
		'callback'            => 'meinpraefix_buecher_cb',
		'permission_callback' => '__return_true',
	) );
} );

Der permission_callback ist seit WordPress 5.5 (August 2020) Pflicht; fehlt er, meldet WordPress einen _doing_it_wrong()-Hinweis. Für öffentliche Endpunkte gibst du __return_true an, für geschützte prüfst du eine Capability mit current_user_can(). Ohne ihn erzeugt WordPress einen Hinweis.

Definiere Namespace und Version (mein-plugin/v1). So bleibst du bei späteren API-Änderungen abwärtskompatibel.

Statisch oder dynamisch?

Ein statischer Block speichert sein fertiges HTML im Beitrag; er ist schnell, ändert sich aber nicht automatisch. Ein dynamischer Block speichert nur seine Einstellungen und rendert bei jedem Aufruf neu – richtig für Inhalte wie „neueste Beiträge“, die sich ständig ändern.

Ein Beispiel für einen eigenen Endpunkt

Eine mobile App soll eine Liste von Rezepten abrufen. Du registrierst eine Route unter einem eigenen Namespace mit Version, etwa mein-plugin/v1/rezepte, gibst eine Callback-Funktion an und legst fest, wer zugreifen darf. Der Namespace mit Version erlaubt es später, die Schnittstelle zu ändern, ohne bestehende Clients zu brechen.

Gute Praxis

• Eingaben einer Route validieren und bereinigen.
• Rückgaben schlank halten und nur nötige Felder liefern.
• Geschützte Daten nur nach Capability-Prüfung ausgeben.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind. Codebeispiele sind nur auf Syntax geprüft, nicht in WordPress ausgeführt.

Quellen

• WordPress Developer Resources – Funktionsreferenz zu register_rest_route() (permission_callback seit WordPress 5.5 verpflichtend) (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• WordPress Block Editor Handbook – „Block API: block.json“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)