WordPress-KI-Integration: Ein detaillierter Einblick in die Architektur und ein Anwendungsbeispiel aus der Praxis

Vor WordPress 7.0 mussten Plugins, die KI-Funktionen hinzufügten, einen API-Schlüssel anfordern und verwalten, um mit einem KI-Anbieter zu kommunizieren.

Das brachte einige Nachteile hinsichtlich des Code-Umfangs und der Wartbarkeit mit sich. Du musstest umfangreiche, proprietäre SDK-Bibliotheken in deine Plugins einbinden und anbieterspezifische cURL-Anfragen schreiben.

Dieses fragmentierte Szenario hat sich mit der in WordPress 7.0 eingeführten nativen KI-Integration komplett verändert. Heute bietet WordPress eine zentralisierte Schnittstelle zur Konfiguration von Zugangsdaten für verschiedene KI-Anbieter sowie eine neue PHP-API. Diese neue Architektur ermöglicht es dir, Befehle, Anweisungen, Mediendateien und Datenstrukturen nahtlos zu senden, während der Core die Anfragen abwickelt.

Die neue Architektur bietet sowohl für Website-Administratoren als auch für Plugin-Entwickler erhebliche Vorteile.

Administratoren müssen die KI-Einstellungen nicht mehr über mehrere Plugins hinweg konfigurieren. Ab WordPress 7.0 installierst und aktivierst du einfach deine Plugin-Konnektoren, gibst deine API-Schlüssel in die einheitliche Konnektoren-Oberfläche ein – und schon stehen sie sofort allen KI-gestützten Plugins auf deiner Website zur Verfügung. Du kannst die KI-Nutzung ganz einfach überwachen, zu deinem bevorzugten Modell wechseln oder den Zugriff eines Anbieters für alle Plugins mit einem einzigen Klick widerrufen.

Für Plugin-Entwickler sind die Vorteile sogar noch größer – sie reichen von Datensicherheit über Code-Portabilität bis hin zu einer drastischen Reduzierung der technischen Schulden.

Bist du bereit, diese Reise in die neue WordPress-KI-Architektur zu beginnen? Dann lass uns loslegen.

Die drei Ebenen der WordPress-KI-Architektur

Heute sind deine WordPress-Websites von Haus aus KI-fähig. Dabei geht es jedoch nicht um sofort einsatzbereite KI-Funktionen, sondern vielmehr um die Grundlage für den Aufbau KI-gestützter Websites.

Die neue Architektur ist in drei verschiedene Ebenen gegliedert:

KI-Konnektor

Vor WordPress 7.0 benötigte jedes Plugin, das deiner Website KI-Funktionen hinzufügte, ein eigenes System zum Speichern und Verwalten deiner API-Schlüssel. Deine Anmeldedaten mussten entweder fest im Plugin hinterlegt oder über eine benutzerdefinierte Einstellungsseite verwaltet werden. In beiden Fällen war das alles andere als eine ideale Lösung für den Umgang mit sensiblen Daten.

Über eine einheitliche Oberfläche kannst du alle deine KI-Dienstleister an einem zentralen Ort konfigurieren. Diese Oberfläche bringt mehrere wesentliche Vorteile für die Website-Verwaltung mit sich.

Aus Sicht der Verwaltung und Sicherheit besteht der größte Vorteil darin, dass du deine Anbieter nur einmal in der „Konnektoren“-Oberfläche einrichten musst und sie dann vergessen kannst – ganz gleich, wie viele Plugins sie nutzen. Solltest du jemals deine API-Schlüssel ändern müssen, musst du nicht jedes Plugin neu konfigurieren; du kannst sie alle auf einmal im „Konnektoren“-Bildschirm aktualisieren.

Die Zentralisierung der Anmeldedaten verbessert zudem die Sicherheit deiner Website, indem sie das Risiko mindert, dass sensible Daten durch Plugins von Drittanbietern offengelegt werden, die möglicherweise schlecht programmiert oder nicht vertrauenswürdig sind.

Ein weiterer wichtiger Vorteil ist die Portabilität des Codes. Deine Plugins müssen nicht mehr wissen, welchen KI-Anbieter du nutzt, da die neue Architektur die Authentifizierung von der Plugin-Logik entkoppelt. Das bedeutet: Wenn du den KI-Anbieter wechselst, funktioniert dein Plugin weiterhin, ohne dass auch nur eine einzige Zeile Code geändert werden muss.

Der eigentliche Durchbruch bei der Portabilität ist jedoch die Möglichkeit für Website-Administratoren, mehrere Konnektoren gleichzeitig zu konfigurieren. Wenn ein Plugin eine Anfrage auslöst, wählt WordPress automatisch den am besten geeigneten KI-Anbieter und das passende Modell aus, um die Antwort zu generieren – basierend sowohl auf der spezifischen Konfiguration des Plugins als auch auf den Fähigkeiten der verfügbaren Modelle.

KI-Client

Während der „Konnektoren“-Bildschirm die Konfigurationsoberfläche für KI-Anbieter bereitstellt, bietet der KI-Client Entwicklern das operative Werkzeug zur Kommunikation mit KI-Modellen.

Es handelt sich um eine native Software-Schnittstelle, die die Interaktion mit KI-Modellen über die globale Funktion wp_ai_client_prompt() und einen einheitlichen Satz von PHP-Methoden standardisiert.

Reduzierte technische Schulden

