JPKCom DB

WP Code Generator — Tipps & Tricks

Strategie und Stolperfallen für den WP Code Generator: Ausgabe prüfen, gemeinsame Felder, readme.txt-Regeln, 7.x-Snippets und sinnvolle Kombinationen.

Zurück zur Übersicht: WP Code Generator · Tool live öffnen: www.jpkc.com/tools/wp/

Das Manual beschreibt jeden Generator, die Beispiele zeigen die Abläufe. Hier geht es um das, was beides voraussetzt, aber selten dabeisteht: was der erzeugte Code dir abnimmt und was nicht, wo du genauer hinschauen solltest und wie du das Tool sinnvoll in deinen Workflow einbaust.

Code-Gerüst, nicht fertige Funktion

Der wichtigste Merksatz zuerst: Der WP Code Generator liefert Boilerplate, keine Lösung. Er nimmt dir die immer gleiche, fehleranfällige Tipparbeit ab — den Plugin-Header, die register_post_type()-Signatur, die Settings-API-Kaskade, die Rechteprüfungen einer REST-Route —, aber die eigentliche Logik steckt in den Funktionsrümpfen, die du selbst füllst.

  • Lies den Code, bevor du ihn übernimmst. Gerade die neuen Generatoren kommentieren ausführlich, warum etwas so gebaut ist: warum ein Zahl-Sanitizer ein eigener Helfer ist, warum der Standardbegriff einer Taxonomie unübersetzt bleibt, warum ein Passwort-Feld leer bleiben darf. Das Tool ist auch ein Spickzettel.
  • Warnungen ernst nehmen. Die gelbe Liste über der Ausgabe meldet nicht nur Tippfehler, sondern echte Fallstricke — etwa dass wp_insert_post() einen Beitrag ohne Titel, Inhalt und Auszug ablehnt oder dass sich ein Meta-Key mit Unterstrich nicht über die Core-Quelle core/post-meta an einen Block binden lässt.
  • Auf Ersatzwerte achten. Nicht jeder Generator prüft jedes Feld. Wo er es nicht tut, setzt er für leere Felder still einen Standard ein — bei Nav Menus etwa entsteht ohne eigenen Eintrag nur die Position primary, obwohl im Formular zwei Zeilen mit Platzhaltertext stehen. Prüfe also in der Ausgabe, ob alles drin ist, was du erwartest.
  • Das Tool kennt deine Installation nicht. Es weiß nicht, ob ein Hook existiert, ein Slug belegt ist oder eine Capability deinen Rollen zugewiesen ist. In den Generatoren Custom Post Type, Taxonomy und Post Status nennt es manche harten Grenzen von WordPress nur im Infotext: Post-Type-Slugs dürfen höchstens 20, Taxonomie-Slugs höchstens 32 Zeichen lang sein, und ein eigener Beitragsstatus darf nicht wie ein Core-Status heißen.

WordPress 7.x, PHP 8.3 und Coding-Standards

