WP Code Generator — Manual

Back to the overview: WP Code Generator · Open the tool live: www.jpkc.com/tools/wp/

This manual describes the WP Code Generator in full: how the interface is laid out, how generation, output, and storage work, what each of the 33 generators does and which fields it offers, what the snippet library contains, and where the limits are. The tool's interface is in English, so the generator and field names appear in their original spelling throughout.

Layout and operation

The tool has two parts: a sidebar on the left with all generators in nine groups, and on the right the workspace of the selected generator — the form at the top, the output below. On load, the Plugin generator is active.

Live generation

As soon as you change a field, the tool rebuilds the code after 300 milliseconds, so typing doesn't stutter. The Generate button at the top right of the form produces the code immediately and scrolls to the output. Apart from Plugin and the Code Snippets, which are generated on load, each generator only runs once you open it in the sidebar, and again every time you reopen it — that way it also picks up values you entered in another generator in the meantime. The Code Snippets react without any delay.

Output editor

The output sits in a read-only ACE editor with syntax highlighting. For PHP, JavaScript, JSON, CSS, HTML, and SVG the editor checks the syntax in the background and flags errors in the gutter (except for a block theme's HTML templates and for the Abilities API's js/abilities.js when Load server abilities in the client is on). You can't edit the code there — you copy or download it instead.

Several files in tabs

Eight generators can produce several files and show them in tabs above the editor, labeled with the file path: Plugin, Theme, Gutenberg Block, Abilities API, SVG Icons, Block Bindings, Block Patterns, and Block Styles. Which files appear depends on the options; when a file drops out, its tab disappears too, so nothing stale ends up in a copy, download, or archive.

Copy, Download, and ZIP

Copy puts the editor content — with several files, that of the active tab — on the clipboard.
Download saves the same content as a file. Single-file generators use descriptive names (hooks.php, cpt.php, settings-page.php, rest-route.php …; for WP-CLI Command, Block Variations, and the snippets they depend on the input), multi-file generators the name of the file in the active tab.
ZIP is available for Plugin, Theme, Gutenberg Block, and Block Bindings. One click regenerates the code and packs all files into a folder named after the plugin or theme slug or the block name — for example book-shelf.zip containing book-shelf/book-shelf.php, book-shelf/readme.txt, and book-shelf/uninstall.php. As a plugin with a header (for Gutenberg Block: Registration "Plugin", no build step) and as a theme, the archive installs directly through the plugin or theme upload in the WordPress admin; in @wordpress/scripts mode you build first. As long as fields marked in red block the output — an invalid slug, for Block Bindings any hard error —, no archive is created; a notice asks you to fix the fields marked in red first.

If there is no code yet to copy or download, the tool reports "Generate code first by switching to this tab."

Shared fields and browser storage

Some details you need in almost every generator. The tool treats them as shared fields:

Author (Plugin, Theme, Block Bindings) and Author URI (Plugin, Theme),
the text domain of the plugin-style generators,
the theme text domain — kept separately — for Theme, Nav Menus, Sidebar / Widget Area, Block Patterns, and the Text Domain / Prefix field of the Code Snippets,
the function prefix of the generators that have one (except in Nav Menus, Sidebar / Widget Area, and Block Patterns, whose prefix belongs to a theme, and except the Table Prefix of wp-config.php).

When you type into one of these fields, the tool copies the value immediately into the matching fields of the other generators — but only into fields you haven't changed there yourself. If you clear the source field, the untouched targets fall back to their default. Nothing is copied into the text domain of Plugin and Block Bindings: in Plugin it follows the slug, in Block Bindings an empty field means the slug, since it should match the folder name. What you type there is still passed on to the other generators like any other field.

Your browser also remembers these values in localStorage (key jpktools_wp_common, at most 200 characters per value) and fills them into the fields that still hold their initial value (mostly empty, my-plugin for four text domains) on your next visit. The Forget saved defaults button at the bottom of the sidebar deletes the stored state; the fields keep their current values until you reload. Without browser storage — say, in a private window with storage blocked — the tool still works, it just doesn't remember anything.