Für Entwickler ist ein großer Vorteil der neuen KI-Architektur die Reduzierung von technischer Verschuldung und Abhängigkeiten. Vor WordPress 7.0 war das Hinzufügen von KI-Funktionen mit sehr hohen Kosten für die Code-Wartung verbunden. Man musste proprietäre SDKs von Drittanbietern (wie die offiziellen Bibliotheken für OpenAI oder Anthropic) einbinden und ständig die Bibliotheksversionen im Auge behalten. Das führte zu einem aufgeblähten Plugin-Code und öffnete die Tür für Kompatibilitätsfehler.

Außerdem musstest du viele Zeilen Code schreiben, um die Netzwerk-Logik und das Parsen der Antworten zu handhaben. Erschwerend kam hinzu, dass der Code anbieterabhängig war – wenn du dich also entschieden hast, den KI-Anbieter zu wechseln, musstest du die gesamte Netzwerkarchitektur deines Plugins neu schreiben.

Der KI-Client löst dieses Problem an der Wurzel, indem er all diese aufwendige Arbeit an den WordPress-Kern überträgt. Dein Code wird völlig unabhängig vom KI-Anbieter; du musst deine Anweisungen nur einmal schreiben, und WordPress übersetzt sie in den modellspezifischen „Dialekt“.

Intelligente Modellauswahl

Eine leistungsstarke Funktion der „Fluent Interface“ des KI-Clients ist die Möglichkeit, bevorzugte Modelle über die Methode using_model_preference() festzulegen, die über die Builder-Funktion wp_ai_client_prompt() verfügbar ist. Mit dieser Methode kannst du eine geordnete Liste von Modellen für die spezifische Aufgabe deines Plugins deklarieren. Der folgende Code fordert beispielsweise eine Textgenerierung an, die auf drei bevorzugte Modelle abzielt:

$text_result = wp_ai_client_prompt( 'Convert the following transcript into a concise, blog-ready draft.' )
	->using_model_preference(
		'gemini-2.5-flash',
		'claude-3-5-sonnet',
		'gpt-4o'
	)
	->generate_text();

WordPress überprüft die auf dem „Konnektoren“-Bildschirm konfigurierten Anbieter und durchsucht die im Plugin-Code definierte Modellliste, wobei es den ersten Connector auswählt, der auch auf der Website verfügbar ist. Sollte keines der in deinem Code angegebenen Modelle unter den aktiven „Konnektoren“ verfügbar sein, ignoriert WordPress die Modellpräferenzliste und greift auf das erste kompatible Modell zurück, das auf der Website konfiguriert ist.

Dieser Mechanismus stellt sicher, dass dein Plugin immer funktioniert, selbst wenn der Website-Administrator zu einem anderen KI-Anbieter wechselt.

KI-Anbieter

Ein KI-Anbieter ist das Unternehmen, das die von uns täglich genutzten großen Sprachmodelle (LLMs) besitzt, trainiert und hostet. OpenAI, Google Gemini und Anthropic sind die gängigsten KI-Anbieter, die über spezielle Konnektoren in WordPress 7.0 unterstützt werden, aber Entwickler können zusätzliche benutzerdefinierte KI-Anbieter registrieren.

Wenn der Code deines Plugins die Methode generate_text() – oder eine andere Generierungsmethode – aufruft, kompiliert WordPress die Daten und sendet sie über den vom Konnektor eingerichteten Endpunkt an den KI-Anbieter. Hier ist der Ablauf der Vorgänge, die hinter den Kulissen stattfinden:

• Zunächst erhält der KI-Anbieter den Eingabetext zusammen mit eventuell angehängten Multimediadateien (Datenpaket).
• Nach dem Empfang verarbeitet er die Anfrage unter Berücksichtigung etwaiger Systemanweisungen.
• Anschließend generiert er die Ausgabe, die entweder als Freitext oder als JSON-Objekt strukturiert ist.
• Schließlich sendet er die Ausgabe über eine HTTP-Antwort zurück an WordPress.

Jeder Anbieter bietet eine große Auswahl an Modellen mit unterschiedlichen Fähigkeiten, Geschwindigkeiten und Preisen an. Diese reichen von Modellen, die ausschließlich auf Textverarbeitung spezialisiert sind, über multimodale Modelle, die neben einer Textanfrage auch Mediendateien (Audio, Bilder, Video) akzeptieren, bis hin zu Modellen, die für bestimmte Aufgaben entwickelt wurden, wie beispielsweise die Bilderzeugung oder die Sprach-zu-Text-Umwandlung.

Auch hier hängt es von den KI-Anbietern ab, die der Nutzer im „Connectors“-Bildschirm konfiguriert, welche Modelle für eine WordPress-Seite verfügbar sind. Das bedeutet, dass dein Plugin nicht vorschreibt, welcher Anbieter konkret verwendet werden soll.

Ein tiefer Einblick in die Funktion wp_ai_client_prompt()

Die Funktion wp_ai_client_prompt() ermöglicht es Plugins, auf standardisierte Weise mit KI-Modellen zu kommunizieren: Du musst keine externen Bibliotheken installieren, keine anbieterspezifischen Konfigurationen vornehmen und keine manuellen HTTP-Anfragen fest einprogrammieren.

Es handelt sich um eine Software-Schnittstelle, mit der du deinen Code nur einmal schreiben musst, während WordPress die Hauptarbeit übernimmt und deine Anweisungen in den spezifischen „Dialekt“ des jeweiligen Modells übersetzt.

