# 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. Source: https://www.jpkc.com/db/tools/wp/tips/ Zurück zur Übersicht: [WP Code Generator](https://www.jpkc.com/db/tools/wp/) · Tool live öffnen: [www.jpkc.com/tools/wp/](https://www.jpkc.com/tools/wp/) Das [Manual](https://www.jpkc.com/db/tools/wp/manual/) beschreibt jeden Generator, die [Beispiele](https://www.jpkc.com/db/tools/wp/examples/) 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. - **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." und die Screen-ID `settings_page_` passen genau dazu; 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](https://www.jpkc.com/db/tools/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](https://www.jpkc.com/db/tools/source/)** — 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](https://www.jpkc.com/db/tools/seo/)** — 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](https://www.jpkc.com/db/tools/wp/) zum großen Bild, das [Manual](https://www.jpkc.com/db/tools/wp/manual/) für jeden Generator und die [Beispiele](https://www.jpkc.com/db/tools/wp/examples/) für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im [Tool](https://www.jpkc.com/tools/wp/).