Öffnet in einem neuen Tab
WP KI Anwendung Plugin

WP-KI-Anwendung: Plugin erstellen

tl;dr: Mit KI kann jeder alles, auch ohne eine Zeile Code zu schreiben. Wie kann man die Möglichkeiten sinnvoll nutzen, ohne die Risiken zu maximieren? Erweitere dein WordPress nach deinen Vorstellungen, das ist praktisch – aber auch ein tiefer Eingriff in das System.

Was ist ein Plugin wirklich?

Als ich 2019 (!) meinen ersten Artikel über Plugins geschrieben habe war das nicht klar: heute muss man kein Programmierer sein, ja man muss nicht einmal Code verstehen können um ein Plugin zum Laufen zu bekommen. Was sich nicht geändert hat: ein Plugin läuft mit den selben Rechten wie WordPress selber - wer viel Macht hat, hat auch viel Veranwortung.

Diese Verwantwortung hast du auch als Plugin-Autor. Hier geht es nicht darum, ein Plugin für die Welt schreiben zu lassen - es geht darum, wie du eine auf deiner Website fehlende Funktion ergänzt. Das Ergebnis: Du bekommst von deiner KI ein .zip-Archiv und kannst das auf einer Website deiner Wahl wie gewohnt installieren und aktivieren. Es geht hier um den Eigenbedarf und nicht um ein Produkt.

Der wesentliche Unterschied sind die Formen: ein Plugin in freier Wildbahn benötigt eine readme.txt, muss unter GPL laufen etc. Hier ist aber wichtig, dass es richtig, sicher und sauber funktioniert. Wir benötigen nicht zwingend die Basis für Übersetzungen, brauchen kein Repository auf Git oder ähnliches. 

Die Umgebung

Gerade wenn es um PHP geht ist die Gefahr, dass fehlerhafter Code die Website crasht sehr groß. Du benötigst als ein Produktionsumgebung, also

diese lokale WordPress verbindest du mit deiner KI. Meine Empfehlung lautet, Novamira zu verwenden: es gibt eine kostenlose Variante für den Anfang und Novamira kann wirklich viele nützliche Dinge. Welches LLM dahinter liegt ist Geschmackssache. Ich verwende Claude Desktop, das ist ausreichend.  

Der Workflow

Die Schritte von der Idee zum fertigen Plugin lassen sich wie folgt zusammenfassen:

  1. Beschreibe im Prompt, was das Plugin können soll, was es nicht soll, und dass sich die KI möglichst auch an Sicherheit „denken” soll.
  2. Diskutiere die Details mit der KI (Rückfragen sind gut, lass die Schritte immer bestätigen bevor das grosse Werkeln los geht), lass dir das Plugin als .zip-Archiv übergeben (die Schreibrechte der KI sind innerhalb von WordPress hoffentlich begrenzt, daher dieser Weg).
  3. Installiere das Plugin auf einer Testinstanz. Prüfe. Gehe zurück zu Schritt 2 so oft, bis du zufrieden bist. 
  4. Teste das Plugin in einer Umgebung, die jener der endgültigen ähnlich ist – ev. mit einem anderen Theme, anderen aktiven Plugins etc. 
  5. Prüfe das Plugin so gut wie möglich, zb. auch mit Plugin Check (PCP). 
  6. Iregendwann ist das Plugin gut genug, dass dir keine Fehler mehr auffallen. Dann kannst du live gehen. Immer mit Backup vor der Erstinstallation. 

Risikomodell