Die Funktion gibt eine Instanz der Klasse WP_AI_Client_Prompt_Builder zurück, die eine flüssige Schnittstelle mit verkettbaren Methoden bietet, um deine Eingabeaufforderungen anzupassen. Die Funktion wird wie folgt beschrieben:

/**
 * Fluent builder for constructing AI prompts, returning WP_Error on failure.
 *
 * This class provides a fluent interface for building prompts with various
 * content types and model configurations. It wraps the PHP AI Client SDK's
 * PromptBuilder and adds WordPress-specific behavior including WP_Error
 * handling instead of exceptions, snake_case method naming, and integration
 * with the Abilities API.
 *
 * Only the generating methods will return a WP_Error, to not break the fluent
 * interface. As soon as any exception is caught in a chain of method calls,
 * the returned instance will be in an error state, and all subsequent method
 * calls will be no-ops that just return the same error state instance. Only
 * when a generating method is called, the WP_Error will be returned.
 */

wp_ai_client_prompt() führt keine unmittelbare HTTP-Anfrage durch, sondern instanziiert ein WP_AI_Client_Prompt_Builder-Objekt und gibt dieses zurück. Über 50 Konfigurationsmethoden füllen die privaten Eigenschaften des Objekts mithilfe einer Fluent-Schnittstelle, was den Code sehr gut lesbar und einfach zu schreiben macht.

Hier ist eine nicht vollständige Liste der Methoden, die du am häufigsten verwenden wirst:

• with_text(): Fügt Text zur aktuellen Nachricht hinzu.
• with_file(): Fügt der aktuellen Nachricht eine Datei hinzu.
• with_history(): Fügt Nachrichten aus dem Konversationsverlauf hinzu.
• using_model_preference(): Legt die bevorzugten Modelle fest, die der Reihe nach ausgewertet werden sollen.
• using_system_instruction(): Legt die Systemanweisung fest.
• using_max_tokens(): Legt die maximale Anzahl der zu generierenden Tokens fest.
• using_temperature(): Legt die Temperatur für die Generierung fest.
• using_top_p(): Legt den Top-p-Wert für die Generierung fest.
• using_top_k(): Legt den Top-k-Wert für die Generierung fest.
• as_output_file_type(): Legt den Typ der Ausgabedatei fest.
• as_json_response(): Konfiguriert die Eingabeaufforderung für die Ausgabe von JSON-Antworten.
• is_supported_for_text_generation(): Prüft, ob die Textgenerierung von der aktiven Konfiguration unterstützt wird.
• is_supported_for_image_generation(): Prüft, ob die Bilderzeugung von der aktiven Konfiguration unterstützt wird.
• is_supported_for_text_to_speech_conversion(): Prüft, ob die Text-zu-Sprache-Umwandlung von der aktiven Konfiguration unterstützt wird.
• is_supported_for_video_generation(): Prüft, ob die Videoerstellung von der aktiven Konfiguration unterstützt wird.
• generate_text(): Erzeugt ein Textergebnis aus der Eingabeaufforderung.
• generate_image(): Erzeugt ein Bild anhand der Eingabeaufforderung.
• convert_text_to_speech(): Wandelt Text in Sprache um.
• generate_speech(): Erzeugt Sprache aus der Eingabeaufforderung.
• generate_video(): Erzeugt ein Video aus der Eingabeaufforderung.

Die vollständige Liste der Methoden findest du im WordPress-Kernquellcode.

Angenommen, du möchtest den Inhalt einer Audiodatei genau transkribieren. Dann könntest du die Funktion wie folgt verwenden:

$transcription_builder = wp_ai_client_prompt( $prompt )
	->with_file( $audio_base64, $mime_type )
	->using_temperature( 0.1 );

if ( ! $transcription_builder->is_supported_for_text_generation() ) {
	// No configured provider supports the current prompt configuration.
	return new WP_Error(
		'no_supported_model',
		'No configured AI model can process this request. Configure a provider in Settings > Connectors.',
		array( 'status' => 400 )
	);
}

$transcript = $transcription_builder->generate_text();

Das macht dieser Code:

• $prompt: Stellt die Hauptzeichenfolge dar, die deine Kernanweisungen enthält.
• with_file(): Schaltet die multimodalen Funktionen der Schnittstelle frei. Im obigen Beispiel haben wir die vorcodierte Audio-Binärdatei als Base64-kodierte Zeichenkette zusammen mit dem entsprechenden MIME-Typ übergeben.
• using_temperature(): Steuert den Determinismus der Antwort. Während ein niedriger Wert (0,1) das Modell dazu zwingt, sich genau an das Audiomaterial zu halten, ermöglicht ein höherer Wert mehr kreative Freiheit. Du kannst diese Methode mit derusing_top_p()-Methode (Top-Probability) kombinieren, um die Ausgabe genauer zu steuern.
• is_supported_for_text_generation(): Prüft, ob die aktiven Konnektoren die Anforderungen der aktuellen Eingabe unterstützen, bevor Ressourcen für einen Netzwerkaufruf bereitgestellt werden.
• generate_text(): Dies ist die abschließende Methode der Fluent Interface. Sie sendet die vereinheitlichte HTTP-Anfrage an den aktiven Anbieter und gibt entweder die generierte Textzeichenfolge oder bei einem Fehler ein WP_Error-Objekt zurück.

Kurz gesagt: Wir haben dem KI-Anbieter eine Text-Eingabeaufforderung und eine angehängte Audiodatei übergeben. Wir haben eine niedrige „Temperatur“ eingestellt, um ein möglichst deterministisches Ergebnis zu gewährleisten, überprüft, ob die aktive Konfiguration die Textgenerierung unterstützt, und schließlich die Sprach-zu-Text-Transkription basierend auf der Antwort der KI durchgeführt.

