Plugin Header Generator

Generate the plugin file header WordPress reads, with the version requirements, text domain, update URI and the ABSPATH guard.

Live output

Enable JavaScript to customise; default output below.

Shown on the Plugins screen. This is the only header WordPress truly requires.

One line on the Plugins screen. Line breaks are stripped, so keep it to a sentence.

WordPress compares this against the directory to decide whether an update exists.

The plugin's own page. Leave empty and the line is omitted.

More options Show
Live preview my-plugin.php
<?php
/**
 * Plugin Name:       My Plugin
 * Description:       Does one useful thing, with no settings to learn.
 * Version:           1.0.0
 * Requires at least: 6.5
 * Requires PHP:      7.4
 * Author:            Your Name
 * License:           GPLv2 or later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       my-plugin
 *
 * @package my-plugin
 */

// Stops the file doing anything when it is requested directly over the web.
defined( 'ABSPATH' ) || exit;

define( 'MY_PLUGIN_VERSION', '1.0.0' );
define( 'MY_PLUGIN_FILE', __FILE__ );
define( 'MY_PLUGIN_DIR', plugin_dir_path( __FILE__ ) );
define( 'MY_PLUGIN_URL', plugin_dir_url( __FILE__ ) );

Output is valid and updates as you type.

Fill in the headers WordPress reads from your main plugin file and copy the result to the top of it. The generator adds the ABSPATH guard and the version constants most plugins end up writing anyway.

How to use

  1. Name the plugin. That single header is all WordPress needs to recognise the file, but the rest decide how it behaves.
  2. Set Requires WordPress and Requires PHP honestly. WordPress blocks activation below them, which is better than a fatal error on someone’s live site.
  3. Match the text domain to the plugin folder name. WordPress.org builds translation packages from the folder, so a mismatch means no translations.
  4. Leave the constants on unless you already define your own. They give you a version string and both paths without repeating plugin_dir_path() everywhere.
  5. Paste the block at the very top of your main plugin file, before any other code.

Example

A plugin requiring WordPress 6.5, PHP 8.0 and two other plugins, shipping its own translations:

<?php
/**
 * Plugin Name:       Acme Cache Purge
 * Description:       Adds one purge button to the admin bar.
 * Version:           2.1.0
 * Requires at least: 6.5
 * Requires PHP:      8.0
 * Requires Plugins:  woocommerce, wordpress-seo
 * Text Domain:       acme-cache-purge
 * Domain Path:       /languages
 */

defined( 'ABSPATH' ) || exit;

Requires Plugins arrived in WordPress 6.5 and takes WordPress.org slugs only. On older versions the line is ignored rather than fatal.

Pitfalls

  • The header must be in the main plugin file, in the first block comment. WordPress reads only the first 8 KB of the file, so a header below a long banner comment is never seen.
  • Text Domain has to match the plugin folder name for WordPress.org translations. my-plugin in a folder called my-plugin-pro loads nothing.
  • Version is what update checks compare. Leaving it at 1.0.0 across releases means no user is ever offered the update.
  • Requires Plugins accepts slugs, not names, and only for plugins hosted on WordPress.org. A private dependency cannot be declared this way.
  • Without defined( 'ABSPATH' ) || exit; the file runs when requested directly, which turns any fatal into a public stack trace.
  • Update URI set to false stops WordPress.org offering an update for a plugin whose slug collides with a hosted one. Without it, your plugin can be replaced by a stranger’s.
  • Domain Path only matters when you ship .mo files yourself. Setting it without those files makes translation loading fail quietly.
  • Network: true means the plugin can only be activated network wide on multisite, which is a support decision as much as a technical one.

Compatibility

Every header here except Requires Plugins and Update URI has been read by WordPress since 3.x. Update URI needs WordPress 5.8, Requires Plugins needs 6.5, and both are ignored on older versions rather than causing an error. The generated file targets PHP 7.0 and up.

Frequently asked questions

Which headers are actually required?
Only Plugin Name. Everything else changes how the plugin is listed, updated or activated, but the file is recognised without them.
Why does my plugin not appear on the Plugins screen?
Usually the header is not in the first block comment of the main file, or the file sits one folder too deep. WordPress scans the plugin directory root and one level down.
Does the text domain have to match the folder?
For translations from WordPress.org, yes. For your own bundled .mo files, it must match what you pass to load_plugin_textdomain().
What does Update URI do?
It tells WordPress where updates come from. Setting it to false blocks WordPress.org from offering an update to a plugin that happens to share your slug.
Should I define constants?
They save repeating path helpers, and a version constant gives you one place to bump. Prefix them, since constants are global and cannot be redefined.

From the people who built this tool

WP Adminify

The WordPress admin, rebuilt: a dashboard worth looking at, menu and column control, a real file manager and the login page your client sees.

See WP Adminify Free version on WordPress.org

Weekly drops

New tools, when there are new tools

One email when something worth using ships. No schedule to fill, so no filler.

Your address goes nowhere else, and one click unsubscribes.