Derived fields

Many fields follow another field until you change them yourself: the plugin slug follows the plugin name, the plugin text domain the slug, the stable tag the version; for the theme, the slug follows the name and the tags follow the selected options; in Block Bindings the source and the custom block follow the slug; in Admin Notice the screen ID, notice ID, and function name follow the text domain. Once you overwrite such a field, your value stays. Two exceptions: in Plugin, every change to the name resets the PHP namespace; in WP-CLI Command, every change to the command name resets the class name.

Checks, warnings, and error files

Red fields: where the tool checks an input — slugs, namespaces, callback names that are PHP keywords, regex patterns, JSON — it marks invalid values in red, usually with a hint below.
Error files: Plugin (for an invalid slug), Abilities API, SVG Icons, Block Bindings, Block Patterns, Block Styles, Block Variations, REST Route, Admin Notice, and AI Prompt produce no code on hard errors, but a PHP file that, apart from its file header, contains only comments and registers nothing: "Nothing is registered: fix the fields marked in red first." followed by the list of errors. It deliberately doesn't repeat your faulty input.
Substitute values: the other generators substitute a default for empty or unusable fields — some with a warning (e.g. Gutenberg Block), some quietly — or skip a table row.
Warnings: domain-specific notes that don't block the code appear as a yellow list above the output — a tag that wordpress.org ignores, a text domain that doesn't match the slug, or a REST create endpoint with no title, content, or excerpt argument.

Target version and code style

The generated code targets WordPress 7.0 as the minimum, is designed against 7.1, and requires PHP 8.3. These values are the defaults in the version fields of Plugin and Theme (Requires WP 7.0, Tested up to 7.1, Requires PHP 8.3; the header line is Requires at least); JSON schemas point to wp/7.1 by default. PHP files consistently start with declare(strict_types=1); and the defined( 'ABSPATH' ) || exit; guard. The exceptions have reasons: uninstall.php checks WP_UNINSTALL_PLUGIN instead, WP-CLI files check WP_CLI, wp-config.php has its own structure, and the wp_nav_menu() snippet is a template call without a file header. Further exceptions: a block's render.php has only the ABSPATH guard, the *.asset.php files just return an array, and snippets in "Paste into functions.php" format have no file header at all. Translatable strings go through __() and friends with a literal text domain, so wp i18n make-pot finds them.

Group "Plugin & Theme"

Plugin

Produces a complete plugin from up to three files: the main file <slug>.php, a readme.txt for wordpress.org, and optionally an uninstall.php. ZIP is available.

Header fields: Plugin Name, Plugin slug (folder and file name, follows the name), Text Domain (follows the slug), PHP namespace (default: the name in PascalCase — reset on every name change), Main class (default 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 then blocks activation while a required plugin is missing or inactive), Network (network activation on multisite only), Description (one line, at most 140 characters).
The code: the header in the documented order, always with Domain Path: /languages — a load_plugin_textdomain() is no longer needed. Then the namespace and a final class singleton with a VERSION constant (typed from PHP 8.3), init() on the init hook, and activation and deactivation methods; activation stores the version as the option <slug>_version (hyphens become underscores, e.g. book_shelf_version).
readme.txt: the fields Contributors, Tags (at most five), Donate link, Tested up to (7.1), Stable tag (follows the version), Long description (Markdown), and Upgrade notice (at most 300 characters) don't belong in the plugin header and therefore end up only here. The tool applies the rules of the wordpress.org parser: plugin and wordpress as tags are removed, everything from the sixth tag on is cut, and the short description is trimmed to 150 characters — each with a warning. The readme.txt writes the GPL licenses in short form ("GPLv2 or later" or "GPLv3 or later"); for Proprietary the tool warns that wordpress.org only hosts GPL-compatible plugins.
uninstall.php (default: on) deletes the version option, on multisite for every site.

Theme