Mit einer weiteren Eingabe können wir das Rohtranskript an die KI zurückgeben, um eine als JSON-Objekt strukturierte Antwort zu generieren:

$structured_json = wp_ai_client_prompt(
	"Convert the following transcript into a concise, blog-ready draft in American English.n" .
	"Return JSON with a post title and body sections.n" .
	"Each section must have: heading, level (2 or 3), and paragraphs (array).n" .
	"If useful, include bullet_points (array) for short actionable lists.n" .
	"Use short, clear headings and readable paragraph text.nn" .
	"Transcript:n" . $transcript
)
	->using_system_instruction( "You are a professional WordPress content editor. Always write in American English (use appropriate spelling, grammar, and conventions for that language variant)." )
	->using_temperature( 0.4 )
	->as_json_response( $schema )
	->generate_text();

Für diese zweite Eingabe nutzen wir zusätzliche Methoden, um weitere Funktionen der API auszuschöpfen:

• using_system_instruction(): Definiert den operativen Kontext und die Verhaltensrolle des Modells und trennt dabei klar dessen Persona („ein professioneller WordPress-Content-Editor“) von den eigentlichen Daten.
• using_temperature( 0.4 ): Legt eine höhere „Temperatur“ fest als bei der vorherigen Transkriptionsaufgabe, wodurch das Modell einen reichhaltigeren Wortschatz nutzen und flüssigere Inhalte erzeugen kann.
• as_json_response(): Zwingt das Modell dazu, eine strukturierte JSON-Zeichenkette zurückzugeben, die dem in deiner Variable $schema definierten Layout entspricht. Das ist nützlich, wenn du Inhalte für Gutenberg vorbereitest.

Mit einer als JSON strukturierten Ausgabe kannst du einzelne Felder extrahieren und sie mithilfe von WordPress-Kernfunktionen programmgesteuert in native Gutenberg-Blöcke abbilden.

Einen tieferen Einblick in den KI-Client findest du auch in der Entwicklernotiz Einführung des KI-Clients in WordPress 7.0.

Eine Audiodatei mit KI in Gutenberg-fähigen Inhalt umwandeln

Nachdem du nun ein besseres Verständnis für die drei Ebenen der WordPress-KI-Architektur hast, schauen wir uns anhand eines Beispiels aus der Praxis an, wie das Ganze zusammenpasst. In diesem Abschnitt lernst du, wie du die Kernlogik eines KI-gestützten Plugins entwickelst, das direkt aus einer Audiodatei einen gut ausgearbeiteten Beitragsentwurf generiert.

Die Anwendungsfälle für diese Funktion sind vielfältig und breit gefächert. Stell dir vor, du erstellst einen umfassenden Blogbeitrag aus einer kurzen Sprachnotiz, die du über deine Lieblings-Messaging-App gesendet hast, oder transkribierst ein auf deinem Smartphone aufgenommenes Audio-Interview.

Um diese Funktionalität auf deiner WordPress-Website zu implementieren, musst du ein benutzerdefiniertes Plugin erstellen. Wir werden hier weder auf die Boilerplate-Dateien noch auf den gesamten Prozess der Plugin-Registrierung eingehen; die Grundlagen der Plugin-Entwicklung findest du in anderen Tutorials im Kinsta-Blog oder in der offiziellen WordPress.org-Dokumentation.

Wir konzentrieren uns auf die Kernlogik, die es deinem Plugin ermöglicht, mit deinem KI-Anbieter zu kommunizieren. Aber keine Sorge, das Plugin steht dir in diesem GitHub-Repository zum Durchsehen und Herunterladen zur Verfügung.

Was dieses Plugin macht

Um loszulegen, geh auf die GitHub-Projektseite und lade das ZIP-Archiv des Plugins herunter. Melde dich anschließend in deinem WordPress 7.0-Dashboard an und lade es unter Plugins > Plugin hinzufügen > Plugin hochladen hoch. Sobald das Plugin installiert und aktiviert ist, kannst du diesem Tutorial folgen.

Das KI-Content-Builder-Plugin generiert eine Seitenleiste mit benutzerdefinierten Einstellungen, die über ein Symbol in der oberen rechten Ecke der Block-Editor-Oberfläche aufgerufen werden kann. Diese Seitenleiste verfügt über eine spezielle Oberfläche zum Hochladen von Audiodateien und einen Schalter, mit dem die KI den aktuellen Beitragstitel überschreiben kann.

Die Schaltfläche Audio hochladen öffnet den WordPress-Medien-Uploader, über den du eine neue Audiodatei hochladen oder eine vorhandene aus deiner Medienbibliothek auswählen kannst.

Sobald die Audiodatei geladen ist, löst die Schaltfläche Inhalt generieren eine asynchrone Anfrage an deinen aktiven KI-Anbieter aus.

Das Bild unten zeigt den fertigen Beitragsentwurf, den die KI in nur wenigen Sekunden generiert hat.

Der resultierende Inhalt ist in native Gutenberg-Blöcke strukturiert, darunter Absätze, Überschriften und Listen.

Schauen wir uns nun die Logik des Plugins genauer an.

Was du für dieses Plugin brauchst

Hier sind die grundlegenden Voraussetzungen für die Erstellung eines WordPress-Plugins, das sich in die neue KI-Architektur einbindet, um deine Beitragsinhalte zu generieren:

