How to create a WordPress Plugin?

Plugins in WordPress are used for enhancement, modification and customization of a website. With the help of plugins, you easily can add functionality instead of changing the codes. In brief, WordPress Plugin is a program written in PHP, which can be integrated with your website and allows to add some services or features.

Do you want to have new functionality? Firstly, try to find a plugin which will meet your requirements. If there is no such plugin, this article will be useful for you since it gives some useful advice related to the creation of the WordPress plugin. In addition, we hope that you are familiar with PHP programming and basic functionality of WordPress.

First you need to do is think about what features your Plugin will have, and choose a suitable name for it. It is better to use the name that will describe what the Plugin will do. For example, a contact form-related Plugin would probably have the words “contact form” in its name. You can use several words for it. Also, try a Google search to verify if your proposed name is unique.

When you pick a name, create a PHP file with a similar name. For example, if your Plugin is called “Contact Form”, your PHP file will have the name contact-form.php. We suggest using an original name. When installing your Plugin, people will put this PHP file into wp-content/plugins/ – their WordPress Plugins directory, that is why your PHP file should have an orginal name.

Another step is to split your Plugin into several files. You should create one PHP file at least. In addition, it will contain CSS files, JavaScript files, language files, image files, etc. If there is more that one file, choose the original name for the main PHP file of your plugin and for a directory such as contact-form and contact-form.php respectively, paste all your Plugin’s files into that directory. Tell your plugin users that the whole directory should be installed under wp-content/plugins/. You have to use plugins_url() and plugin_dir_path() for absolute URLs and paths since the installation in wp-content/plugins/ directory can be moved. Before calling any WordPress functions, make sure you avoid executing standalone sensitive PHP code, as well as evade blocking plugins PHP files by having the following code in the each file:

defined(‘ABSPATH’) or die(“No script kiddies please!”);

You should also have a readme.txt file in a standard format if you want your plugin to be hosted on WordPress http://wordpress.org/extend/plugins/. Find the automatic plugin ‘readme.txt’ generator or check a WordPress tutorial for a detailed description

Please consider that in the stable tag, the WordPress plugin repository takes the “Tested up to” and “Requires” versions from the readme.txt.

It is definitely better to have a home page of your plugin. It should tell about the plugin features,  what versions of WordPress it is compatible with, how to install and how to use it, what has changed from the previous version.

The next step is to fill your plugin PHP file.

Standard Plugin information header should be placed at the top of the main PHP file of your Plugin. Your Plugin will never be activated without this header, since it should be recognized by WordPress to be added to the Plugin management screen. Only after that, your plugin could be loaded and activated. Here is the format of the header:

<?php
/**
* Plugin Name: Plugin`s Name
* Plugin URI: http://URI_Describes_Plugin_and_its_Updates
* Description: Short description of the Plugin.
* Version: The Number of Plugin’s Version, e.g.: 1.1
* Author: Author`s Name
* Author URI: http://Author`s_URI
* License: The name of “Slug” license e.g. GPL3
*/

The order of the lines is not important. It is the minimum information needed for WordPress to recognize your plugin. The rest of the presented information is necessary for the plugin management screen to create the table of plugins.

Also, the License slug should be in a form of a short common identifier since it should be easy to recognize. Notice that the file should be in UTF-8 encoding.