Produces a block theme or a classic theme, each also as a child theme. ZIP is available.

Basic fields: Theme Name, Theme slug (folder name), Text Domain (empty = slug), Version, Author, Author URI, Theme URI, Parent Theme (filled = child theme), Requires WP, Tested up to, Requires PHP, Description, Footer Text, and Tags (suggests matching tags from the options).
Block Theme (Full Site Editing) switches to a block theme and opens the options in accordions: theme.json schema (wp/6.9 to trunk, default wp/7.1; version stays 3), a four-color palette and gradient, optionally a duotone filter primary-base (color.duotone), content and wide width, fonts (system fonts or your own font file), fluid typography, a paragraph indent (Paragraph text indent, 7.0), spacing, dimension presets narrow/half (7.0), shadows, radii, states such as :focus-visible for buttons, a text shadow for headings (7.1), responsive styles for @mobile/@tablet and custom breakpoints (7.1), the templates index, home, single, page, archive, search, 404, and optionally blank, template parts for header, footer, and navigation overlay (7.0) — for header.html and footer.html you pick the area (Area of header.html/Area of footer.html: uncategorized, header, footer, or navigation-overlay) —, style variations as a table (the first one is the inverted palette, i.e. "Dark" for a light theme), a section style, a pattern, and an editor stylesheet.
Classic produces style.css, functions.php with the usual add_theme_support() calls, two menu locations and a sidebar, plus index.php, header.php, footer.php, comments.php, and optionally assets/js/main.js (deferred, in the footer).
Child themes stay lean: style.css with a Template: header, functions.php, and for a block theme an almost empty theme.json — presets of its own would replace the parent theme's lists. Templates, template parts, the style variation, and the section style are left out; depending on the options, a block child theme also gets the pattern and the editor stylesheet, a classic child theme assets/js/main.js. Classic child themes have the switch Parent loads its stylesheet with get_stylesheet_uri() (e.g. Twenty Fifteen to Seventeen, Twenty Twenty): when it's on, the child registers the parent's style.css under the parent's handle <parent>-style and loads it before its own; when it's off, the child enqueues only its own style.css, at priority 20 — right for parents that load their stylesheet themselves via get_template_directory_uri() or get_parent_theme_file_uri().

Code identity such as the function prefix and handles follows the slug; the text domain only the translation calls. The tool warns when selected options are newer than the schema or the minimum version you entered. It doesn't ship the font file itself — you put it at assets/fonts/<family>/<file>.woff2 (the tool shows the exact path).

Nav Menus

Registers menu locations with register_nav_menus() on after_setup_theme. Fields: Function Prefix, Text Domain, and a table with Location ID and Label. Note: the two prefilled rows contain placeholder text only — if you enter nothing, only the primary location is created.

`wp_nav_menu()`

Produces the call that outputs a menu, as a snippet for a template. Fields: theme_location, container (nav, div, or false), depth, container_class, container_id, container_aria_label, menu_class, menu_id, fallback_cb (default, false, or your own function), item_spacing, and the options echo and Generate custom Walker class with a Walker_Nav_Menu subclass. Default values for depth, fallback_cb, echo, and item_spacing and empty fields are left out; theme_location and container are always written.

Registers widget areas with register_sidebar() on widgets_init. Fields: Function Prefix, Text Domain, Widget Wrapper Tag (section, div, aside, li, or custom HTML), Title Tag, and a table with ID, name, and description per area. As with Nav Menus, the prefilled row contains placeholders only; without an entry, primary-sidebar is created.

Group "Blocks & Editor"

Gutenberg Block

Produces a block with block.json (apiVersion 3) in three modes — ZIP is available, the folder is named after the block:

No build step (default): main file, block.json, index.js using the window.wp globals, index.asset.php, and depending on the options render.php, style.css and editor.css, view.js and view.asset.php.
@wordpress/scripts: main file, package.json with a build script, and the sources under src/<block>/ in JSX; registration goes through wp_register_block_types_from_metadata_collection() and blocks-manifest.php.
PHP only: a single PHP file with register_block_type() and autoRegister (WordPress 7.0) — the editor then builds the controls itself for text, number, and boolean values.