• WordPress 7.0+
• Einen API-Schlüssel für einen KI-Anbieter, der ein Modell zur Sprach-zu-Text-Umwandlung anbietet. In unserem Beispiel verwenden wir Google AI.
• Deine bevorzugte IDE. Für dieses Plugin haben wir VS Code verwendet.
• Fundierte Kenntnisse in den Bereichen WordPress- und Gutenberg-Entwicklung, REST-APIs, PHP und JavaScript.

Du musst dir keine Gedanken über Node.js, Build-Prozesse oder den Import externer Bibliotheken machen, da dieses Plugin vollständig auf nativen WordPress-Core-APIs basiert. Das Ergebnis ist ein schlankes, sicheres Plugin ohne technische Schulden.

Plugin-Struktur und Mindestversion von WordPress

Das AI Content Builder-Plugin besteht aus nur zwei Dateien:

• ai-content-builder.php
• editor.js.

Die erforderliche Mindestversion von WordPress ist 7.0, stell also sicher, dass du dies im Header des Plugins festlegst:

<?php
/**
 * Plugin Name: AI Content Builder
 * Description: Gutenberg sidebar plugin that uploads audio and generates post content using the WordPress 7.0 AI Client.
 * Version: 1.0.0
 * Requires at least: 7.0
 * Requires PHP: 8.0
 * Author: Your Name
 * License: GPL-2.0-or-later
 * Text Domain: ai-content-builder
 */

Vor diesem Hintergrund schauen wir uns nun den Prozess der Entwicklung eines KI-gestützten Plugins für WordPress an.

Der Datenfluss des Plugins

Bevor wir uns den Code genauer ansehen, schauen wir uns erst mal an, wie die Daten vom WordPress-Backend (dem Block-Editor) zum PHP-Server und zum KI-Anbieter fließen – und dann wieder zurück.

1. Vom Browser zum Server: Asynchroner REST-Aufruf: Der Browser sendet die Audio-ID an den benutzerdefinierten REST-Endpunkt des Plugins. Um zu verhindern, dass die Benutzeroberfläche einfriert, registrieren wir einen REST-Endpunkt, der asynchrone Anfragen an den PHP-Server zulässt.

2. Erster KI-Durchlauf: Sprach-zu-Text-Transkription: Der Server fängt die Anfrage ab, ruft die Audiodatei aus der Datenbank ab und fragt den KI-Client ab, um die Rohtext-Transkription zu extrahieren.

3. Zweiter KI-Durchlauf: Strukturierung des Inhalts: Der Server sendet die Rohtranskription zurück an den KI-Client und fordert an, dass sie als strukturiertes JSON-Objekt formatiert wird.

4. Datenbefüllung und Blockgenerierung: Das JavaScript-Skript (JS) empfängt das strukturierte JSON-Objekt, normalisiert es und ordnet die Felder den nativen Gutenberg-Blöcken zu.

Schauen wir uns nun die Logik hinter den einzelnen Phasen an.

1. Einen benutzerdefinierten API-Endpunkt registrieren

Der erste Schritt bei der Erstellung des KI-Content-Builder-Plugins ist die Registrierung eines API-Endpunkts. Dies ist unerlässlich, da die Verarbeitung einer Audiodatei und die Generierung einer Antwort für das KI-Modell mehrere Sekunden (oder sogar Minuten) dauern können. Durch die Registrierung eines REST-Endpunkts kannst du über die Steuerelemente in der Seitenleiste asynchrone Anfragen stellen und so verhindern, dass die Benutzeroberfläche einfriert.

Durch die Registrierung eines API-Endpunkts kannst du außerdem sichere KI-Aufrufe durchführen, ohne Anmeldedaten preiszugeben, indem du das native Authentifizierungssystem von WordPress nutzt.

Die Logik für die Registrierung und Initialisierung des Endpunkts wird in der PHP-Datei des Plugins mithilfe der beiden Klassenmethoden init() und register_rest_routes() abgewickelt.

public static function init(): void {

	// Register the custom REST endpoint used by the sidebar JS.
	add_action( 'rest_api_init', array( __CLASS__, 'register_rest_routes' ) );

	...
}

Indem der Funktionsaufruf an den Hook rest_api_init angehängt wird, registriert das Plugin den Endpunkt-Stammordner erst dann, wenn eine REST-API-Anfrage ausgelöst wird. Das verbessert die Leistung, da unnötige Verzögerungen beim Laden der Seite vermieden werden.

Du kannst Routen mithilfe der Methode register_rest_routes() konfigurieren, wie im folgenden Code gezeigt:

public static function register_rest_routes(): void {
	register_rest_route(
		self::REST_NAMESPACE,
		self::REST_ROUTE,
		array(
			'methods'             => WP_REST_Server::CREATABLE, // Alias for POST.
			'callback'            => array( __CLASS__, 'handle_generate_request' ),
			'permission_callback' => static function (): bool {
				// Reject unauthenticated or insufficiently privileged requests early.
				return current_user_can( 'edit_posts' );
			},
			'args'                => array(
				'audio_id' => array(
					'type'     => 'integer',
					'required' => true,
				),
			),
		)
	);
}

Diese Methode führt Folgendes aus:

