How to Create a WordPress Plugin

Sometimes a WordPress theme’s built- in features are not just enough to provide that needed look and feel to your WP blog. This is the time when you desire for a plugin that enriches your blog and makes it different from the rest. The very first thing you can do is to find some already created plugins in the WP repositories that fulfill your criteria. Otherwise, you can always create your own custom plugin referring this small post on coding standards for developing a well-structured WordPress plugin.

WordPress Plugins are small programs developed in PHP with a set of functions to give an added functionality to a WordPress Website/Blog. These plugins can be easily integrated with the WP blogs using the WordPress Plugin API.

Naming a Plugin

Finding out a relevant and unique name for your plugin is the very first step you need to do. A plugin should be named in a way that the functionality of your plugin is reflected in its name. Like a plugin for Google Maps is named as “WP Google Map Pro Plugin” that by its very name gives an idea about the work it does. To find if your name is already taken you can search through the WordPress Plugins repositories or hit Google.

Creating the Plugin File

The very next step is to start creating the plugin PHP file. You may name the plugin PHP file as per your plugin name like wp-google-map.php for a google map plugin. Make sure to uniquely name this file too because while installing the plugin is placed in the WordPress Plugins directory (wp-content/plugins/) where no two plugins can have the same name.

If your plugin is in form of multiple files with one as the main PHP plugin file and other JS, CSS, Image files, language files etc. then you can place all the files into a single directory and uniquely name it giving the same name to the main PHP file. During installation, this entire directory can be placed in the WP Plugins directory.

For absolute paths and URLs to configure WP Installation, you can use the plugin_dir_path() and plugins_url().

Readme File

Create a readme.txt file in a standard format to elaborately describe your plugin and place in your WordPress directory. To check out the proper format of the file, you can click at http://wordpress.org/extend/plugins/about/readme.txt.

The WP plugin repository fetches the “Requires” and “Tested up to” version information for all the plugins hosted at http://wordpress.org/extend/plugins/ from the readme.txt file.

Home Page

It is a good practice to create a web page that acts like the home page for your WordPress Plugin. This page can describe various aspects of the plugin like plugin installation, plugin features, plugin version update history, compatible WordPress version, and how-to-use instructions etc.

Plugin Headers

A WordPress Plugin file should consist of some standard plugin information in form of header. This header lets WordPress recognize your plugin file, add it to the Plugin management screen to activate it, load it, and run its functions. No plugin file can be activated or run without a header.

Here is the standard plugin header format:

/**

 * Plugin Name: Name Of The Plugin

 * Plugin URI: http://URI_Of_Page_Describing_Plugin_and_Updates

 * Description: A brief description of the Plugin.

 * Version: The Plugin's Version Number, e.g.: 1.2

 * Author: Name Of The Plugin Author

 * Author URI: http://URI_Of_The_Plugin_Author

 * License: A "Slug" license name e.g. GPL2

 */

The plugin header at least requires Plugin Name to recognize your Plugin. The rest of the information is optional and is used to create the Plugins Table on the Plugin management screen.
The License slug contains a short identifier to identify the license under which the plugin falls. This is a simple way to stay explicit about the code license.

Programming Your Plugin

The below section consists of standard ways to develop a WordPress Plugin and make it functionally active.

a) WordPress Plugin Hooks

WordPress Plugin Hooks are generally used by plugins to trigger their actions. A hook periodically checks throughout WordPress Core if any plugin has a registered function to be run at that instance of time and if so executes it. You can implement a WordPress Hook by using either of the actions or filters which are two kinds of hooks.

An action is used to add/ remove the code from existing actions and make them perform additional functions whereas a filter allows replacing specific data like the variable from existing actions and thus manipulating outputs.

This can be cited by an example. Before WordPress displays a post title it will check if any plugin has a registered function for the “filter” hook called “the_title” and if found, runs it in turn.

b) Template Tags

Implementing template tags in a plugin is a method to create additional features and customize your WordPress blog. You can add these template tags to display them anywhere within your blog including sidebars, footer, inside post content etc.

There are 9 template tag files which are located in wp-includes directory. Each template tag file is name is suffixed with “-template.php”.

• wp-includes/general-template.php
• wp-includes/author-template.php
• wp-includes/bookmark-template.php
• wp-includes/category-template.php
• wp-includes/comment-template.php
• wp-includes/link-template.php
• wp-includes/post-template.php
• wp-includes/post-thumbnail-template.php
• wp-includes/nav-menu-template.php