Der erzeugte Code zielt auf WordPress 7.0 als Minimum und PHP 8.3. Ein paar Dinge, die du im Kopf behalten solltest:

  • Requires PHP ehrlich setzen. Der Code nutzt moderne Syntax wie typisierte Signaturen, mixed, den Nullsafe-Operator ?-> und im Plugin-Generator eine typisierte Klassenkonstante (public const string VERSION), die es erst ab PHP 8.3 gibt. Senkst du Requires PHP im Plugin-Generator, lässt er den Typ der Konstante weg — den übrigen Code passt er nicht an. Wenn du ältere Server bedienen musst, prüfe die Syntax selbst.
  • Den ABSPATH-Schutz nicht wegkürzen. Die Zeile defined( 'ABSPATH' ) || exit; verhindert, dass eine PHP-Datei direkt über ihre URL aufgerufen wird. Wo das Tool sie weglässt, hat es einen Grund: uninstall.php prüft WP_UNINSTALL_PLUGIN, WP-CLI-Dateien prüfen WP_CLI.
  • Text Domain gleich Ordnername. Bei Plugin, Theme und Block Bindings folgt die Text Domain dem Slug. Überschreibst du sie, warnt das Tool — wordpress.org verlangt die Übereinstimmung, weil es Sprachpakete über den Slug zuordnet. Ein load_plugin_textdomain() brauchst du dank Domain Path im Header nicht mehr.
  • Versionen ohne Pflegeaufwand. Für eigene CSS- und JS-Dateien ist im Asset Enqueue-Generator die Versionsstrategie filemtime() eine gute Wahl: Der Browser lädt eine geänderte Datei automatisch neu. Baust du mit @wordpress/scripts, nimm stattdessen build/*.asset.php — dann stimmen Version und Abhängigkeiten.
  • Neuere Optionen gezielt einsetzen. Einige Theme- und Block-Optionen gibt es erst in WordPress 7.1 (etwa eigene Breakpoints oder responsive Stile). Das Tool markiert sie und warnt, wenn sie neuer sind als deine Mindestversion — WordPress 7.0 würde sie still ignorieren.

Gemeinsame Felder gezielt nutzen

Die Live-Übertragung von Autor, Text Domain und Präfix spart viel Tipparbeit, wenn du sie bewusst einsetzt:

  • Mit dem Plugin anfangen. Trag Autor und Autor-URI zuerst im Plugin-Generator ein. Der Autor landet sofort im Theme und in Block Bindings, die Autor-URI im Theme. Eine Text Domain oder ein Präfix, das du selbst tippst, verteilt sich genauso auf die übrigen Plugin-Generatoren — außer auf Plugin und Block Bindings, deren Text Domain immer ihrem Slug folgt. Werte, die das Tool nur abgeleitet hat, überträgt es nicht.
  • Theme und Plugin sind getrennt. Die Theme-Generatoren und das Feld Text Domain / Prefix der Snippets teilen sich eine eigene Text Domain. So kannst du Plugin und Theme parallel bauen, ohne dass sich die Werte gegenseitig überschreiben.
  • Selbst getippte Werte sind sicher. Die Übertragung füllt nur Felder, die du im Ziel-Generator noch nicht angefasst hast. Einen Sonderfall in einem einzelnen Generator trägst du dort einfach ein.
  • An fremden Rechnern aufräumen. Das Tool merkt sich die Werte im Browser. Arbeitest du an einem geteilten Rechner, klick zum Schluss auf Forget saved defaults — oder nutze gleich ein privates Fenster.

readme.txt und wordpress.org

Willst du ein Plugin im Verzeichnis von wordpress.org veröffentlichen, nimm die Warnungen des Plugin-Generators als Checkliste:

  • Höchstens fünf Tags, und plugin sowie wordpress zählen nicht — das Verzeichnis ignoriert beide, alles nach dem fünften Tag ebenso.
  • Die Kurzbeschreibung unter dem Header hat höchstens 150 Zeichen und kein Markup. Das Tool übernimmt sie aus der Description und kürzt sie wie der Parser von wordpress.org.
  • Stable tag nie trunk. Er folgt im Tool der Version; weichen beide voneinander ab, warnt es.
  • Tested up to und Stable tag gehören nicht in den Plugin-Header, sondern in die readme.txt — genau so teilt das Tool sie auf.
  • Nur GPL-kompatibel. Wählst du Proprietary, weist das Tool darauf hin, dass wordpress.org nur GPL-kompatible Plugins aufnimmt.

Snippets gezielt einsetzen

Die Snippet-Bibliothek ist bequem, aber kein Selbstläufer:

  • Must-use-Plugin statt functions.php. Das Standardformat ist eine eigene Datei für wp-content/mu-plugins/. Sie lädt automatisch, ohne Aktivierung, und ist schon aktiv, bevor die normalen Plugins laden. Die functions.php-Variante lädt erst nach allen Plugins — für Einstellungen, die Plugins beim Laden lesen, ist das zu spät.
  • Präfix setzen, Kollisionen vermeiden. Das Feld Text Domain / Prefix versieht die Funktionen der Snippets mit einem eigenen Präfix. Kombinierst du mehrere Snippets oder arbeitest neben fremdem Code, verhindert das doppelte Funktionsnamen.
  • Optionen prüfen, nicht blind kopieren. 24 Snippets haben ein Optionen-Panel. Disable Comments etwa kann die REST-Endpunkte für Kommentare für eingeloggte Nutzer behalten — die braucht die Funktion Notes im Block-Editor. Add Security Headers sendet Strict-Transport-Security nur, wenn du es ausdrücklich anhakst.
  • Verstehen, was abgeschaltet wird. Disable XML-RPC trennt Dienste, die noch über XML-RPC sprechen. Disable Public REST API und Hide Users REST Endpoint können Plugins stören, die die REST-API ohne Anmeldung nutzen. Setz solche Snippets nur ein, wenn du die Abhängigkeiten kennst.
  • Alt-Texte zentral pflegen, aber bewusst. Gutenberg Image Alt Text gibt bei Bild-Blöcken den Alt-Text aus der Mediathek aus und ersetzt damit den im Block gespeicherten. Das lohnt sich, wenn deine Redaktion Alt-Texte in der Mediathek pflegt; ein im Block angepasster, kontextbezogener Alt-Text wird dann aber nicht mehr ausgegeben (gespeichert bleibt er, und ohne das Snippet erscheint er wieder). Bilder ohne Mediathek-Bezug, etwa per URL eingefügte, bleiben unberührt. Ist der Mediathek-Eintrag leer oder enthält nur Leerzeichen, bleibt der Block-Wert stehen.
  • Security-Header gehören auf den Server. Das Snippet Add Security Headers setzt Header per PHP und nur für das Frontend. Wo du Zugriff auf die Server-Konfiguration hast, ist sie dort meist besser aufgehoben — das Snippet ist die portable Notlösung.
  • Die 7.x-Schalter kennen. Die Gruppe WordPress 7.x & Editor bündelt, was Kunden oft fragen: KI-Funktionen abschalten, Notes abschalten, die Font Library abschalten (auf Wunsch samt Google-Fonts-Sammlung), den Editor ohne Inhalte von wordpress.org betreiben oder Abilities aus der REST-API nehmen. Für die KI gibt es zusätzlich die Konstante WP_AI_SUPPORT im WP-Config-Generator.

Die richtigen Generatoren kombinieren

Viele Aufgaben brauchen mehrere Generatoren nacheinander. Typische Ketten:

  • Plugin + Datentypen + Block Bindings. Erst das Plugin, dann Custom Post Type (mit show_in_rest und custom-fields) und Taxonomy, dann die Felder — entweder als Post Meta Field mit dem Schalter Block Bindings, der das Feld an Core-Blöcke bindbar macht, oder gleich als eigene Quelle mit dem Block Bindings-Generator.
  • Block-Theme + Patterns + Styles. Der Theme-Generator liefert ein Pattern und Style-Variationen mit. Weitere Patterns holst du dir aus Block Patterns im Modus Theme, eigene Stile für Core-Blöcke aus Block Styles, Varianten aus Block Variations.
  • Inhalte für KI und Automationen öffnen. Eine Abilities API-Fähigkeit beschreibt, was ein Agent tun darf, inklusive Schemas und Rechten. Brauchst du einen klassischen Endpunkt für eigene Anwendungen, nimm REST Route. Willst du selbst ein KI-Modell ansprechen, liefert AI Prompt die Funktion dazu.
  • Einstellungen + Hinweis. Eine Settings Page für den API-Schlüssel, dazu eine Admin Notice auf der Einstellungsseite — die Voreinstellung „API key missing." passt dazu. Die Screen ID des Hinweises musst du aber an die Einstellungsseite anpassen: toplevel_page_<menu-slug> für die voreingestellte Top-Level-Seite, settings_page_<menu-slug> für eine Unterseite unter Settings (options-general.php). <menu-slug> ist dabei der Menu Slug der Settings Page (Standard my-plugin-settings), nicht die Text Domain, aus der der Admin-Notice-Generator seine Vorbelegung settings_page_my-plugin ableitet. Die Prüfung, ob der Schlüssel fehlt, ergänzt du selbst in der Funktion.
  • Dashicons als Zulieferer. Wann immer ein Generator ein Icon will — Custom Post Type, Block, Block-Variante —, liefert der Dashicons-Browser den Namen per Klick, wahlweise schon im Format für block.json.

Mit anderen JPKCom-Tools kombinieren

Der WP Code Generator erzeugt das Gerüst — diese Tools schließen den Workflow:

  • Beautify — formatiert JavaScript, CSS und HTML. Wenn du das JS eines generierten Blocks oder das Theme-CSS nach eigenen Anpassungen wieder sauber einrücken willst, ist das der richtige Ort. (Hinweis: Beautify deckt JS/CSS/HTML ab, nicht PHP.)
  • Source Viewer — zeigt Quellcode in über 100 Sprachen mit Syntax-Highlighting; gut, um einen generierten Schnipsel in Ruhe zu lesen, zu prüfen oder weiterzugeben.
  • SEO & GEO Analyzer — wenn das Plugin oder Theme live ist, prüfst du die ausgelieferte Seite hier auf SEO, KI-Readiness und Technik. So schließt sich der Kreis vom Code bis zur fertigen, optimierten Seite.

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jeden Generator und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.