• Die Funktion register_rest_route() nimmt drei Parameter entgegen: den Routen-Namespace, die Route selbst und ein Konfigurations-Array.
• WP_REST_Server::CREATABLE ist ein Alias für die POST-Transportmethode, die verwendet wird, um maximale Kompatibilität mit der internen Architektur von WordPress zu gewährleisten.
• permission_callback ist eine anonyme Funktion, die den Zugriff auf authentifizierte Benutzer beschränkt, die die Berechtigung zum Erstellen und Bearbeiten ihrer eigenen Beiträge haben. WordPress blockiert die Anfrage dann vor der Verarbeitung und gibt bei unbefugtem Zugriff automatisch einen 401-Fehler („Unauthorized“) oder einen 403-Fehler („Forbidden“) zurück.
• args ist ein optionales Array mit zusätzlichen Parametern, mit denen du die API-Antwort anpassen kannst. Damit kannst du festlegen, welche Daten die Anfrage an den Endpunkt zurückgeben soll.
• audio_id ist ein Array mit Parametern, das den Typ der erforderlichen Daten angibt. Wenn der zurückgegebene Datentyp keine Ganzzahl ist oder fehlt, bricht die REST-API die Ausführung ab und löst einen Fehler aus.

Stelle schließlich sicher, dass die Editor-Seitenleiste weiß, wohin die Daten gesendet werden sollen. Dazu verwendest du die Funktion wp_localize_script() innerhalb der Methode enqueue_editor_assets().

public static function enqueue_editor_assets(): void {
	...

	wp_localize_script(
		'ai-content-builder-editor',
		'AICBData',
		array(
			'restPath' => '/' . self::REST_NAMESPACE . self::REST_ROUTE,
			'nonce'    => wp_create_nonce( 'wp_rest' ),
		)
	);
}

• Die Funktion wp_localize_script() wird in erster Linie verwendet, um ein registriertes Skript mit Daten für eine JavaScript-Variable zu verknüpfen, aber hier nutzen wir sie, um Daten von PHP an JavaScript über das globale AICBData-Objekt zu übergeben.
• restPath ist die Endpunktadresse; wenn du sie hier angibst, musst du sie nicht fest in die JavaScript-Datei einbetten.
• nonce legt ein Sicherheitstoken fest, um unbefugten Zugriff zu verhindern.

2. Zugriff auf den KI-Client, um Text aus einer Audiodatei zu extrahieren

Das Herzstück unseres Plugins ist die Methode handle_generate_request(). Diese Methode führt eine Abfolge von Aufgaben durch, beginnend mit Sicherheitsprüfungen und endend mit der Generierung von Beitragsinhalten, die in den Block-Editor eingefügt werden sollen.

Zunächst wird überprüft, ob der KI-Client verfügbar ist und ob die KI-Unterstützung auf der Website nicht deaktiviert wurde.

public static function handle_generate_request( WP_REST_Request $request ) {
	if ( ! function_exists( 'wp_ai_client_prompt' ) ) {
		return new WP_Error(
			'ai_client_unavailable',
			'WordPress AI Client is not available. This plugin requires WordPress 7.0 .',
			array( 'status' => 500 )
		);
	}

	if ( function_exists( 'wp_supports_ai' ) && ! wp_supports_ai() ) {
		return new WP_Error(
			'ai_disabled',
			'AI support is disabled on this site.',
			array( 'status' => 403 )
		);
	}
	...
}

Im Falle eines Fehlers geben die Prüfungen jeweils einen 500- oder 403-Fehler zurück.

Der nächste Code-Block führt die folgenden Aktionen durch:

• Extrahiert die ID der Audiodatei aus der Anfrage
• Stellt sicher, dass die ID der Audiodatei eine positive ganze Zahl ist
• Prüft den Dateityp
• Ruft den MIME-Typ ab
• Extrahiert den Dateiinhalt und kodiert ihn in Base64

$audio_id = absint( $request->get_param( 'audio_id' ) );
if ( ! $audio_id ) {
	return new WP_Error( 'invalid_audio_id', 'Invalid audio ID.', array( 'status' => 400 ) );
}

$attachment = get_post( $audio_id );
if ( ! $attachment || 'attachment' !== $attachment->post_type ) {
	return new WP_Error( 'audio_not_found', 'Audio attachment not found.', array( 'status' => 404 ) );
}

$mime_type = (string) get_post_mime_type( $audio_id );
if ( 0 !== strpos( $mime_type, 'audio/' ) ) {
	return new WP_Error( 'invalid_audio_type', 'Attachment must be an audio file.', array( 'status' => 400 ) );
}

$audio_path = get_attached_file( $audio_id );
if ( ! $audio_path || ! file_exists( $audio_path ) ) {
	return new WP_Error( 'audio_path_missing', 'Audio file path not found on server.', array( 'status' => 404 ) );
}

$audio_bytes = file_get_contents( $audio_path );
if ( false === $audio_bytes ) {
	return new WP_Error( 'audio_read_failed', 'Unable to read audio file.', array( 'status' => 500 ) );
}

$audio_base64 = base64_encode( $audio_bytes );

Damit wurde die Binärdatei in eine Zeichenkette umgewandelt, die an den KI-Client übergeben werden kann. Jetzt können wir mit dem Extrahieren des Textes fortfahren:

$output_language = self::get_output_language();

$transcription_builder = wp_ai_client_prompt(
	"Transcribe this voice note accurately into $output_language. Return plain text only."
)
	->with_file( $audio_base64, $mime_type )
	->using_temperature( 0.1 );

if ( ! $transcription_builder->is_supported_for_text_generation() ) {
	return new WP_Error(
		'no_supported_model',
		'No configured AI model can process this request. Configure a provider in Settings > Connectors.',
		array( 'status' => 400 )
	);
}