You can write a custom template tag by simply writing a PHP function and documenting it on the plugin’s home page or plugin’s main PHP file to help users know what to add in the theme file to use the function.

Saving Plugin Data to Database

WordPress Plugins receive all its input data for use in its filter, action and template functions from site owner or blog users that are saved between sessions. In order to remain persistent between sessions, this input data needs to be saved in the WordPress database. You can save the plugin data in the database using four methods:

1. Use the WordPress “option” mechanism to store relatively small amounts of relatively static, named pieces of data — the type of data a site owner will enter when first setting up the Plugin, and rarely change thereafter.
2. The Post Meta/ Custom Fields can be used for data associated with individual posts, pages, or attachments.
3. To classify posts and other objects like users and comments or for a user-editable name/value list of data, you can use custom taxonomy. This is used especially when you want to access all posts/objects associated with a given taxonomy term.
4. You can also create a custom new database table for plugin setup data and data that in form of expanded information related to posts, categories, uploads, and other WordPress components.

WordPress Options Mechanism

WordPress provides a mechanism to save, update or retrieve individual or named pieces of data called as “options”. Option values can be strings, arrays, or PHP objects with unique names so as not to conflict with WordPress or other Plugins. These values are “serialized” (converted to a string) before storage and unserialized when retrieved.

You must try and minimize the number of options you use for your plugin. For example, in place of storing 10 different named options, you can store a serialized array of 10 elements as a single named option.

Some important functions to access WordPress options are:

a) To create a new option

add_option($name, $value, $deprecated, $autoload);

Here,

$name- Required (string). Name of the option to be added.

$value- Optional (mixed), defaults to empty string. The option value to be stored.

$deprecated- Optional (string), no longer used by WordPress, You may pass an empty string or null to this argument if you wish to use the following $autoload parameter.

$autoload- Optional, defaults to ‘yes’ (enum: ‘yes’ or ‘no’). If set to ‘yes’ the setting is automatically retrieved by the wp_load_alloptions function.

b) To retrieve an option value from the database

get_option($option);

Here,

$option- Required (string). Name of the option whose value you want to be returned.

c) To update or create an option value in the database

update_option($option_name, $newvalue);

Here,

$option_name- Required (string). Name of the option to update.

$newvalue- Required. (string|array|object). The new value for the option.

Internationalizing Your Plugin

Since WordPress is used worldwide so internationalizing is very crucial for plugins. It involves setting up a software for translating the text of plugin into local languages (localization).

Add the following code to the Plugin file to load language files:

load_plugin_textdomain('your-unique-name', false, basename( dirname( __FILE__ ) ) . '/languages' );

Plugin Development Suggestions

Here are some more suggestions to be taken care of while developing a WordPress Plugin.

• Follow WordPress Coding Standards and Inline Documentation while coding your plugin.
• Make sure to uniquely name all functions in your plugin from other functions present in the WordPress core, other Plugins, and themes files. You can also use a common prefix for names of all functions within the plugin.
• It is highly recommended to define all Plugin functions inside a class with a unique name again.
• Do not hardcode WordPress database table prefix (usually “wp_”) into your plugin. Make sure to use $wpdb->prefix variable instead.
• Try to minimize the amount of writing to the database. Make only those write operations that you need.
• Use WordPress’ APIs instead of using direct SQL wherever possible. Example, use get_posts() or new WP_Query() instead of SELECT * FROM {$wpdb->prefix}_posts.
• Use the existing database tables which are capable of accomplishing most use-cases instead of creating new custom tables. Adding new tables add complexity to the plugin.
• SELECT only what you need to reduce the load on the database. If you need to count the number of rows in a table don’t SELECT * FROM, because all the data in all the rows will be pulled, wasting memory.
• Eliminate PHP errors in your plugin. Add define(‘WP_DEBUG’, true); to your wp-config.php file, try all plugin functionalities and test for any errors or warnings. Fix all that occurs and continue in debug mode until each error is eliminated.
• Try not to echo <script> and <style> tags directly but use the recommended wp_enqueue_style() and wp_enqueue_script()functions. They help eliminate duplicate scripts and styles and introduce dependency support.

Sources:

https://codex.wordpress.org/Writing_a_Plugin