Gerade weil es so einfach geworden ist sein WordPress zu killen kann gar nicht oft genug daran erinnert werden, wie man das Risiko minimieren kann, hier praktische Tips:

  • Lass dir die Funktionsweise in Alltagssprache erklären, mit diesen 4 Fragen: Was liest das Plugin? Was schreibt/ändert das Plugin? Wie verbindet es sich nach aussen? Was löst die Funktion des Plugins aus?
  • Mache einen Recheck in einem anderen Chat (neue, getrennte KI-Sitzung): besonders wenn es Schreib-/Dateizugriff oder externe Verbdinungen gibt. Wenn du die Möglichkeit hast, lass das Plugin von jemanden der Code versteht gegenlesen.
  • Verwende beim Testen Plugin Check PCP. Das Tool zeigt dir mache Fehler auf. Nur weil es keinen Fehler mehr findet, ist dein Plugin aber nicht sicher!
  • Sei dir selber ehrlich gegenüber, was das verbeibende Restrisiko betrifft. Das betrifft nicht nur die technische Sicherheit: es geht auch um Speed oder die schlichte Frage nach der Inhaltlichen Relevanz (braucht der Leser das überhaupt?).

Ein Beispiel

Die Aufgabe

Wir haben ein Datums/Uhrzeitfeld (Datetimepicker) mit ACF zu unseren Beiträgen hinzugefügt. Damit können wir zB. Datums/Uhrzeitinformationen eines Events anzeigen, das im Beitrag beschrieben wird. Nun wollen wir dieses Datum und die Uhrzeit als Block einbinden können. Er soll so wie eine Überschrift gestaltet und formatiert werden können. 

Natürlich gibt für diese Anwendung einfachere Lösungen, aber darum geht es hier nicht. Es kann auch eine gute Idee sein, sich bei dem Prompt selber von einem LLM in einem Dialog helfen zu lassen. LLMs verstehen auch wenn sie länger mit dir arbeiten den Kontext oft schlecht. Dann weichen sie ins Grundsätzlich aus und gewichten die Dinge falsch.

Hier nun ein Beispiel für einen Dialog, der zu einem sinnvollen Auftrag an das LLM führen könnte. Je genauer deine Angaben sind, desto besser wird das Ergebnis werden.

Schreibe ein WordPress-Plugin das überprüft, ob ein ACF-Feld 'eventdatum' exisiert, wenn ja dieses Feld ausliest und einen Gutenberg-Block erzeugt, der im Inserter als Block 'Eventdatum' angeboten wird. Der Block soll die gleichen Formatierungs-Möglichkeiten haben wie der Standardblock Überschrift, sowohl was den HTML-Tag als auch die Formatierungen betrifft. Verwende als Ausgabeformat jenes Format, das ACF als Rückgabeformat eingestellt hat. Schreibe das Plugin als reines PHP-Plugin, gib mir das Plugin als .zip-Datei. Bevor du das Plugin schreibst erkläre mir welche Risiken damit verbunden sind: was liest es, was kann das Plugin ändern, verbindet es sich nach aussen und wie wird das Plugin ausgelöst? Stelle Rückfragen bezüglich der fehlenden Details.
Risiken (für dieses Plugin gering):

Was liest es? Den Wert des ACF-Felds eventdatum des aktuellen Beitrags aus der Datenbank, über get_field().
Was kann es ändern? Nichts. Es speichert nichts, legt keine Dateien an und ändert keine Einstellungen.
Verbindet es sich nach außen? Nein.
Wie wird es ausgelöst? Beim Laden der Seite und beim Bearbeiten im Editor.
Restrisiko: Ungeschützte Ausgabe des Feldwerts. Ich gebe ihn mit esc_html() aus.