$transcript = $transcription_builder->generate_text();

Hier ist eine Übersicht darüber, was der obige Code macht.

• get_output_language() ist eine statische Methode, die an anderer Stelle im Skript definiert ist und die Ländereinstellung der Website zurückgibt. (Siehe GitHub.)
• wp_ai_client_prompt() initialisiert eine neue Anfrage, indem die Haupt-Eingabeaufforderung übergeben wird.
• with_file() Teilt dem KI-Client mit, dass wir eine multimodale Anfrage senden; er akzeptiert den Dateiinhalt in Base64 und den MIME-Typ.
• using_temperature() ermöglicht es dir, den Grad des Determinismus der Antwort festzulegen. Wir setzen einen niedrigen Wert, um eine originalgetreue Transkription des Audios zu erhalten.
• Die Methode is_supported_for_text_generation() prüft, ob der KI-Anbieter aus den bereitgestellten Daten Text generieren kann; wenn der Anbieter keine multimodale Eingabe unterstützt, bricht das Plugin ab und gibt eine Fehlermeldung zurück.
• Die Methode generate_text() initiiert die HTTP-Anfrage.

3. Die Umwandlung der Audio-Transkription in strukturierte Inhalte

Da wir nun das Transkript haben, muss das Plugin erneut mit dem KI-Anbieter kommunizieren, um eine strukturierte JSON-Antwort zu erhalten. Dazu müssen wir ein strukturiertes Array im JSON-Format definieren.

$schema = array(
	'type'       => 'object',
	'properties' => array(
		'title'    => array( 'type' => 'string' ),
		'sections' => array(
			'type'  => 'array',
			'items' => array(
				'type'       => 'object',
				'properties' => array(
					'heading'    => array( 'type' => 'string' ),
					'level'      => array(
						'type' => 'integer',
					),
					'paragraphs' => array(
						'type'  => 'array',
						'items' => array( 'type' => 'string' ),
					),
					'bullet_points' => array(
						'type'  => 'array',
						'items' => array( 'type' => 'string' ),
					),
				),
				'required'   => array( 'heading', 'level', 'paragraphs' ),
			),
		),
	),
	'required'   => array( 'title', 'sections' ),
);

Mit dieser Struktur antwortet die KI mit einem JSON-Objekt, das einen Titel und ein Array von Abschnitten enthält. Jeder Abschnitt muss eine Überschrift, eine Überschriftenebene, mindestens einen Absatz und Aufzählungspunkte enthalten.

Nachdem das Schema nun definiert ist, können wir mit der Konfiguration der zweiten Anfrage an den KI-Client fortfahren:

$structured_json = wp_ai_client_prompt(
	"Convert the following transcript into a concise, blog-ready draft in $output_language.n" .
	"Return JSON with a post title and body sections.n" .
	"Each section must have: heading, level (2 or 3), and paragraphs (array).n" .
	"If useful, include bullet_points (array) for short actionable lists.n" .
	"Use short, clear headings and readable paragraph text.nn" .
	"Transcript:n" . $transcript
)
	->using_system_instruction( "You are a professional WordPress content editor. Always write in $output_language (use appropriate spelling, grammar, and conventions for that language variant)." )
	->using_temperature( 0.4 )
	->as_json_response( $schema )
	->generate_text();

if ( is_wp_error( $structured_json ) ) {
	return $structured_json;
}

Schauen wir uns die wichtigsten Punkte dieses Codes genauer an:

• using_system_instruction() definiert die Persona des Modells.
• using_temperature( 0.4 ) legt einen höheren Temperaturwert fest, wodurch die KI mehr kreative Freiheit erhält, um eine Antwort zu generieren und einen flüssigeren, reichhaltigeren Text zu produzieren.
• as_json_response( $schema ) Weist den Client an, die Antwort in einem strukturierten Format bereitzustellen.
• Das Plugin bricht im Fehlerfall ab.

Der nächste Schritt ist das Dekodieren und Bereinigen der Daten.

$structured = json_decode( (string) $structured_json, true );

if ( ! is_array( $structured ) ) {
	return new WP_Error(
		'invalid_ai_json',
		'Could not parse structured AI response.',
		array( 'status' => 500 )
	);
}

$normalized = self::normalize_structured_post( $structured );

if ( '' === $normalized['title'] && empty( $normalized['sections'] ) ) {
	return new WP_Error(
		'empty_structured_content',
		'The AI provider returned empty structured content.',
		array( 'status' => 500 )
	);
}

Im obigen Code:

• Die Funktion json_decode() wandelt die JSON-Zeichenkette in ein assoziatives PHP-Array um.
• Ist das JSON fehlerhaft, gibt die folgende Prüfung einen 500-Statuscode zusammen mit einer eindeutigen Fehlermeldung zurück.
• Die statische Methode normalize_structured_post() bereinigt und normalisiert die Ausgabe des Providers, bevor sie an JavaScript weitergegeben wird (siehe die Definition dieser Funktion auf GitHub).

Jetzt muss nur noch die resultierende Ausgabe an JavaScript übergeben werden, um native Gutenberg-Blöcke zu generieren.

4. Gutenberg-fähige Ausgabe generieren

Der nächste Schritt besteht darin, die JSON-Ausgabe nativen Gutenberg-Blöcken zuzuordnen. Diese Phase findet auf der Client-Seite statt und wird von der Datei editor.js übernommen.

