JPKCom DB

WP Code Generator — Manual

Vollständige Funktionsbeschreibung des WP Code Generators: alle 33 Generatoren und 40 Snippets, Dateien, ZIP, gemeinsame Felder, Prüfungen und Grenzen.

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

Dieses Manual beschreibt den WP Code Generator vollständig: wie die Oberfläche aufgebaut ist, wie Generierung, Ausgabe und Speicherung funktionieren, was jeder der 33 Generatoren macht und welche Felder er anbietet, was die Snippet-Bibliothek enthält und wo die Grenzen liegen. Die Oberfläche des Tools ist auf Englisch — Generator- und Feld-Bezeichnungen stehen hier deshalb in ihrer englischen Original-Schreibweise (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

Aufbau und Bedienung

Das Tool ist zweigeteilt: links eine Seitenleiste mit allen Generatoren in neun Gruppen, rechts der Arbeitsbereich des gewählten Generators — oben das Formular, darunter die Ausgabe. Beim Laden ist der Plugin-Generator aktiv.

Live-Generierung

Sobald du ein Feld änderst, baut das Tool den Code nach 300 Millisekunden neu, damit es beim Tippen nicht ruckelt. Die Schaltfläche Generate oben rechts im Formular erzeugt den Code sofort und scrollt zur Ausgabe. Außer Plugin und den Code Snippets, die schon beim Laden erzeugt werden, läuft jeder Generator erst, wenn du ihn in der Seitenleiste öffnest, und bei jedem erneuten Öffnen wieder — so übernimmt er auch Werte, die du inzwischen in einem anderen Generator eingetragen hast. Die Code Snippets reagieren ohne Verzögerung.

Ausgabe-Editor

Die Ausgabe steht in einem schreibgeschützten ACE-Editor mit Syntax-Hervorhebung. Für PHP, JavaScript, JSON, CSS, HTML und SVG prüft der Editor die Syntax im Hintergrund und markiert Fehler am Zeilenrand (außer bei den HTML-Templates eines Block-Themes und bei js/abilities.js der Abilities API, wenn Load server abilities in the client aktiv ist). Ändern kannst du den Code dort nicht — dafür kopierst oder lädst du ihn herunter.

Mehrere Dateien in Reitern

Acht Generatoren können mehrere Dateien erzeugen und zeigen sie in Reitern über dem Editor, beschriftet mit dem Dateipfad: Plugin, Theme, Gutenberg Block, Abilities API, SVG Icons, Block Bindings, Block Patterns und Block Styles. Welche Dateien entstehen, hängt von den Optionen ab; fällt eine Datei weg, verschwindet ihr Reiter, damit nichts Veraltetes in Kopie, Download oder Archiv landet.

Copy, Download und ZIP

  • Copy legt den Inhalt des Editors — bei mehreren Dateien den des aktiven Reiters — in die Zwischenablage.
  • Download speichert denselben Inhalt als Datei. Einzeldatei-Generatoren verwenden sprechende Namen (hooks.php, cpt.php, settings-page.php, rest-route.php …; bei WP-CLI Command, Block Variations und den Snippets abhängig von der Eingabe), Mehrdatei-Generatoren den Namen der Datei im aktiven Reiter.
  • ZIP gibt es bei Plugin, Theme, Gutenberg Block und Block Bindings. Ein Klick erzeugt den Code neu und packt alle Dateien in einen Ordner, der nach dem Plugin- oder Theme-Slug bzw. dem Blocknamen heißt — etwa book-shelf.zip mit book-shelf/book-shelf.php, book-shelf/readme.txt und book-shelf/uninstall.php. Als Plugin mit Header (bei Gutenberg Block: Registration „Plugin“, ohne Build-Schritt) und als Theme lässt sich das Archiv so direkt über den Plugin- bzw. Theme-Upload im WordPress-Backend installieren; im Modus @wordpress/scripts musst du vorher bauen. Solange rot markierte Felder das Erzeugen verhindern — ein ungültiger Slug, bei Block Bindings jeder harte Fehler —, entsteht kein Archiv; ein Hinweis bittet dich, zuerst die rot markierten Felder zu korrigieren.

Gibt es noch keinen Code zum Kopieren oder Laden, meldet das Tool „Generate code first by switching to this tab.“

Gemeinsame Felder und Speicherung im Browser

Manche Angaben brauchst du in fast jedem Generator. Das Tool behandelt sie als gemeinsame Felder:

  • Author (Plugin, Theme, Block Bindings) und Author URI (Plugin, Theme),
  • die Text Domain der Plugin-artigen Generatoren,
  • die Theme-Text-Domain — getrennt davon — für Theme, Nav Menus, Sidebar / Widget Area, Block Patterns und das Feld Text Domain / Prefix der Code Snippets,
  • das Function Prefix der Generatoren, die eines haben (außer bei Nav Menus, Sidebar / Widget Area und Block Patterns, deren Präfix zum Theme gehört, und außer dem Table Prefix der wp-config.php).

Tippst du in eines dieser Felder, überträgt das Tool den Wert sofort in die passenden Felder der anderen Generatoren — aber nur in Felder, die du dort noch nicht selbst geändert hast. Leerst du das Quellfeld, fallen die unberührten Ziele auf ihren Standardwert zurück. In die Text Domain von Plugin und Block Bindings überträgt das Tool nichts: Beim Plugin folgt sie dem Slug, bei Block Bindings gilt ein leeres Feld als Slug, denn sie soll dem Ordnernamen entsprechen. Was du dort eintippst, geht aber wie bei den anderen Feldern an die übrigen Generatoren weiter.

Zusätzlich merkt sich dein Browser diese Werte im localStorage (Schlüssel jpktools_wp_common, je Wert höchstens 200 Zeichen) und setzt sie beim nächsten Besuch in die Felder ein, die noch ihren Ausgangswert haben (meist leer, bei vier Text-Domains my-plugin). Die Schaltfläche Forget saved defaults am Fuß der Seitenleiste löscht den gespeicherten Stand; die Felder behalten ihre aktuellen Werte bis zum Neuladen. Ohne verfügbaren Browser-Speicher — etwa in einem privaten Fenster mit gesperrtem Speicher — funktioniert das Tool trotzdem, es merkt sich dann nur nichts.

Abgeleitete Felder

Viele Felder folgen einem anderen, bis du sie selbst änderst: der Plugin-Slug dem Plugin-Namen, die Plugin-Text-Domain dem Slug, der Stable Tag der Version, beim Theme der Slug dem Namen und die Tags den gewählten Optionen, bei Block Bindings die Quelle und der Custom Block dem Slug, bei Admin Notice Screen-ID, Notice-ID und Funktionsname der Text Domain. Überschreibst du ein solches Feld, bleibt dein Wert stehen. Zwei Ausnahmen: Beim Plugin setzt jede Änderung am Namen den PHP namespace neu, beim WP-CLI Command jede Änderung am Kommandonamen den Klassennamen.

Prüfungen, Warnungen und Fehler-Dateien

  • Rote Felder: Wo das Tool eine Eingabe prüft — Slugs, Namespaces, Callback-Namen, die PHP-Schlüsselwörter sind, Regex-Muster, JSON —, markiert es ungültige Werte rot, meist mit einem Hinweis darunter.
  • Fehler-Dateien: Plugin (bei ungültigem Slug), Abilities API, SVG Icons, Block Bindings, Block Patterns, Block Styles, Block Variations, REST Route, Admin Notice und AI Prompt erzeugen bei harten Fehlern keinen Code, sondern eine PHP-Datei, die außer dem Dateikopf nur Kommentare enthält und nichts registriert: „Nothing is registered: fix the fields marked in red first.“ und darunter die Fehlerliste. Deine fehlerhafte Eingabe wiederholt sie bewusst nicht.
  • Ersatzwerte: Die übrigen Generatoren setzen für leere oder unbrauchbare Felder einen Standardwert ein — manche mit Warnung (etwa Gutenberg Block), manche still — oder überspringen eine Tabellenzeile.
  • Warnungen: Fachliche Hinweise, die den Code nicht verhindern, erscheinen als gelbe Liste über der Ausgabe — etwa ein Tag, den wordpress.org ignoriert, eine Text Domain, die nicht zum Slug passt, oder ein REST-Endpunkt zum Anlegen, dem Titel, Inhalt und Auszug fehlen.

Zielversion und Code-Stil

Der erzeugte Code richtet sich an WordPress 7.0 als Minimum, ist gegen 7.1 ausgelegt und setzt PHP 8.3 voraus. Diese Werte stehen als Vorgabe in den Versionsfeldern von Plugin und Theme (Requires WP 7.0, Tested up to 7.1, Requires PHP 8.3; im Header wird daraus Requires at least); JSON-Schemas zeigen standardmäßig auf wp/7.1. PHP-Dateien beginnen durchgängig mit declare(strict_types=1); und dem Schutz defined( 'ABSPATH' ) || exit;. Ausnahmen sind begründet: uninstall.php prüft stattdessen WP_UNINSTALL_PLUGIN, WP-CLI-Dateien prüfen WP_CLI, die wp-config.php hat einen eigenen Aufbau, und das wp_nav_menu()-Schnipsel ist ein Template-Aufruf ohne Dateikopf. Außerdem hat die render.php eines Blocks nur den ABSPATH-Schutz, die *.asset.php-Dateien geben nur ein Array zurück, und Snippets im Format „Paste into functions.php“ haben gar keinen Dateikopf. Übersetzbare Texte laufen durch __() und Co. mit literaler Text Domain, damit wp i18n make-pot sie findet.

Gruppe „Plugin & Theme"

Plugin

Erzeugt ein vollständiges Plugin aus bis zu drei Dateien: die Hauptdatei <slug>.php, eine readme.txt für wordpress.org und optional eine uninstall.php. ZIP ist verfügbar.

  • Header-Felder: Plugin Name, Plugin slug (Ordner- und Dateiname, folgt dem Namen), Text Domain (folgt dem Slug), PHP namespace (Standard: der Name in PascalCase — wird bei jeder Namensänderung neu gesetzt), Main class (Standard Plugin), Version, License (GPL-2.0-or-later, GPL-3.0-or-later, MIT, Proprietary), Author, Author URI, Plugin URI, Update URI, Requires WP (7.0), Requires PHP (8.3), Requires Plugins (wordpress.org-Slugs, WordPress blockiert dann die Aktivierung, solange ein benötigtes Plugin fehlt oder inaktiv ist), Network (nur für Multisite-Netzwerk-Aktivierung), Description (eine Zeile, höchstens 140 Zeichen).
  • Der Code: Header in der dokumentierten Reihenfolge, immer mit Domain Path: /languages — ein load_plugin_textdomain() ist nicht mehr nötig. Danach Namespace und eine final class als Singleton mit VERSION-Konstante (ab PHP 8.3 typisiert), init() auf dem init-Hook sowie Aktivierungs- und Deaktivierungs-Methode; die Aktivierung speichert die Version als Option <slug>_version (Bindestriche als Unterstriche, etwa book_shelf_version).
  • readme.txt: Die Felder Contributors, Tags (höchstens fünf), Donate link, Tested up to (7.1), Stable tag (folgt der Version), Long description (Markdown) und Upgrade notice (höchstens 300 Zeichen) gehören nicht in den Plugin-Header und landen deshalb nur hier. Das Tool wendet die Regeln des wordpress.org-Parsers an: plugin und wordpress als Tags werden entfernt, ab dem sechsten Tag abgeschnitten und die Kurzbeschreibung auf 150 Zeichen gekürzt — jeweils mit Warnung. Die GPL-Lizenzen schreibt die readme.txt in der Kurzform („GPLv2 or later“ bzw. „GPLv3 or later“); bei Proprietary warnt das Tool, dass wordpress.org nur GPL-kompatible Plugins aufnimmt.
  • uninstall.php (Standard: an) löscht die Versions-Option, auf Multisite für jede Site.

Theme

Erzeugt ein Block-Theme oder ein klassisches Theme, jeweils auch als Child-Theme. ZIP ist verfügbar.

  • Grundfelder: Theme Name, Theme slug (Ordnername), Text Domain (leer = Slug), Version, Author, Author URI, Theme URI, Parent Theme (gefüllt = Child-Theme), Requires WP, Tested up to, Requires PHP, Description, Footer Text und Tags (schlägt passende Tags aus den Optionen vor).
  • Block Theme (Full Site Editing) schaltet auf Block-Theme um und öffnet die Optionen in Akkordeons: theme.json-Schema (wp/6.9 bis trunk, Standard wp/7.1; version bleibt 3), Farbpalette mit vier Farben und Verlauf, optional ein Duotone-Filter primary-base (color.duotone), Content- und Wide-Breite, Schriften (Systemschriften oder eine eigene Schriftdatei), flüssige Typografie, Absatzeinzug (Paragraph text indent, 7.0), Abstände, Dimension-Presets narrow/half (7.0), Schatten, Radien, Zustände wie :focus-visible für Buttons, Textschatten für Überschriften (7.1), responsive Stile für @mobile/@tablet und eigene Breakpoints (7.1), die Templates index, home, single, page, archive, search, 404 und optional blank, Template Parts für Header, Footer und Navigation-Overlay (7.0) — für header.html und footer.html wählst du die Area (Area of header.html/Area of footer.html: uncategorized, header, footer oder navigation-overlay) —, Style-Variationen als Tabelle (die erste ist die invertierte Palette, also „Dark" für ein helles Theme), ein Section Style, ein Pattern und ein Editor-Stylesheet.
  • Klassisch erzeugt style.css, functions.php mit den üblichen add_theme_support()-Aufrufen, zwei Menüpositionen und einer Sidebar, dazu index.php, header.php, footer.php, comments.php und optional assets/js/main.js (mit defer im Footer).
  • Child-Themes bleiben schlank: style.css mit Template:-Header, functions.php und beim Block-Theme eine fast leere theme.json — eigene Presets würden die Listen des Eltern-Themes ersetzen. Templates, Template Parts, Style-Variation und Section Style entfallen; je nach Optionen kommen beim Block-Theme das Pattern und das Editor-Stylesheet hinzu, beim klassischen Child-Theme assets/js/main.js. Für klassische Child-Themes gibt es den Schalter Parent loads its stylesheet with get_stylesheet_uri() (etwa Twenty Fifteen bis Seventeen, Twenty Twenty): Ist er an, registriert das Child die style.css des Eltern-Themes unter dessen Handle <parent>-style und lädt sie vor der eigenen; ist er aus, bindet es nur die eigene style.css mit Priorität 20 ein — richtig für Eltern-Themes, die ihr Stylesheet selbst über get_template_directory_uri() oder get_parent_theme_file_uri() laden.

Code-Identität wie Funktionspräfix und Handles folgt dem Slug, die Text Domain nur den Übersetzungsaufrufen. Das Tool warnt, wenn gewählte Optionen neuer sind als das Schema oder die eingetragene Mindestversion. Die Schriftdatei selbst liefert es nicht mit — du legst sie unter assets/fonts/<familie>/<datei>.woff2 ab (das Tool zeigt den genauen Pfad an).

Registriert Menüpositionen mit register_nav_menus() auf after_setup_theme. Felder: Function Prefix, Text Domain und eine Tabelle mit Location ID und Label. Achtung: Die beiden vorbelegten Zeilen enthalten nur Platzhaltertext — trägst du nichts ein, entsteht nur die Position primary.

Erzeugt den Aufruf, der ein Menü ausgibt, als Schnipsel für ein Template. Felder: theme_location, container (nav, div oder false), depth, container_class, container_id, container_aria_label, menu_class, menu_id, fallback_cb (Standard, false oder eigene Funktion), item_spacing sowie die Optionen echo und Generate custom Walker class mit einer Walker_Nav_Menu-Unterklasse. Standardwerte bei depth, fallback_cb, echo und item_spacing sowie leere Felder lässt das Tool weg; theme_location und container schreibt es immer.

Registriert Widget-Bereiche mit register_sidebar() auf widgets_init. Felder: Function Prefix, Text Domain, Widget Wrapper Tag (section, div, aside, li oder eigenes HTML), Title Tag und eine Tabelle mit ID, Name und Beschreibung je Bereich. Wie bei Nav Menus stehen in der vorbelegten Zeile nur Platzhalter; ohne Eintrag entsteht primary-sidebar.

Gruppe „Blocks & Editor"

Gutenberg Block

Erzeugt einen Block mit block.json (apiVersion 3) in drei Modi — ZIP ist verfügbar, der Ordner heißt wie der Block:

  • No build step (Standard): Hauptdatei, block.json, index.js mit den window.wp-Globals, index.asset.php sowie je nach Optionen render.php, style.css und editor.css, view.js und view.asset.php.
  • @wordpress/scripts: Hauptdatei, package.json mit Build-Skript und die Quellen unter src/<block>/ in JSX; registriert wird über wp_register_block_types_from_metadata_collection() und die blocks-manifest.php.
  • PHP only: nur eine PHP-Datei mit register_block_type() und autoRegister (WordPress 7.0) — die Bedienelemente erzeugt der Editor dann selbst für Text-, Zahl- und Wahrheitswerte.

Felder: Namespace und Block Name, Title, Text Domain, Category (auch eine eigene Kategorie), Icon (Dashicon), Keywords, Description, Registration (Plugin mit Header oder register.php zum Einbinden), block.json schema, Dynamic block (render.php, Standard: an), Stylesheets, Interactivity API (view.js) samt globalem Zustand, eine Attribut-Tabelle (Typ, Default, Enum, Source, Selector, Rolle), Block Bindings attributes und ein Akkordeon mit Supports, in das nur Werte geschrieben werden, die vom WordPress-Standard abweichen. Unter Advanced fields folgen Version, example, parent, ancestor, allowedBlocks, usesContext, providesContext, Block-Styles und blockHooks. Ungültige Namen fallen hier mit Warnung auf my-plugin/my-block zurück, statt die Ausgabe zu blockieren.

SVG Icons

Nutzt die Icons API aus WordPress 7.1: Registriert eine eigene Icon-Collection mit wp_register_icon_collection() und Icons mit wp_register_icon(), auf Wunsch entfernt es Core-Icons. Felder: Collection Slug (core ist vergeben), Function Prefix, Text Domain, Collection Label, Collection Description, eine Icon-Tabelle mit Name, Label, Quelle (SVG direkt im Code oder als Datei icons/<name>.svg) und Markup, Unregister core icons und ein Nutzungsbeispiel mit wp_get_icon(). Die Registrierung prüft zuerst, ob die Funktion existiert, damit das Plugin auch unter 7.0 lädt.

Hilfreich ist die SVG-Prüfung: Das Tool gleicht dein Markup mit dem, was der Sanitizer von WordPress durchlässt, ab — erlaubt sind nur <svg>, <path> und <polygon> mit wenigen Attributen — und meldet Kreise, Rechtecke, stroke-Attribute, feste Farben statt currentColor oder eine fehlende viewBox, bevor WordPress sie stillschweigend entfernt.

Block Bindings

Erzeugt ein komplettes Plugin, das eine eigene Block-Bindings-Quelle registriert: Blöcke im Editor zeigen dann Werte aus Post-Meta-Feldern an und können sie auf Wunsch auch bearbeiten. ZIP ist verfügbar. Dateien: <slug>.php, assets/editor.js, dazu block-markup.html und pattern-overrides.html als Beispiel-Markup zum Einfügen.

Felder: Plugin Name, Plugin Slug, PHP Namespace, Text Domain, Author, Version, Source Name (namespace/name, core/… ist verboten), Source Label, Kontext (postId und postType immer, optional termId, taxonomy und eigene Schlüssel), Post Types, Editable in the editor und eine Feld-Tabelle mit Feldname, Label, Typ, Meta-Key und Sanitizer. Optional kannst du einen eigenen Block für Bindings und Pattern Overrides freischalten (Custom Block, Bindable Attributes).

Der PHP-Teil registriert die Meta-Felder mit Rechteprüfung, die Quelle mit register_block_bindings_source() und liest Werte nur aus, wenn der Beitrag öffentlich sichtbar oder für dich lesbar und nicht passwortgeschützt ist — dieselben Prüfungen wie die Core-Quelle core/post-meta. Das JavaScript meldet die Quelle mit registerBlockBindingsSource() im Editor an und listet die Felder zur Auswahl.

Block Patterns

Erzeugt ein Block-Pattern — im Modus Theme als Datei patterns/<name>.php mit Header, die WordPress automatisch findet (bei eigener Kategorie zusätzlich inc/block-pattern-categories.php), im Modus Plugin mit register_block_pattern() und separater Markup-Datei. Felder: Mode, Namespace, Pattern Name, Title, Description, Text Domain, Function Prefix, Content (Vorlagen Hero, Call to action, Three columns oder eigenes Block-Markup), die Texte der Vorlage, Core-Kategorien, eine eigene Kategorie, Keywords, Block Types, Post Types, Template Types, Viewport Width und Inserter. Texte der Vorlagen landen übersetzbar als esc_html_e() in der Datei. Eigenes Markup prüft das Tool auf offene oder überkreuzte Blöcke, ungültiges JSON und Inhalt außerhalb von Blöcken.

Block Styles

Registriert einen Block-Stil (Klasse is-style-<name>) für einen oder mehrere Blöcke mit register_block_style(). Die Gestaltung kommt aus einer von drei Quellen: style_data (Werte wie in theme.json — Hintergrund, Text, Innenabstand, Rahmen), inline_style (CSS-Text) oder style_handle (ein eigenes Stylesheet, das das Tool mit erzeugt und beim Rendern der Blöcke lädt). Dazu kommen Label, Text Domain, Default style und Remove Styles, um vorhandene Stile im PHP und im Editor zu entfernen.

Block Variations

Erzeugt Block-Varianten — im Modus Filter über get_block_type_variations für jeden in PHP registrierten Block (Standard core/group), im Modus variations.php als Datei für einen eigenen Block. Je Zeile: Name, Titel, Beschreibung, Icon, Attribute (JSON), Inner Blocks (JSON), isActive, Keywords, Scope und Default. Das Tool warnt, wenn isActive auf ein Attribut zeigt, das die Variante gar nicht setzt — dann erkennt der Editor sie nicht wieder.

Gruppe „Hooks & Assets"

Hook (Action / Filter)

Erzeugt eine Callback-Funktion samt add_action() bzw. add_filter(). Felder: Type, Hook Name (mit Vorschlagsliste gängiger Core-Hooks und zwei WooCommerce-Hooks), Priority, Accepted Args, Callback Function Name und Typed parameters (known hooks). Wählst du einen bekannten Hook wie save_post, pre_get_posts oder the_title, stellt das Tool Typ und Parameterzahl selbst ein und schreibt die echten Parametertypen in die Signatur; unbekannte Parameter werden mixed und optional — außer dem ersten Parameter eines Filters, dem Wert $value. Priorität und Parameterzahl lässt es weg, wenn sie dem Standard entsprechen.

Cron Event

Erzeugt ein geplantes Ereignis mit wp_schedule_event(), geschützt gegen doppeltes Einplanen, samt Callback und Aufräumen per wp_clear_scheduled_hook() bei der Deaktivierung — über register_deactivation_hook(), das nur aus der Haupt-Plugin-Datei greift; in Themes und mu-plugins räumst du selbst auf. Felder: Event Hook Name, Callback Function Name, Schedule (Hourly, Twice Daily, Daily, Weekly oder ein eigenes Intervall in Minuten oder Stunden, das über cron_schedules registriert wird), Schedule via (Plugin-Aktivierung oder init für Themes und mu-plugins) und Text Domain.

Asset Enqueue

Erzeugt das saubere Registrieren und Einbinden von CSS, klassischem JavaScript oder einem Script-Modul. Felder: Type, Handle / Module ID, Enqueue Hook (Frontend, Admin, Login, enqueue_block_assets, enqueue_block_editor_assets), Relative paths from (Plugin oder Theme), Source, Dependencies, Version Strategy (fester String, filemtime(), die build/*.asset.php von @wordpress/scripts, false oder null), Media, Loading strategy (defer/async), fetchpriority, In Footer, JS translations und Text Domain. Zwei praktische Einschränkungen: auf eine bestimmte Admin-Seite (Hook-Suffix) oder nur auf den Editor-Inhalt bei enqueue_block_assets.

Shortcode

Erzeugt einen Shortcode mit add_shortcode() auf init und eine Render-Funktion mit shortcode_atts() und Ausgabepufferung. Felder: Shortcode Tag (ohne Leerzeichen und ohne & / < > [ ] =), Callback Function Name, Has inner content und eine Attribut-Tabelle mit Standardwerten.

oEmbed Provider

Registriert eigene oEmbed-Anbieter mit wp_oembed_add_provider(). Felder: Function Prefix, Register on Hook und eine Tabelle mit URL-Muster, Endpunkt und Regex-Schalter. Ohne ausgefüllte Zeile setzt das Tool einen Beispiel-Anbieter ein.

WP-CLI Command

Erzeugt eine Klasse, die von WP_CLI_Command erbt, und registriert sie mit WP_CLI::add_command(). Felder: Command name, Class name, Namespace, Description und WP-CLI guard (die Datei endet sofort, wenn sie nicht über WP-CLI geladen wird). Unter Subcommands legst du Unterbefehle mit Alias, @when, Beschreibung, Beispiel und Argumenten an — Positionsargumente, --key=<value> mit Standardwert und Auswahl sowie Flags. Das Tool erzeugt daraus die PHPDoc-Syntax, die WP-CLI für die Hilfe liest. Der Dateiname folgt dem Kommando, etwa my-plugin-cli.php.

Gruppe „Data Types"

Custom Post Type

Erzeugt register_post_type() auf init mit dem vollständigen Label-Satz. Felder: Post Type Slug, Singular Label, Plural Label, Text Domain, Dashicon, Menu Position, Description, die Schalter public, show_in_rest, has_archive, hierarchical, show_in_nav_menus, show_in_admin_bar, exclude_from_search und can_export, die Supports (inklusive editor notes), capability_type, Taxonomies, Rewrite-Slug und with_front, rest_base, rest_namespace, delete_with_user, embeddable sowie ein Block-Template als JSON mit template_lock. Kommentare im Code weisen darauf hin, wenn der Block-Editor ohne show_in_rest fehlt oder Meta-Felder ohne custom-fields nicht in REST und Block Bindings erscheinen. Den Slug prüft das Tool nicht — WordPress erlaubt höchstens 20 Zeichen.

Taxonomy

Erzeugt register_taxonomy() mit dem Label-Satz passend zu hierarchischen oder schlagwortartigen Taxonomien. Felder: Taxonomy Slug (höchstens 32 Zeichen, ungeprüft), Labels, Object Types, Text Domain, Rewrite-Optionen, die Sichtbarkeits-Schalter, sort, Meta box (Standard oder keine), rest_base, rest_namespace und ein Default term, dessen Name bewusst unübersetzt bleibt, damit nicht je Sprache ein eigener Begriff entsteht.

Post Status

Registriert einen eigenen Beitragsstatus mit register_post_status(). Felder: Status Slug, Labels für Einzahl und Zählung, Text Domain, Visibility (protected, public, private oder internal), die Schalter für Suche und Listen sowie Show as post state in list tables. Der Kommentar im Code hält fest, was oft überrascht: Der Block-Editor bietet trotzdem nur seine fünf eingebauten Status an.

Post Meta Field

Registriert ein Meta-Feld mit register_post_meta(). Felder: Post Type (leer = alle), Meta Key, Function Prefix, Type, Default Value, Text Domain, Description, Label, das REST-Schema für Arrays und Objekte, single, show_in_rest, revisions_enabled, Block Bindings sowie Auth Callback und Sanitize Callback. Der Sanitizer wird je Typ vorgeschlagen; für Zahlen erzeugt das Tool einen eigenen Helfer, weil floatval() als Callback mit mehreren Argumenten einen Fehler wirft. Mit Block Bindings erzwingt es show_in_rest und single und warnt vor geschützten Schlüsseln mit Unterstrich, die sich nicht binden lassen.

Term Meta Field

Wie Post Meta Field (ohne Block Bindings und revisions_enabled), aber mit register_term_meta() für eine Taxonomie. Zusätzlich gibt es Generate form field integration: Das Tool erzeugt dann die Formularfelder für die Seiten „Neuer Begriff" und „Begriff bearbeiten" samt Nonce, Rechteprüfung und Speichern.

Gruppe „APIs"

Abilities API

Registriert eine Ability — eine Fähigkeit deiner Website, die KI-Assistenten, MCP-Clients, REST-Automationen und der AI Client von WordPress aufrufen können. Ausgabe: abilities.php, optional js/abilities.js.

  • Name und Kategorie: Namespace, Ability Slug (zusammen namespace/slug), Function Prefix, Text Domain, Category (eigene Kategorie oder die Core-Kategorien site und user).
  • Beschreibung: Label und Description — die Beschreibung ist für Agenten geschrieben und sollte sagen, was die Ability liefert und wann sie sinnvoll ist.
  • Schemas: Input (keine Parameter, ein einzelner Wert oder ein Objekt mit Eigenschaften-Tabelle) und Output (nichts, ein Wert, ein Objekt oder eine Liste). Die Input-Tabelle kennt Typ, Pflicht, Standardwert, Enum, Minimum und Maximum, Längen, Muster und Format; die Output-Tabelle Typ, Listen-Typ, Format, Beschreibung und Pflicht. Beim Objekt-Input lehnt das Schema unbekannte Eigenschaften standardmäßig ab (Reject unknown properties, 'additionalProperties' => false, abschaltbar).
  • Rechte und Verhalten: Permission (Capability, eingeloggte Nutzer oder öffentlich), die Annotationen readonly, destructive und idempotent — daraus ergibt sich die HTTP-Methode (GET, POST oder DELETE) —, public (7.1), show_in_rest und die MCP-Angaben public, type und uri.
  • Extras: Callbacks als benannte Funktionen oder Closures, ein Nutzungsbeispiel in PHP und curl, Platzhalter für neun Lifecycle-Hooks (sieben davon neu in 7.1), ein Beispiel mit dem AI Client und eine clientseitige Ability (js/abilities.js), die auf Wunsch auch die Server-Abilities in den Client lädt (Load server abilities in the client, @wordpress/core-abilities).

Mit den Voreinstellungen entsteht eine funktionierende Ability get-recent-posts, die die neuesten Beiträge liefert. Das Muster für eigene Eingaben prüft das Tool doppelt — als JavaScript-Regex und auf Verträglichkeit mit PHP —, weil beide Seiten das Schema auswerten.

REST Route

Registriert eine eigene REST-Route mit register_rest_route(). Ausgabe: rest-route.php.

  • Route: Namespace (etwa my-plugin/v1), Route, ID segment (erzeugt die Einzel-Route /{id}), die Methoden GET, POST, EDITABLE (POST, PUT, PATCH) und DELETE.
  • Rechte: Permission — je Objekt (read_post, edit_post, delete_post für den angefragten Beitrag), eine Capability oder öffentlich.
  • Argumente: eine Tabelle mit Name, Typ, Methoden, Pflicht, Standardwert, Enum, Grenzen, Format und Beschreibung. Validierung und Bereinigung übernimmt WordPress anhand dieser Angaben selbst.
  • Real CRUD: Ohne diesen Schalter sind Anlegen, Ändern und Löschen sichere Beispiele, die nichts speichern. Mit ihm erscheint das Feld Post type (Standard post), und POST legt einen Beitrag dieses Typs als Entwurf an (wp_insert_post()) — also auch einen eigenen Post Type wie book —, EDITABLE ändert ihn, DELETE verschiebt ihn in den Papierkorb — mit den passenden Rechteprüfungen und HTTP-Status wie 201 samt Location-Header.
  • Weiteres: ein schema-Callback, Resource name für Funktionsnamen und Meldungen, Function Prefix und Text Domain.

Die Warnungen sind hier besonders nützlich: Sie melden etwa einen Namespace ohne Version, eine öffentliche Route mit Schreibrechten oder dass wp_insert_post() einen Beitrag ganz ohne Titel, Inhalt und Auszug ablehnen würde.

AI Prompt

Erzeugt eine PHP-Funktion, die einen Prompt über den AI Client von WordPress (wp_ai_client_prompt()) an das auf der Website eingerichtete KI-Modell schickt. Ausgabe: ai-prompt.php. Felder: Function name, Text Domain, System instruction, Temperature, Max tokens, Output (Text oder JSON mit eigenem JSON-Schema), eine optionale REST-Route (POST mit einem prompt-Argument, Namespace, Route, Capability, maximale Prompt-Länge) und ein Capability gate, das den Prompt nur für berechtigte Nutzer zulässt. Die Funktion prüft der Reihe nach: leerer Prompt, KI auf der Website abgeschaltet, fehlende Berechtigung (nur mit Capability gate), kein passendes Modell, ungültiges JSON (nur bei JSON-Ausgabe) — und gibt jeweils einen WP_Error zurück. Ein Modell wählt sie nicht aus, das bleibt der Einrichtung der Website überlassen.

Gruppe „Admin UI"

Meta Box

Erzeugt eine Meta-Box mit add_meta_box(), Render-Funktion und Speichern. Felder: Meta Box ID, Title, Screen (post, page, dashboard oder ein eigener Post Type), Context, Priority, Text Domain, einen Schalter für den Hook add_meta_boxes_{post_type}, zwei Kompatibilitäts-Schalter für den Block-Editor und eine Feld-Tabelle (Text, Zahl, E-Mail, URL, Textarea, Checkbox, Datum). Beim Speichern prüft der Code Revision, Autosave, Nonce und edit_post und bereinigt jeden Wert passend zum Typ.

Dashboard Widget

Erzeugt ein Dashboard-Widget mit wp_add_dashboard_widget(). Felder: Widget ID, Widget Name, Callback Function Name, Capability (Standard manage_options), Text Domain, Column, Priority und Widget Content — ein PHP-Schnipsel, das unverändert in die Render-Funktion übernommen wird.

Settings Page

Erzeugt eine Einstellungsseite über die Settings-API als eigener Menüpunkt oder Untermenü. Felder: Page Type, Parent Slug, Function Prefix, Text Domain, Page Title, Menu Title, Capability, Menu Slug, Option Name, Setting description, Expose in REST, Help as toggletip (7.1) sowie Tabellen für Sektionen und Felder (Text, E-Mail, URL, Zahl, Textarea, Checkbox, Passwort). Alle Werte landen als ein Array unter einem Optionsnamen; eine eigene Capability schaltet das Tool über option_page_capability_* frei.

Passwort-Felder sind sorgfältig gelöst: Das Formular gibt den gespeicherten Wert nie aus, ein leeres Feld behält ihn, und die Checkbox Remove saved password löscht ihn gezielt. Neue Passwörter werden verlustfrei gespeichert — nur ungültiges UTF-8 und Steuerzeichen fallen weg, damit Sonderzeichen erhalten bleiben. Mit Expose in REST erscheinen die Einstellungen unter /wp/v2/settings, Passwörter aber nie; sind alle Felder Passwörter, bleibt die Einstellung ganz aus der REST-API.

Admin Bar Nodes

Fügt der Admin-Leiste Einträge mit add_node() hinzu. Felder: Function Prefix, Text Domain, Capability, Priority, Visibility (beide Bereiche, nur Admin, nur Frontend) und eine Knoten-Tabelle mit ID, Titel, Eltern-ID, href, Klasse, Tooltip, ARIA-Titel und Öffnen in neuem Tab. Ein href mit Klammer gilt als PHP-Ausdruck (etwa admin_url( … )) und wird unverändert übernommen.

Contact Methods

Passt die Kontaktfelder im Benutzerprofil über den Filter user_contactmethods an: Felder hinzufügen, deren Schlüssel zum User-Meta-Key werden, und vorhandene entfernen. Seit WordPress 6.9 registriert WordPress selbst keine Kontaktfelder mehr; „entfernen" wirkt also nur noch auf Felder anderer Plugins oder Themes.

Admin Notice

Erzeugt eine Admin-Meldung mit wp_admin_notice(). Felder: Message, Type (success, error, warning, info oder ohne Typ), Hook (Site-, Netzwerk-, Benutzer- oder alle Admin-Bereiche), Text Domain, Function name, Screen ID (leer = überall), Capability, Notice ID, Extra classes, Attributes, Dismissible und Wrap the message in <p>. Die Meldung darf <a href>, <strong>, <em> und <code> enthalten; Links wandelt das Tool in übersetzbare sprintf()-Platzhalter um. Die Funktion wird mit Namen eingehängt, damit anderer Code sie per remove_action() entfernen kann. Das Tool warnt, wenn weder Screen noch Capability gesetzt sind — dann sieht jeder Nutzer mit Admin-Zugang die Meldung.

Gruppe „Config & Queries"

WP-Config

Erzeugt eine vollständige wp-config.php zum Anpassen. Grundfelder sind WP_HOME, WP_SITEURL, WP_ENVIRONMENT_TYPE, WP_DEVELOPMENT_MODE, die Datenbank-Zugangsdaten, das Tabellenpräfix, Speicherlimits, Autosave, Revisionen, Papierkorb, Debug-Einstellungen, FORCE_SSL_ADMIN, DISALLOW_FILE_EDIT und zwei Medien-Schalter. Optionen schützen jede Konstante mit defined(), lesen Zugangsdaten aus Umgebungsvariablen oder erkennen HTTPS hinter einem Reverse Proxy. In aufklappbaren Gruppen folgen Updates und Wartung, Performance und Debugging, WordPress 7.x (KI abschalten mit WP_AI_SUPPORT, API-Schlüssel für Anbieter-Connectoren, Voreinstellungen für Speculative Loading), Sicherheit und HTTP sowie Multisite. Aus diesen Gruppen landen nur Werte in der Datei, die du gesetzt hast.

Die Schaltfläche Generate Salt Keys holt acht frische Sicherheitsschlüssel vom Generator der JPKCom-Tools und setzt sie ein; ohne Klick stehen dort die üblichen Platzhalter. Anders der Knopf Random neben WP_CACHE_KEY_SALT in der Gruppe Performance und Debugging (nur für Object-Cache-Drop-ins, nicht für den Core): Er erzeugt einen zufälligen Wert aus 32 Hex-Zeichen direkt in deinem Browser, ohne Server-Anfrage.

Query Builder

Erzeugt eine Datenbank-Abfrage. Über Query Type wählst du eine von neun Arten, und das Formular passt sich an: WP_Query (posts), get_users(), get_terms(), get_comments(), WP_Network_Query (Multisite), WP_Site_Query (Multisite) sowie WP_Tax_Query, WP_Meta_Query und WP_Date_Query als eigenständige Klassen. Bei WP_Query gibt es Tabellen für meta_query und tax_query, und die Ausgabe enthält die vollständige Schleife mit wp_reset_postdata(). Ein Info-Kasten erklärt den jeweils gewählten Typ.

Code Snippets

Der Eintrag Code Snippets ist kein Formular-Generator, sondern eine Bibliothek aus 40 fertigen Snippets. Du wählst im Auswahlfeld einen Eintrag; darunter erscheinen eine Beschreibung, bei 24 Snippets ein Optionen-Panel und das Feld Text Domain / Prefix, das Funktionsnamen einen eigenen Präfix gibt.

Das Output format entscheidet über die Form:

  • Must-use plugin file (Standard): eine vollständige Datei mit Plugin-Header, declare(strict_types=1) und ABSPATH-Schutz, gedacht für wp-content/mu-plugins/<id>.php. Must-use-Plugins laden automatisch, ohne Aktivierung.
  • Paste into functions.php: nur der Code, ohne öffnendes PHP-Tag und ohne declare(), zum Einfügen hinter das PHP-Tag der functions.php. Die functions.php lädt allerdings erst nach allen Plugins — Code, den Plugins beim Laden lesen, gehört deshalb in ein Must-use-Plugin.

Die Snippets in ihren sechs Gruppen:

  • Security & Cleanup (14) — Generator-Meta-Tag entfernen, Emoji-Support entfernen, Dashicons im Frontend entfernen, XML-RPC abschalten, Versions-Query-Strings entfernen, Argon2ID-Passwörter aktivieren, Kommentare komplett abschalten, Upload-Pfad für Contact Form 7, Login-Fehlermeldungen verallgemeinern, Benutzer-Enumeration verhindern, den REST-Endpunkt users für Gäste verbergen, Datei-Editor abschalten, Security-Header senden, öffentliche REST-API einschränken.
  • Content & Output (5) — Excerpt-Länge, „Weiterlesen"-Text, Block-Stylesheets im Frontend entfernen (für klassische Themes), eigene Bildgröße, Alt-Texte für Bild-Blöcke aus der Mediathek übernehmen (Gutenberg Image Alt Text: Der in der Mediathek gepflegte Alt-Text ersetzt in der Ausgabe den im Block gespeicherten, der Block selbst bleibt unverändert; ist er leer oder besteht nur aus Leerzeichen, bleibt der Block-Wert stehen).
  • Admin & Customisation (3) — Skripte mit defer oder async laden, eigenes Login-Logo, eigener Admin-Footer-Text.
  • Branding (5) — eigener E-Mail-Absender, WordPress-Logo aus der Admin-Leiste entfernen, White-Label-Admin, Dashboard-Widgets entfernen, eigenes Dashboard-Widget.
  • Misc & SEO (3) — Anhangseiten umleiten, Revisionen begrenzen, RSS-Feeds abschalten.
  • WordPress 7.x & Editor (10) — Speculative Loading abschalten oder einstellen, KI-Funktionen abschalten, Abilities aus der REST-API nehmen, clientseitige Medienverarbeitung abschalten, endloses Scrollen in der Mediathek abschalten, Notes abschalten, Font Library abschalten, Block-Editor ohne Inhalte von wordpress.org (Block-Verzeichnis und entfernte Patterns), die Benutzer-Sitemap entfernen, einen Connector registrieren.

Vier Snippets verweigern die Ausgabe, wenn im Optionen-Panel nichts ausgewählt ist — etwa Add Security Headers ohne einen einzigen Header —, und melden das kurz; der zuletzt erzeugte Code bleibt dann stehen. Die Datei heißt beim Download <id>.php bzw. <id>-functions.php.

Reference: Dashicons

Der Dashicons-Browser zeigt die 349 Icons der WordPress-Admin-Schrift mit Suchfeld und Trefferzähler. Du wählst, was ein Klick kopiert: die CSS-Klasse (dashicons-book), den Namen für block.json (book) oder fertiges HTML (<span class="dashicons dashicons-book"></span>). Das ist eine Referenz, kein Code-Generator — praktisch für das menu_icon eines Custom Post Types oder das Icon eines Blocks.

Architektur und Grenzen

  • Clientseitig. Sämtliche Code-Templates und die Generierungs-Logik laufen in deinem Browser; deine Eingaben werden nicht übertragen. Abgesehen vom Nachladen der Editor-Dateien ist die einzige Server-Anfrage der Abruf der Salt Keys im WP-Config-Generator, und der enthält keine Formulardaten. Gespeichert werden nur die gemeinsamen Felder, lokal im Browser.
  • Gerüst, kein fertiges Plugin. Der Code ist syntaktisch korrekt — außer an den Stellen, an denen du selbst PHP einträgst (Widget-Inhalt, href mit Klammer, Asset-Quelle als PHP-Ausdruck), denn die übernimmt das Tool ungeprüft —, folgt den Konventionen und ist oft schon lauffähig, enthält aber bewusst Platzhalter und leere Funktionsrümpfe. Die fachliche Logik schreibst du selbst.
  • Keine Prüfung gegen deine Installation. Das Tool weiß nicht, ob ein Hook existiert, ein Slug schon belegt ist oder eine Capability deinen Rollen zugewiesen ist. Manche Grenzen — etwa die Länge von Post-Type- und Taxonomie-Slugs — nennt es nur im Infotext.
  • Kein KI-Anteil im Tool selbst. Der Generator arbeitet mit festen Templates. Code für die KI-Schnittstellen von WordPress — Abilities, AI Client, Connectoren — erzeugt er, eine KI-Komponente hat er nicht.
  • Zielplattform WordPress 7.0/7.1 und PHP 8.3. Für ältere Versionen passt du den Code und die Versionsangaben selbst an; Funktionen aus 7.1 prüft der erzeugte Code teils vorab, damit er unter 7.0 nicht abbricht.

Für den Einstieg und die Zielgruppen siehe die Übersichtsseite. Konkrete Abläufe zeigen die Beispiele, Strategie und Stolperfallen die Tipps & Tricks. Ausprobieren kannst du alles direkt im Tool.