The majority of plugins use a license compatible with the GPL2 or the GPL2 license used by WordPress. It is necessary  to follow the information about Plugin`s licensing. Include the following lines in your Plugin to indicate a GPL2 license:

<?php
/*  Copyright YEAR  PLUGIN_AUTHOR_NAME  (email : PLUGIN AUTHOR EMAIL)

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License, version 2, as
published by the Free Software Foundation.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/

The next step is to make your Plugin actually working. This part of the article tells about how to accomplish those things the Plugin will need to perform.

Some Plugins are trying to achieve their goals by using plugin “hooks”. They can modify default WordPress behavior. These hooks make WordPress check if any plugins have running functions at that time, and run the functions of your plugin if so.

For example, before adding the title of a page to browser output, the hook checks if any Plugins have the similar function. If so, the title text will be put in turn through each registered function. The “action” hook called “wp_footer” is another example of a hook. It checks to see whether any Plugins have registered functions for the “wp_footer” action hook just before the end of the HTML page WordPress is generating and runs them in turn.

Creating custom Template Tags is another way for a WordPress plugin to add functionality to WordPress. People using your plugin can include these “tags” to their theme, post content section, in the sidebar etc. For example, a plugin that can add a geographical tag to pages might define a template tag function called geo_list_states() for the sidebar. It lists all the state-based archive pages the Plugin enables with the states posts are tagged with.

Simply type a PHP function and document it for users of the plugin on your homepage and/or in the main PHP file of the plugin in order to define a custom template tag. It is a great solution to give an example what exactly should be added to the theme file to use the function, including ?> and <?php.

It is often necessary to get some input from blog users or the site owner and save it between sessions, for use in its template functions, action functions and filter functions. In order to be persistent between sessions, this information has to be saved in the WordPress database. Here are four ways to save plugin data in the database:

• Use the described below WordPress “option” mechanism. This method is great for saving relatively small amounts of named, relatively static pieces of data. It is the type of data you would expect the site developer to enter when setting up the Plugin first time.
• Post Meta is appropriate for data associated with individual attachments, posts or pages.
• Custom Taxonomy method. It is necessary for classifying objects like comments and users or posts for a user-editable data list of value/name, especially when all objects/ posts you want to access are associated with a given taxonomy term.
• Creation of a new, custom database table. It is suitable when the type of data doesn’t have individual names and that will grow as time goes on and for data not associated with attachments, individual posts, comments or pages.

The WordPress database provides  an option to retrieve, update and save named, individual data pieces (“options”). Option values can be PHP objects, arrays or strings (when retrieved, they will be converted to a string). Option names must be unique since they are strings. Make sure they do not conflict with other Plugins or WordPress.

Also, it will be better to use minimum options for your plugin.  It is suggested to store a serialized array of 10 elements as a single named option, instead of storing 10 various named options.

Now take a look at the main functions to access WordPress options, which your Plugin can use:

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

To create a new option; if option already exists it does nothing.

$name

Required (string). Name of the option you want to add.

$deprecated

Optional (string), WordPress no longer uses it. However, if you wish to use the following $autoload parameter, you may pass null or an empty string or to this argument.

$value

Optional (mixed), defaults to empty string. The option value that you want to store.

$option

Required (string). Name of the option value which you want to return.

update_option($option_name, $newvalue);

Creates or updates an option value in the database (pay attention that if you do not want to use the $autoload or $deprecated parameters, the add_option does not have to be called).

$autoload

Optional, defaults to ‘yes’ (enum: ‘no’ or ‘yes’). The setting is automatically retrieved by the wp_load_alloptionsfunction if set to ‘yes’.

get_option($option);

It is used to retrieve an option value from the database.

$newvalue

Required. (string|array|object) The option new value.

$option_name

Required (string). Name of the option to be updated.

Once you have created the Plugin, another step is to internationalize it. Internationalization means to set up software the way that it could be localized; localization means translate displayed text  into multiple languages. Localization and internationalization and built into the structure of WordPress since it is used all around the world.

Please, pay attention that plugin language files are for manual load. To make sure the language files are loaded, add this to the plugin code:

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

To return the translation or _e(‘String name’,’your-unique-name’) to echo the translation; to fetch a string simply use __(‘String name’,’your-unique-name’);. You will then find your translation files in languages/plugin’s folder. It is very important to internationalize the plugin so that the users from various countries will be able to localize it.

When you host your plugin on http://wordpress.org/extend/plugins, it is necessary to update it from time to time to fix bugs or add features. You can make these changes and commit them to your plugin trunk as often as you need. All changes made will be visible to the technically-minded people from WP team who check out the Plugin using SVN.

Once you are ready to release your Plugin:

• Make sure new version actually works and everything is committed. Try to test all WordPress versions your Plugin supports and pay attention to all of them. Do not concentrate on testing the new features only; make sure that the older functionality of the Plugin works perfectly as well.
• In the header comment of the main PHP file in the trunk folder, change the version number to the new one.
• Change the number of version in the trunk folder in the ‘Stable tag’ field of the readme.txt file.
• In the ‘changelog’ section of the readme.txt file, add a new subsection which will describe the changes made, compared to the last release in short. It will be displayed on the Plugin page in the ‘Changelog’ tab.
• Do not forget to commit all changes.
• As a copy of trunk create a new SVN tag

Wait five minutes to let the system do its job, and then go to wordpress.org Plugin page to check if WordPress installation shows an update for your Plugin and everything updated correctly. This could take some time since the update checks might be cached.

Troublesolving:

• If the Plugin’s page on wordpress.org still shows the old version, check the trunk folder. Did you updated the ‘stable tag’ field there? It is not enough just to update the readme.txt in the tag folder and create a tag.
• Do not forget to update the ‘Version’ comment in the main PHP file. If not, no update notification will take place  in your WordPress installations, the Plugin’s page will offer a zip file with the new version, but the button will display the old version number.

Here is some casual advice regarding Plugin development.

• The code of your Plugin should be prepared in a strict accordance with the WordPress Coding Standards.
• All plugin functions should to have different names from other themes and plugins, as well as functions in the WordPress core. That is why, it will be perfect to use an original prefix on all functions of your plugin. To define your Plugin functions inside a class is a far superior possibility and it is also needed to choose a unique name for it.
• Be sure you are using the $wpdb->prefixvariable, do not hardcode the WordPress database table prefix (usually “wp_”) instead.
• Database writing is expensive while reading is cheap. Databases are quick and good at fetching data and bringing it to you. The more complex and expensive thing is to make changes to the database that is why try to minimize the amount of it. Make sure your code is ready first, so that you can make only the needed changes.
• Instead of using direct SQL, use WordPress’ APIs  where possible. For instance, instead of SELECT * FROM {$wpdb->prefix}_posts, use get_posts() or new WP_Query().
• Instead of creating new custom tables, use the existing database tables if its possible. Before adding a table think very carefully since it adds an unnecessary complexity to your plugin. In most cases it can be accomplished with meta data, custom taxonomy, custom post types or/and one of the other standard tables.
• Choose what you need only. You should try to reduce the load on the database even though databases fetch data blindingly quickly. Use only the data you really need. Do not SELECT * FROM if you need to count the number of rows in a table, since it will waste memory by pulling all the data in all the rows. Similarly, to minimize database load, just select those specific fields if you only need the post_author and the post_id in your Plugin. Notice: a large number of processes ran simultaneously overloads the database. The server and database each have limited resources to handle them. Knowing how to minimize those processes is very useful so your plugin will not be blamed for the overspending resources.
• Add define(‘WP_DEBUG’, true); to your wp-config.php file and eliminate PHP errors in your plugin. Check if there are any warnings or errors and try all of your plugin functionality. Fix all occurred bugs, and until they have all been eliminated continue in debug mode.
• Use the recommended wp_enqueue_script() and wp_enqueue_style() functions instead of trying to echo <style> and <script> tags directly. It will help you to introduce dependency support, as well as to eliminate including duplicate styles and scripts.