Fields: Namespace and Block Name, Title, Text Domain, Category (including a custom category), Icon (Dashicon), Keywords, Description, Registration (plugin with header, or register.php to include), block.json schema, Dynamic block (render.php, default: on), Stylesheets, Interactivity API (view.js) with global state, an attribute table (type, default, enum, source, selector, role), Block Bindings attributes, and an accordion of Supports, of which only values that differ from the WordPress default are written. Under Advanced fields follow version, example, parent, ancestor, allowedBlocks, usesContext, providesContext, block styles, and blockHooks. Invalid names fall back to my-plugin/my-block with a warning instead of blocking the output.

SVG Icons

Uses the Icons API from WordPress 7.1: registers your own icon collection with wp_register_icon_collection() and icons with wp_register_icon(), and optionally removes core icons. Fields: Collection Slug (core is taken), Function Prefix, Text Domain, Collection Label, Collection Description, an icon table with name, label, source (SVG inline in the code or as a file icons/<name>.svg) and markup, Unregister core icons, and a usage example with wp_get_icon(). The registration first checks that the function exists, so the plugin still loads on 7.0.

The SVG check is useful: the tool compares your markup with what the WordPress sanitizer lets through — only <svg>, <path>, and <polygon> with a few attributes are allowed — and flags circles, rectangles, stroke attributes, fixed colors instead of currentColor, or a missing viewBox before WordPress silently strips them.

Block Bindings

Produces a complete plugin that registers your own Block Bindings source: blocks in the editor then show values from post meta fields and can optionally edit them too. ZIP is available. Files: <slug>.php, assets/editor.js, plus block-markup.html and pattern-overrides.html as example markup to paste.

Fields: Plugin Name, Plugin Slug, PHP Namespace, Text Domain, Author, Version, Source Name (namespace/name, core/… is forbidden), Source Label, context (postId and postType always, optionally termId, taxonomy, and custom keys), Post Types, Editable in the editor, and a field table with field name, label, type, meta key, and sanitizer. Optionally you can opt a custom block into bindings and Pattern Overrides (Custom Block, Bindable Attributes).

The PHP part registers the meta fields with a permission check, the source with register_block_bindings_source(), and only reads values when the post is publicly viewable or readable for you and not password-protected — the same checks as the core source core/post-meta. The JavaScript registers the source in the editor with registerBlockBindingsSource() and lists the fields for selection.

Block Patterns

Produces a block pattern — in Theme mode as a file patterns/<name>.php with a header that WordPress picks up automatically (plus inc/block-pattern-categories.php for a custom category), in Plugin mode with register_block_pattern() and a separate markup file. Fields: Mode, Namespace, Pattern Name, Title, Description, Text Domain, Function Prefix, Content (presets Hero, Call to action, Three columns, or custom block markup), the preset texts, core categories, a custom category, Keywords, Block Types, Post Types, Template Types, Viewport Width, and Inserter. Preset texts end up translatable as esc_html_e() in the file. Custom markup is checked for unclosed or crossed blocks, invalid JSON, and content outside of blocks.

Block Styles

Registers a block style (class is-style-<name>) for one or more blocks with register_block_style(). The styling comes from one of three sources: style_data (values as in theme.json — background, text, padding, border), inline_style (CSS text), or style_handle (a separate stylesheet that the tool generates too and loads when the blocks render). Add to that Label, Text Domain, Default style, and Remove Styles to remove existing styles in PHP and in the editor.

Block Variations

Produces block variations — in Filter mode through get_block_type_variations for any block registered in PHP (default core/group), in variations.php mode as a file for a block of your own. Per row: name, title, description, icon, attributes (JSON), inner blocks (JSON), isActive, keywords, scope, and default. The tool warns when isActive points to an attribute the variation doesn't set — the editor then can't recognize it again.

Group "Hooks & Assets"