Rückfragen:
1. Soll immer der aktuelle Beitrag verwendet werden, oder auch in Query-Loops der jeweilige Beitrag?
2. “Existiert” heißt: Feld in ACF angelegt, oder für diesen Beitrag ein Wert gesetzt? Was soll bei “nein” passieren: nichts ausgeben, Platzhalter, Hinweis im Editor?
3. Name, Slug, Funktionspräfix, Text-Domain und Lizenz des Plugins?
4. Sprache für Blocktitel und Texte?
5. Mindestversionen für WordPress und PHP? ACF Free oder Pro?
6. Was, wenn ACF deaktiviert ist: still bleiben oder Hinweis im Backend?
7. “Reines PHP”: Für die Auswahl der Überschriftenebene im Editor braucht ein Block üblicherweise JavaScript. Variante A: dynamischer PHP-Block, Formatierungen über block.json, aber ohne Ebenenwahl. Variante B: eine kleine JS-Datei ohne Build-Schritt. Welche?
Antworten:
1. Der jeweils aktuelle Beitrag, auch in Query-Loops.
2. “Existiert” heißt: Der Beitrag hat einen nicht-leeren Wert. Sonst im Frontend nichts ausgeben, im Editor einen kurzen Hinweis “Kein Eventdatum vorhanden”.
3. Name “Eventdatum-Block”, Slug eventdatum-block, Präfix evdb_, Text-Domain wie Slug, Lizenz GPLv2 or later.
4. Deutsch.
5. Mindestversionen so wählen, wie der Block sie braucht, und im Header nennen. ACF Free reicht.
6. Im Frontend nichts ausgeben, im Backend einen Hinweis zeigen.
7. Ohne eigenes JavaScript. Seit WordPress 7.0 gibt es PHP-only-Blöcke. Die Überschriftenebene als Auswahlfeld in der Seitenleiste ist in Ordnung, Standard h2. Die Formatierungen wie beim Überschrift-Block.
Wer ein wenig Erfahrung mit LLMs gesammelt hat weiss: es kann schon ein wenig dauern, die Details zu klären. Ausserdem ist wichtig, dass du die Funktion innerhalb von WordPress wirklich verstehts, damit du die offenen Fragen der KI auch sinnvoll beantworten kannst. 

Das Ergebnis

Aktiviertes Plugin
Das Plugin kann über das Dashboard in der lokalen Site aktiviert werden.
Je nach KI-Modell und Performance bekommt man dann irgendwann ein fertiges .zip-Archiv angeboten. Dieses wird dann (siehe oben unter Workflow) in einer lokalen Umgebung installiert, aktiviert und danach getestet.
Wenn der erste Funktionstest durchgeführt wurde und auch der Plugin Check gut gelaufen ist kann es sinnvoll sein, das LLM eine Testreihe anzeigen zu lassen (was macht das Plugin, wenn ACF deaktiviert wurde?). Immerhin kann sich die KI viel mehr Szenarien vorstellen als man selber, das kann man nutzen. Fertig.
Eigenes Plugin Backend
Im Backend leicht zu erkennen (grün): das Eigene Plugin kann im Blockeditor einfach genutzt werden.

Bis jetzt habe ich ein paar kleine Plugins mit KI erstellt, u.a. ein Tool für EXIF-Daten in meinem Fotoblog form.at, ein Tool zur Sammlung von Hilfsseiten und Updateinfos für Plugins (nicht öffentlich). Zwei Tools sind auch hier auf der Website in Betrieb zu finden: im Artikel Wie alt ist dein WordPress? ist ein Tool im Einsatz, dass versucht das Alter einer WordPress-Site zu ermitteln. Aim Artikel WordPress System Wechseln? ist ein Flow-Chart-Tool, dass bei der Entscheidungsfindung helfen soll. 

Fazit

Es ist einfach ein Plugin schreiben zu lassen - aber es ist nicht trivial. Ich kann nur ausdrücklich davor warnen, dem LLM Dinge zu überlassen, die man nicht versteht - im Gegensatz dazu, können wir sehr wohl Dinge übergeben, die wir nicht können. Ein Trainer muss nicht spielen können, aber er muss das Spiel verstehen. Und so ist es hier auch: Wenn du weisst was du willst kann dir die KI ein gutes Plugin bauen.  

Veröffentlicht am: 9. Oktober 2026
Letztes Update am: 9. Oktober 2026

Hinterlasse den ersten Kommentar