Gutenberg Sidebar – Setting up the Plugin Header

Setting up a plugin header for a Gutenberg sidebar.

In this post in the series, I’ll quickly cover how to set up a plugin header so WordPress knows that there is a plugin to activate/deactivate.

What is a Plugin Header?

The plugin header is basically meta information that WordPress can read in and determine if a plugin is ready to activate or not.

You can set the following information:

  • Plugin Header (the only field that is required): the name of the plugin.
  • Plugin URI: the location where someone can view more information about the plugin.
  • Description: a description of the plugin.
  • Version: the current version of the plugin.
  • Requires at least: the minimum WordPress version the plugin will support.
  • Requires PHP: the minimum PHP version the plugin will support.
  • Author: the author of the plugin.
  • Author URI: the web address of the plugin author.
  • License: the license the plugin supports.
  • License URI: a URL to the license the plugin supports.
  • Text Domain: essentially the slug of the plugin.
  • Domain Path: which folder to find the translations.
  • Network: whether the plugin should be network activated or not.

For the sake of the plugin we’re creating, we’ll set everything except the Network field, which should only be set to true if the plugin must be network activated on a multisite install.

Let’s go ahead and set up the plugin header for our plugin.

Setting up the Plugin Header

As a reminder, here is our current folder structure for the plugin:

└── landing-page-gutenberg-template ├── landing-page-gutenberg-template.php ├── autoloader.php ├── languages ├── src │ ├── js │ │ └── index.js │ ├── scss │ │ ├── template.scss │ │ └── common.scss │ ├── languages │ └── includes │ └── Include files go here. ├── webpack.config.js └── .babel
Code language: AsciiDoc (asciidoc)

You may notice that the folder name is landing-page-gutenberg-template and the plugin file is named similarly as landing-page-gutenberg-template.php.

It’s not exactly a requirement or best practice to name your plugin file the same as your plugin folder, but it sure makes it easier for someone glancing at the plugin’s code where the main plugin file is.

Furthermore, if you plan to release on the WordPress Plugin Directory, your folder name usually translates into the plugin’s slug when browsing the plugin directory. The slug of your plugin is also typically your plugin’s text domain for translations. So in essence, we have to assume the following about this plugin and its header (if we were to release on the plugin directory):

  1. Folder name: landing-page-gutenberg-template
  2. Main plugin file: landing-page-gutenberg-template.php
  3. Plugin Slug: landing-page-gutenberg-template
  4. Text domain: landing-page-gutenberg-template

A Heads Up About Plugin Slugs

Of note here is the plugin slug. It is very important to have a unique slug for your plugin. If the slug is rather generic, such as store-locator, you run the risk of an actual WordPress Plugin Directory plugin thinking it has an update and overwriting the plugin and breaking your site. Most non-.org plugins usually prefix a slug in front of the plugin. For example, Paid Memberships Pro has a ton of third-party add-ons. They usually prefix their slug with pmpro-{plugin-name}.

One trick I learned is to look at WordPress Trac to see if a slug is already taken. For example, my plugin Simple Comment Editing can be found at https://plugins.trac.wordpress.org/browser/simple-comment-editing/. You can replace /simple-comment-editing with whatever slug you’re thinking of using. For example, if you want a slug of nuclear-blocks, you can check https://plugins.trac.wordpress.org/browser/nuclear-blocks and determine that the slug is not taken as of this writing.

The Plugin URI

I’ll set the Author URI to this domain, and the Plugin URI will link to the GitHub repository for this particular plugin.

Let’s go ahead and edit landing-page-gutenberg-template.php to include the plugin header.

<?php /** * Plugin Name: Landing Page for Gutenberg * Plugin URI: https://github.com/wpajax/landing-page-gutenberg-template * Description: Creates a blank template for creating landing pages with Gutenberg and the theme Twenty Twenty One * Version: 1.0.0 * Requires at least: 5.5 * Requires PHP: 7.2 * Author: Ronald Huereca * Author URI: https://wpandajax.com * License: GPL v2 or later * License URI: https://www.gnu.org/licenses/gpl-2.0.html * Text Domain: landing-page-gutenberg-template * Domain Path: /languages */
Code language: PHP (php)

The above code will result in the following in the WordPress plugin’s screen in the Dashboard:

WordPress Plugin in the WordPress Plugin’s Screen

Plugin Name: Landing Page for Gutenberg
Plugin title showing on the WordPress plugin screen.
Plugin description
Plugin Description on the plugin’s screen

PHP Namespaces and Constants

Now that we have our plugin header set, let’s add some constants and namespaces to the main plugin file. For our plugin, the namespace will be WPAndAjax.

Let’s go ahead and set the namespace and constants for our plugin.

<?php namespace WPAndAjax; /** * Plugin Name: Landing Page for Gutenberg * Plugin URI: https://github.com/wpajax/landing-page-gutenberg-template * Description: Creates a blank template for creating landing pages with Gutenberg and the theme Twenty Twenty One * Version: 1.0.0 * Requires at least: 5.5 * Requires PHP: 7.2 * Author: Ronald Huereca * Author URI: https://wpandajax.com * License: GPL v2 or later * License URI: https://www.gnu.org/licenses/gpl-2.0.html * Text Domain: landing-page-gutenberg-template * Domain Path: /languages */ // Exit if accessed directly. if ( ! defined( 'ABSPATH' ) ) { exit; } define( 'WPAJAX_LANDING_VERSION', '1.0.0' ); define( 'WPAJAX_LANDING_DIR', plugin_dir_path( __FILE__ ) ); define( 'WPAJAX_LANDING_URL', plugins_url( '/', __FILE__ ) ); define( 'WPAJAX_LANDING_SLUG', plugin_basename( __FILE__ ) ); define( 'WPAJAX_LANDING_FILE', __FILE__ ); define( 'WPAJAX_LANDING_PLUGIN_URI', 'https://github.com/wpajax/landing-page-gutenberg-template' );
Code language: PHP (php)

The namespace will keep our plugin organized and prevent naming conflicts. The constants will provide useful information other plugins can use and will make things easier in the future if we decide to add a plugin settings screen or need to enqueue some assets.

Conclusion

In this series post, I explained what plugin headers were and set up some basic header information for our sample plugin.