Hook (Action / Filter)

Produces a callback function plus add_action() or add_filter(). Fields: Type, Hook Name (with a suggestion list of common core hooks and two WooCommerce hooks), Priority, Accepted Args, Callback Function Name, and Typed parameters (known hooks). When you pick a known hook such as save_post, pre_get_posts, or the_title, the tool sets the type and number of arguments itself and writes the real parameter types into the signature; unknown parameters become mixed and optional — except a filter's first parameter, the value $value. Priority and argument count are left out when they match the default.

Cron Event

Produces a scheduled event with wp_schedule_event(), protected against double scheduling, including the callback and cleanup with wp_clear_scheduled_hook() on deactivation — through register_deactivation_hook(), which only fires from the main plugin file; in themes and mu-plugins you clean up yourself. Fields: Event Hook Name, Callback Function Name, Schedule (Hourly, Twice Daily, Daily, Weekly, or a custom interval in minutes or hours, registered through cron_schedules), Schedule via (plugin activation, or init for themes and mu-plugins), and Text Domain.

Asset Enqueue

Produces clean registration and loading of CSS, classic JavaScript, or a script module. Fields: Type, Handle / Module ID, Enqueue Hook (front end, admin, login, enqueue_block_assets, enqueue_block_editor_assets), Relative paths from (plugin or theme), Source, Dependencies, Version Strategy (fixed string, filemtime(), the build/*.asset.php from @wordpress/scripts, false, or null), Media, Loading strategy (defer/async), fetchpriority, In Footer, JS translations, and Text Domain. Two practical restrictions: to a specific admin page (hook suffix), or to the editor canvas only with enqueue_block_assets.

Shortcode

Produces a shortcode with add_shortcode() on init and a render function using shortcode_atts() and output buffering. Fields: Shortcode Tag (no spaces and no & / < > [ ] =), Callback Function Name, Has inner content, and an attribute table with defaults.

oEmbed Provider

Registers your own oEmbed providers with wp_oembed_add_provider(). Fields: Function Prefix, Register on Hook, and a table with URL pattern, endpoint, and a regex switch. Without a filled row, the tool inserts an example provider.

WP-CLI Command

Produces a class that extends WP_CLI_Command and registers it with WP_CLI::add_command(). Fields: Command name, Class name, Namespace, Description, and WP-CLI guard (the file exits immediately when it isn't loaded through WP-CLI). Under Subcommands you create subcommands with alias, @when, description, example, and arguments — positional arguments, --key=<value> with default and options, and flags. The tool turns them into the PHPDoc syntax that WP-CLI reads for its help. The file name follows the command, for example my-plugin-cli.php.

Group "Data Types"

Custom Post Type

Produces register_post_type() on init with the complete label set. Fields: Post Type Slug, Singular Label, Plural Label, Text Domain, Dashicon, Menu Position, Description, the switches public, show_in_rest, has_archive, hierarchical, show_in_nav_menus, show_in_admin_bar, exclude_from_search, and can_export, the Supports (including editor notes), capability_type, Taxonomies, rewrite slug and with_front, rest_base, rest_namespace, delete_with_user, embeddable, and a block template as JSON with template_lock. Comments in the code point out when the block editor is missing without show_in_rest, or when meta fields don't show up in REST and Block Bindings without custom-fields. The tool doesn't check the slug — WordPress allows at most 20 characters.

Taxonomy

Produces register_taxonomy() with the label set that fits hierarchical or tag-like taxonomies. Fields: Taxonomy Slug (at most 32 characters, unchecked), labels, Object Types, Text Domain, rewrite options, the visibility switches, sort, Meta box (default or none), rest_base, rest_namespace, and a default term whose name deliberately stays untranslated, so no separate term is created per language.

Post Status

Registers a custom post status with register_post_status(). Fields: Status Slug, labels for singular and count, Text Domain, Visibility (protected, public, private, or internal), the switches for search and lists, and Show as post state in list tables. The comment in the code records what often surprises: the block editor still offers only its five built-in statuses.

Post Meta Field

Registers a meta field with register_post_meta(). Fields: Post Type (empty = all), Meta Key, Function Prefix, Type, Default Value, Text Domain, Description, Label, the REST schema for arrays and objects, single, show_in_rest, revisions_enabled, Block Bindings, plus Auth Callback and Sanitize Callback. The sanitizer is suggested per type; for numbers the tool generates a helper of its own, because floatval() used as a callback throws an error when it receives several arguments. With Block Bindings it enforces show_in_rest and single, and warns about protected keys starting with an underscore, which can't be bound.

Term Meta Field

Like Post Meta Field (without Block Bindings and revisions_enabled), but with register_term_meta() for a taxonomy. On top there's Generate form field integration: the tool then generates the form fields for the "Add New" and "Edit" term screens, including nonce, permission check, and saving.

Group "APIs"

Abilities API

Registers an ability — a capability of your site that AI assistants, MCP clients, REST automations, and the WordPress AI client can call. Output: abilities.php, optionally js/abilities.js.

Name and category: Namespace, Ability Slug (together namespace/slug), Function Prefix, Text Domain, Category (your own category or the core categories site and user).
Description: Label and Description — the description is written for agents and should say what the ability returns and when it's useful.
Schemas: Input (no parameters, a single value, or an object with a property table) and Output (nothing, a value, an object, or a list). The input table knows type, required, default, enum, minimum and maximum, lengths, pattern, and format; the output table knows type, items type, format, description, and required. For object input, the schema rejects unknown properties by default (Reject unknown properties, 'additionalProperties' => false, can be turned off).
Permissions and behavior: Permission (capability, logged-in users, or public), the annotations readonly, destructive, and idempotent — they determine the HTTP method (GET, POST, or DELETE) —, public (7.1), show_in_rest, and the MCP settings public, type, and uri.
Extras: callbacks as named functions or closures, a usage example in PHP and curl, stubs for nine lifecycle hooks (seven of them new in 7.1), an example using the AI client, and a client-side ability (js/abilities.js) that can also load the server abilities into the client (Load server abilities in the client, @wordpress/core-abilities).

With the defaults you get a working ability get-recent-posts that returns the latest posts. The tool checks patterns for your inputs twice — as a JavaScript regex and for compatibility with PHP —, because both sides evaluate the schema.

REST Route

Registers a custom REST route with register_rest_route(). Output: rest-route.php.

Route: Namespace (such as my-plugin/v1), Route, ID segment (creates the single-item route /{id}), the methods GET, POST, EDITABLE (POST, PUT, PATCH), and DELETE.
Permissions: Permission — per object (read_post, edit_post, delete_post for the requested post), a capability, or public.
Arguments: a table with name, type, methods, required, default, enum, bounds, format, and description. WordPress itself handles validation and sanitizing based on these.
Real CRUD: without this switch, create, update, and delete are safe examples that store nothing. With it, the field Post type appears (default post), and POST creates a post of that type as a draft (wp_insert_post()) — so a custom post type such as book works too —, EDITABLE updates it, DELETE moves it to the trash — with the matching permission checks and HTTP statuses such as 201 with a Location header.
More: a schema callback, Resource name for function names and messages, Function Prefix, and Text Domain.

The warnings are particularly useful here: they flag a namespace without a version, a public route with write access, or that wp_insert_post() would reject a post with no title, content, and excerpt at all.

AI Prompt

Produces a PHP function that sends a prompt through the WordPress AI client (wp_ai_client_prompt()) to the AI model configured on the site. Output: ai-prompt.php. Fields: Function name, Text Domain, System instruction, Temperature, Max tokens, Output (text, or JSON with your own JSON schema), an optional REST route (POST with a prompt argument, namespace, route, capability, maximum prompt length), and a Capability gate that only lets authorized users through. The function checks in order: empty prompt, AI switched off on the site, missing permission (only with the Capability gate), no suitable model, invalid JSON (only for JSON output) — and returns a WP_Error for each. It doesn't pick a model; that's left to the site's configuration.

Group "Admin UI"

Meta Box

Produces a meta box with add_meta_box(), a render function, and saving. Fields: Meta Box ID, Title, Screen (post, page, dashboard, or a custom post type), Context, Priority, Text Domain, a switch for the add_meta_boxes_{post_type} hook, two compatibility switches for the block editor, and a field table (text, number, email, URL, textarea, checkbox, date). On save, the code checks for revision, autosave, nonce, and edit_post, and sanitizes each value according to its type.

Produces a dashboard widget with wp_add_dashboard_widget(). Fields: Widget ID, Widget Name, Callback Function Name, Capability (default manage_options), Text Domain, Column, Priority, and Widget Content — a PHP snippet that is inserted into the render function unchanged.

Settings Page

Produces a settings page through the Settings API, as a top-level menu item or a submenu. Fields: 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), plus tables for sections and fields (text, email, URL, number, textarea, checkbox, password). All values are stored as one array under a single option name; a custom capability is unlocked through option_page_capability_*.

Password fields are handled carefully: the form never prints the stored value, an empty field keeps it, and the Remove saved password checkbox deletes it on purpose. New passwords are stored losslessly — only invalid UTF-8 and control characters are dropped, so special characters survive. With Expose in REST, the settings appear under /wp/v2/settings, but passwords never do; if every field is a password, the setting stays out of the REST API entirely.

Admin Bar Nodes

Adds entries to the admin bar with add_node(). Fields: Function Prefix, Text Domain, Capability, Priority, Visibility (both, admin only, front end only), and a node table with ID, title, parent ID, href, class, tooltip, ARIA title, and open in a new tab. An href containing a parenthesis is treated as a PHP expression (such as admin_url( … )) and inserted as is.

Contact Methods

Adjusts the contact fields in the user profile through the user_contactmethods filter: add fields whose keys become user meta keys, and remove existing ones. Since WordPress 6.9, WordPress itself no longer registers any contact fields; "remove" therefore only affects fields added by other plugins or themes.

Admin Notice

Produces an admin notice with wp_admin_notice(). Fields: Message, Type (success, error, warning, info, or none), Hook (site, network, user, or all admin screens), Text Domain, Function name, Screen ID (empty = everywhere), Capability, Notice ID, Extra classes, Attributes, Dismissible, and Wrap the message in . The message may contain <a href>, , , and <code>; the tool turns links into translatable sprintf() placeholders. The function is hooked by name, so other code can remove it with remove_action(). The tool warns when neither screen nor capability is set — then every user with admin access sees the notice.

Group "Config & Queries"

WP-Config

Produces a complete wp-config.php to adapt. The basic fields are WP_HOME, WP_SITEURL, WP_ENVIRONMENT_TYPE, WP_DEVELOPMENT_MODE, the database credentials, the table prefix, memory limits, autosave, revisions, trash, debug settings, FORCE_SSL_ADMIN, DISALLOW_FILE_EDIT, and two media switches. Options guard every constant with defined(), read credentials from environment variables, or detect HTTPS behind a reverse proxy. Collapsible groups follow for updates and maintenance, performance and debugging, WordPress 7.x (turn AI off with WP_AI_SUPPORT, API keys for provider connectors, defaults for speculative loading), security and HTTP, and multisite. From these groups, only values you set end up in the file.

The Generate Salt Keys button fetches eight fresh security keys from the JPKCom tools' generator and inserts them; without a click, the usual placeholders stay. The Random button next to WP_CACHE_KEY_SALT in the Performance & Debugging group works differently (the constant is only for object-cache drop-ins, not core): it creates a random value of 32 hex characters right in your browser, with no server request.

Query Builder

Produces a database query. Under Query Type you choose one of nine kinds, and the form adapts: WP_Query (posts), get_users(), get_terms(), get_comments(), WP_Network_Query (Multisite), WP_Site_Query (Multisite), and WP_Tax_Query, WP_Meta_Query, and WP_Date_Query as standalone classes. For WP_Query there are tables for meta_query and tax_query, and the output contains the complete loop with wp_reset_postdata(). An info box explains the selected type.

Code Snippets

The Code Snippets entry isn't a form generator but a library of 40 ready-made snippets. You pick an entry in the select field; below it appear a description, an options panel for 24 snippets, and the Text Domain / Prefix field that gives function names a prefix of your own.

The Output format decides the shape:

Must-use plugin file (default): a complete file with plugin header, declare(strict_types=1), and ABSPATH guard, meant for wp-content/mu-plugins/<id>.php. Must-use plugins load automatically, without activation.
Paste into functions.php: the code only, without an opening PHP tag and without declare(), for pasting after the PHP tag of functions.php. functions.php only loads after all plugins, though — code that plugins read while loading belongs in a must-use plugin.

The snippets in their six groups:

Security & Cleanup (14) — remove the generator meta tag, remove emoji support, remove Dashicons on the front end, disable XML-RPC, remove version query strings, enable Argon2ID passwords, disable comments entirely, an upload path for Contact Form 7, generic login error messages, prevent user enumeration, hide the users REST endpoint from guests, disable the file editor, send security headers, restrict the public REST API.
Content & Output (5) — excerpt length, "read more" text, remove block stylesheets on the front end (for classic themes), a custom image size, alt text for Image blocks from the media library (Gutenberg Image Alt Text: the alt text stored in the media library replaces the one saved in the block in the output, the block itself stays unchanged; if it's empty or only whitespace, the block's value stays).
Admin & Customisation (3) — load scripts with defer or async, a custom login logo, custom admin footer text.
Branding (5) — a custom email sender, remove the WordPress logo from the admin bar, white-label admin, remove dashboard widgets, a custom dashboard widget.
Misc & SEO (3) — redirect attachment pages, limit revisions, disable RSS feeds.
WordPress 7.x & Editor (10) — disable or configure speculative loading, disable AI features, hide abilities from the REST API, disable client-side media processing, disable infinite scrolling in the media library, disable Notes, disable the Font Library, the block editor without content from wordpress.org (block directory and remote patterns), remove the users sitemap, register a connector.

Four snippets refuse to produce output when nothing is selected in their options panel — Add Security Headers without a single header, for example — and say so briefly; the last generated code then stays in place. The download is named <id>.php or <id>-functions.php.

Reference: Dashicons

The Dashicons browser shows the 349 icons of the WordPress admin font, with a search field and hit counter. You choose what a click copies: the CSS class (dashicons-book), the name for block.json (book), or ready-made HTML (). This is a reference, not a code generator — handy for a custom post type's menu_icon or a block's icon.

Architecture and limits

Client-side. All code templates and the generation logic run in your browser; your input is not transmitted. Apart from loading the editor's own files, the only server request is fetching the salt keys in the WP-Config generator, and it contains no form data. Only the shared fields are stored, locally in the browser.
Scaffold, not a finished plugin. The code is syntactically correct — except where you enter PHP yourself (widget content, an href with a parenthesis, an asset source as a PHP expression), which the tool inserts unchecked —, follows conventions, and often already works, but deliberately contains placeholders and empty function bodies. You write the domain logic yourself.
No check against your installation. The tool doesn't know whether a hook exists, a slug is taken, or a capability is assigned to your roles. Some limits — such as the length of post type and taxonomy slugs — it mentions only in the info text.
No AI inside the tool itself. The generator works with fixed templates. It generates code for the AI interfaces of WordPress — abilities, AI client, connectors — but has no AI component of its own.
Target platform WordPress 7.0/7.1 and PHP 8.3. For older versions you adapt the code and the version details yourself; the generated code checks for some 7.1 functions first, so it doesn't break on 7.0.

For the introduction and target audiences see the overview. Concrete workflows are in the examples, strategy and gotchas in the tips & tricks. You can try everything directly in the tool.