Creating a Plugin

At the core of any plugin lies PHP code, the logic of its operation, and the correct use of the WordPress API. The task of any plugin should be to create new functionality with the least possible load, compatibility with the WordPress core, and proper code operation in a constantly updating system.

Creating a Plugin

To create a WordPress plugin you need to:

1. Create a plugin folder. This will hold the files of our plugin. It is created in the folder of all WordPress plugins. For example, create a folder /wp-content/plugins/my-plugin-name.

2. Create the main plugin file. It is recommended that the name of this file matches the name of the plugin folder. For example, my-plugin-name.php → /wp-content/plugins/my-plugin-name/my-plugin-name.php.

3. Create the plugin description - plugin headers. They are needed for WordPress to recognize the plugin as a plugin; otherwise, it simply will not work. At the very beginning of the main plugin file, you need to add a PHP comment where you specify the name of the plugin:

   <?php
   
   /*
    * Plugin Name: My First Plugin
    */

Done! Now our plugin can be seen in the Plugins section of the admin panel.

Additional Data in the Header

To make the plugin work, it is enough to specify only Plugin Name (the name of the plugin). But you can also specify other parameters of the plugin - this will improve the display of the plugin in the WordPress console.

<?php

/**
 * Plugin Name: Plugin Name
 * Description: Plugin description (140 characters)
 *
 * Plugin URI:  Link to the plugin page
 * Author URI:  Link to the author
 * Author:      Author name
 *
 * Text Domain: Translation ID, specified in load_plugin_textdomain()
 * Domain Path: Path to the translation file.
 *
 * Requires at least: 5.7
 * Requires PHP: 7.0
 *
 * License:     GPL2
 * License URI: https://www.gnu.org/licenses/gpl-2.0.html
 *
 * Network:     true - activates the plugin for the entire network
 * Update URI:  https://example.com/link_to_update
 *
 * Requires Plugins: some-plugin, some-plugin-2
 *
 * Version:     1.0
 */

// plugin code

Plugin Name:(required)

The name of the plugin, which is displayed in the plugin list in the admin area.

Description:

A brief description of the plugin, which is displayed in the Plugins section in the admin area. It is recommended not to exceed 140 characters.

Version:

The current version number of the plugin, for example, 1.0 or 1.0.3.

When setting the version, keep in mind that WP uses the version_compare() function for version comparison. Therefore, when changing the version, ensure that the new version is higher. For example, 1.02 is greater than 1.1.

Plugin URI:

The homepage of the plugin, which can be on WordPress.org or on your own site.

Author:

The name of the plugin author. There can be more than one author in the list.

Author URI:

The author's website or profile on another website, such as WordPress.org.

Requires at least:

The minimum required version of WordPress. For example: 5.7.

Requires PHP:

The minimum required version of PHP. For example: 7.4.

License:

The short name of the plugin license, such as GPL2. More detailed information about licensing can be found on WordPress.org.

License URI:

A link to the license, for example, https://www.gnu.org/licenses/gpl-2.0.html.

Text Domain:

The translation identifier (localization domain), used in localization functions and in the name of the .mo translation file. For more details, see quote here.

Domain Path:

Needed if the translation file is not in the same folder as the current file. For example, if the .mo file is in the /myplugin/languages folder and the plugin file is in /myplugin/myplugin.php, then specify /languages here.

Network:

Specify "true" for the plugin to be activated across the entire network of sites in the MU WordPress build. This will make it impossible to activate the plugin for a single site if the multisite is activated.

Update URI:

The URL for updating the site. Used in the wp_update_plugins() function. A hook update_plugins_(hostname) will be created from the domain.

Requires Plugins:(WP 6.5)

A list of plugins that the current plugin depends on. You need to specify the plugin slugs (comma-separated). For example, my-plugin (usually this is the name of the plugin folder).

Template for Creating a WordPress Plugin

To avoid creating files and structure from scratch, you can use a template for creating a plugin:

• WordPress Plugin Boilerplate - a template generator where you specify the name of the plugin, which will be used in the names of folders, classes, and functions - WordPress Plugin Boilerplate Generator.

The template represents a standard and organized object-oriented foundation.

The template adheres to PHP coding standards for WordPress.

Using this approach, you can be sure of a clearer and more understandable structure of the plugin. This way, you can generate the base and then simply delete all unnecessary files, leaving the folder structure - structure is important!

Hooks in a Plugin

Throughout the WordPress core, there are many hooks. Hooks allow you to connect to the core WordPress code at specific points to change its behavior without affecting core files.

There are two types of hooks in WordPress:

• Actions — allow adding or changing WordPress functionality.
• Filters — allow modifying data.

Hooks are necessary not only for plugin developers but also for those who will use your plugin. Hooks are used everywhere: in the WordPress core itself, in plugins, and themes. It is hooks that make WordPress so flexible.

There are three functions directly related to plugins:

• register_activation_hook() - registers a function that will be triggered during the activation of the plugin.
  It is used to add plugin settings, etc.

• register_deactivation_hook() - registers a function that should run after the plugin is deactivated.
  It is used to remove temporary plugin data.

• register_uninstall_hook() - registers a function that is called when the plugin is deleted.
  It is used when deleting the plugin to remove all plugin data: in settings, in files, in the database, etc.

You can create your own hooks in the plugin's source code using do_action() or apply_filters(). They will allow your plugin users to extend its capabilities, just as WordPress allows you to extend your capabilities.

Imagine that you created a plugin and it is used by another developer, but you continue to improve the plugin and release new versions. When updating, all previous plugin files are overwritten with new ones. Thus, if another developer made changes directly to your plugin files, their changes will be lost. To prevent this from happening, hooks are needed, which will allow another developer to extend your plugin without modifying the plugin's own code.

PHP Functions and WordPress API

WordPress provides a number of APIs. APIs can significantly simplify coding. That is, there is no need to reinvent the wheel when it already exists.

Some WordPress APIs:

• Settings API - simplifies the creation and management of plugin options that are saved in the database.

• plugin_dir_url() — Get the URL directory path (with trailing slash) for the plugin __FILE__ passed in.
• register_activation_hook() — Registers a function that will be triggered at the time of plugin activation.
• register_deactivation_hook() — Set the deactivation hook for a plugin.
• register_uninstall_hook() — Set the uninstallation hook for a plugin.

• HTTP API - simplifies the creation of HTTP requests in PHP. A great replacement for bicycles on cURL.

How WordPress Loads Plugins

When a plugin is activated, WordPress writes the path to its main file in the active_plugins option. Then, when loading any page (admin and front), WordPress simply includes all files from the active_plugins option (the paths are stored there as an array). See how this looks:

$active_plugins = get_option( 'active_plugins' );

/* We will get in $active_plugins
Array
(
	[0] => hello-dolly/hello-dolly.php
	[1] => backupwordpress/backupwordpress.php
	[2] => democracy-poll/democracy.php
	[3] => disable-emojis/disable-emojis.php
)
*/

From all this, it follows: simply by their presence, plugins do not affect the speed of the site (except for including the plugin file, which is a super fast operation). Inactive plugins do not affect it at all. For more details read here.

WordPress Plugin Repository

A plugin can be personal (created only for one site) or public (posted in the WordPress plugin repository).

Requirements for personal plugins are usually minimal, while public ones are more complicated; they require a license, support, compatibility, localization, and more. Therefore, creating public plugins is many times more difficult.

If you plan to submit the plugin to WordPress.org, you must follow the WordPress plugin header requirements.

The license informs users how they can use the plugin code for their purposes. To maintain compatibility with the WordPress core, it is recommended to choose a license that works with GNU General Public License (GPLv2+).