Wenn der Nutzer eine Audiodatei auswählt, wird der folgende Code ausgelöst:

function AIContentBuilderSidebar() {

	const [ audioId, setAudioId ] = useState( 0 );
	...

	const onSelectAudio = function ( media ) {
		if ( ! media || ! media.id ) {
			return;
		}
		setAudioId( media.id );
		setAudioLabel( media.title || media.filename || ( 'Audio #'   media.id ) );
		setNotice( null );
	};
	...
}

Dieser Code ruft die ID der aufgenommenen Audiodatei aus der WordPress-Datenbank ab.

Wenn der Nutzer auf die Schaltfläche Inhalt generieren klickt, sendet die Funktion onGenerate() über apiFetch() eine POST-Anfrage an den API-Endpunkt, die unter anderem die Audio-ID enthält.

const onGenerate = async function () {

	...

	try {
		const response = await apiFetch( {
			path: AICBData.restPath,
			method: 'POST',
			headers: {
				'X-WP-Nonce': AICBData.nonce,
			},
			data: {
				audio_id: audioId,
			},
		} );
		...
	}
	...
}

• await Die Funktion wird vorübergehend angehalten, um zu verhindern, dass der Browser während des Wartens auf die Antwort der KI einfriert.
• Sobald die Antwort eingegangen ist, wird das JSON-Objekt vorübergehend in der Variablen response gespeichert.

Der Inhalt der Variablen response ist ein Objekt mit folgender Struktur:

{
	title: "Two Wheels to the Medina: ...",
	sections: [
		{
			heading: "A Well-Deserved Rest in the Red City",
			level: 2,
			paragraphs: [ "On April 24th, our group of seven motorcyclists..." ],
			bullet_points: []
		},
		{
			heading: "Diving into the Medina and Jemaa el-Fnaa",
			level: 2,
			paragraphs: [ "We spent the day exploring the historic Medina..." ],
			bullet_points: [ 
				"Navigating the vibrant, maze-like alleys of the ancient Medina", 
				"Tasting traditional Berber tagines and Moroccan mint tea",
				"Shopping for handmade leather goods, spices, and lanterns in the souks" 
			]
		},
		{...}
	],
	content: "Fallback plain text...",
	transcript: "Full transcript..."
}

Dieses Objekt liefert die notwendigen Daten zum Erstellen der Blöcke. Das Skript kann jedoch entweder eine JSON-Zeichenkette oder in einem Objekt verschachteltes JSON erhalten. Daher ist vor dem Extrahieren der Daten für die Blockgenerierung ein zusätzlicher Normalisierungsschritt erforderlich:

const normalizedSections = normalizeSectionsPayload( response.sections );

• Die Funktion normalizeSectionsPayload() normalisiert ungewisse sections-Payloads in ein Array. (Siehe Code auf GitHub.)

Anschließend wird die Variable normalizedSections als Argument an die Funktion übergeben, die die sections-Felder in native Gutenberg-Blöcke umwandelt:

const structuredBlocks = buildBlocksFromSections( normalizedSections );

Hier ist ein Auszug aus der Funktion buildBlocksFromSections():

function buildBlocksFromSections( sections ) {
	if ( ! Array.isArray( sections ) ) {
		return [];
	}

	const blocks = [];

	sections.forEach( function ( section ) {
		if ( ! section || 'object' !== typeof section ) {
				return;
			}

			const heading =
				( 'string' === typeof section.heading )
					? section.heading.trim()
					: '';

			const level = ( 3 === section.level ) ? 3 : 2;

			if ( heading ) {
				blocks.push(
					createBlock( 'core/heading', {
						content: heading,
						level: level,
					} )
				);
			}

			...

		} );
	return blocks;
}

Im obigen Code durchläuft die Schleife forEach() das Daten-Array und extrahiert section.heading und section.level, die von der nativen Funktion createBlock() verwendet werden.

Für die Zuordnung von section.paragraphs und section.bullet_points schau dir bitte den Quellcode auf GitHub an.

Unbegrenzte Erweiterungsmöglichkeiten

Die Einführung von KI in WordPress eröffnet sowohl Website-Administratoren als auch Entwicklern völlig neue Horizonte. Während du früher eine komplette Netzwerkinfrastruktur von Grund auf neu aufbauen musstest, nur um KI-Funktionen in deine WordPress-Website zu integrieren, ist es mittlerweile bemerkenswert einfach geworden, deinen redaktionellen Workflow zu automatisieren und KI-gestützte Funktionen hinzuzufügen.

Das im zweiten Teil dieses Artikels vorgestellte Beispiel-Plugin beleuchtet nur einen einzigen Anwendungsfall. Es zeigt jedoch deutlich, wie du nun Tools entwickeln kannst, die die Website-Verwaltung und die Bearbeitung von Inhalten drastisch vereinfachen. Darüber hinaus erschließt diese Architektur fortschrittliche Funktionen, deren Umsetzung bisher entweder zu komplex oder zu kostspielig war.

Und doch stehen wir erst am Anfang. Künstliche Intelligenz ist eine sich ständig weiterentwickelnde Realität, die zweifellos eine massive Innovationswelle auslösen wird.

Apropos Innovation… Hast du das Hosting von Kinsta schon ausprobiert? Wenn du deine Website mit der absolut besten Technologie ausstatten möchtest, die es heute für WordPress gibt, probier Kinsta ganz ohne Risiko aus oder wende dich an unser Vertriebsteam, um mehr zu erfahren.