Plugins are a big reason why WordPress has gotten as powerful and as popular as it has, for they extend the functionality of WordPress in many different ways, including adding shopping carts, boosting SEO ratings, adding widgets and calculators to make conversions, etc.
What are Plugins and how do they work?
Plugins for WordPress add functionality and features to the core WordPress engine. That said, one should NEVER mess with the WordPress core itself–the wp-admin folder. Plugins are basically php files that use php functions to execute commands (essentially a mini-program), and they can be used interchangeably by different themes, because they reside in a different folder alongside the themes folder–namely, the “plugins” folder inside of the wp-content folder.
Plugins can be more than just one php file, however–it can be a whole folder with subfolders, including a functions.php file, but will have one php file with unique header text to identify it. More on that in a moment.
Steps to creating plugins
1. What does it do?
The first step to developing a plugin is deciding what functionality it will have–essentially, what do you want it to do–and then coming up with a suitably descriptive name for it, and if it is a name that is certain to be used by other plugins, come up with a unique “prefix” for the name that will differentiate it to the WordPress engine. The name can have multiple words in it, and best practice is to name it symantically (according to function).
Plugins must have at least one php file (with the php functions), but can also use JavaScript, HTML and CSS (for how it will display), image files, language files, etc. In the case of multiple files, it is your plugin folder and the main php file in that folder that need to be named uniquely.
2. Header
The next step is to create your main Plugin PHP file and fill in the header section. This information will allow WordPress to know that your plugin exists, in order to add it to its Plugin Management screen on the user’s Dashboard in order to activate it. (So it’s really important, because without this header, your plugin won’t run.)
<?php
/*
* 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.0
* Author: Name Of The Plugin Author
* Author URI: http://URI_Of_The_Plugin_Author
* License: A “Slug” license name e.g. GPL2
*/
Of this sample, it is the “Plugin Name” that is most important. Even though it is a comment (so it will not execute as code), WordPress will see and recognize it. The rest of the information is actually optional (but good form), and the order of the lines is not important. WordPress will use the other information in a table of information about the plugin. Be consistent in whatever numbering convention you use for versions between updates.
Another really important thing to include in your header is the encoding, and for WordPress plugins, the encoding MUST be UTF-8 encoding. There is a ini directive for this in PHP, and you can use (but not commented out, as you need this code to actually run):
ini_set(‘default_charset’, ‘UTF-8’);
3. Actual Programming–Wordpress hooks, Actions, and Filters
Plugins use “hooks” for how to know when/where on the page to display/activate, and those hooks are already included in the WordPress module (and cannot be changed or modified–you just need to know what they are. Don’t worry, there are a LOT of them, so you can usually find something to hook to when/where you need it). For a thorough listing of WordPress Hooks for all the different versions, check out the exhaustive http://adambrown.info/p/wp_hooks for more information.
Intermittently, WordPress will check to see if any plugins have functions to run at any given time, and if so, these functions are run, and modify the default behavior of WordPress.
Let’s take, for an example, “the_title” hook in WordPress. If a plugin needs to add information to or style the title in any way, and therefore references the_title as the function’s hook, WordPress will check that before it adds the title to the browser page, making any modifications that the plugin calls for.
There are two kinds of hooks, Actions, and Filters.
Actions are triggered when certain events happen, such as changing themes, publishing a post, displaying an administrative screen. An Action function is a custom php function defined in your plugin and hooked (set to respond) to some of these events.
The basic process is, in your plugin file:
1. Create a php function that executes when a specific event occurs.
2. Hook this function to the event by using the add_action() function.
|
Actions Functions |
|
Filter Functions |
Basically, you are writing functions that do something, either action or filter text, and then “call” that function through attaching it to a WordPress hook. Here is a really basic example of a main php plugin file, with the most basic header:
<?php
/*
Plugin Name: My Plugin
*/
function my_function ($text) {
$text = str_replace(‘foo’, ‘bar’, $text);
return $text;}
add_filter(‘the_content’, ‘my_function’);
?>
I would actually omit the php closing tag for best practices 😉 The “my_function” is doing a string replace of taking every instance of “foo” and replacing it with “bar.” Then the “add_filter” is hooking into the WordPress hook “the_content” and calling “my_function” every instance that the content appears in order to do the text replace. Realize that the filter will ONLY be applied to the_content and not other portions of the page, for instance, such as the_title and the_header, and so on. You have to know where and when and be very specific with your function calls, how to hook them in to perform. Once you have a function written, you can hook it into multiple hooks, by simply adding more add_filter, add_action statements, etc., closing each one with a semicolon.
Interlinking multiple files within a Plugin
Regardless of the fact that you’ve instructed the user where to place your plugin to be able to load it, WordPress allows users to put plugins wherever they want, so you must not assume that a user will follow your direction, or that uploads will be in the wp-content/uploads or that themes will be in wp-content/themes, so the fix for that potential descrepancy is using php functions to link between files so that they can find each other rather than hard-coding references.
For instance, with JavaScript or CSS files that would reside in a separate folder (“js” or “css”) inside the plugin directory, you can use the plugins_url() function (instead of a url, as with a “require once” or “include”:
plugins_url( ‘myscript.js’, __FILE__ );
Then this function will dynamically return the current url/path to the object for access on your php page. [eg. example.com/wp-content/plugins/myplugin/myscript.js.]
Loading and Using your Plugin
Once you’ve finished writing all the php to make your plugin work, then you can load it into the wp_content > plugins folder, and access it through Dashboard, under Plugin Management. From there, one can activate it and start using it (or troubleshooting it until it’s ready for use).
Sharing your Plugin With others
If you want to allow other people to use your plugin (and gain some recognition, or potentially monetize it at some point), you can host it on WordPress.org. You will need to create a README.TXT file. There is a “readme.txt template” on WordPress.org that is a great model at http://wordpress.org/plugins/about/readme.txt. There’s even a readme file generator! (http://generatewp.com/plugin-readme/)
WordPress will access the “Requires” [min version of WordPress plugin requires] and “Tested up to” [highest version plugin tested for] version numbers from the readme.txt file for the plugin to determine whether the version installed and trying to load it fits in that range.
It is considered standard practice, when one is sharing a plugin, to create a “home page” to also host that plugin as well as offer some documentation and support for it. Usually this page will describe to users how to install the plugin (put the plugin file(s) into their “plugins” folder of wp-content), what the plugin does, what versions of WordPress it is compatible with (that range that was mentioned in the readme.txt file), what has changed from version to version of your Plugin (if you have multiple versions) and how to use the plugin. Screenshots are invaluable for this last, especially if you have built in an API. The more complex your plugin, the more documentation you may need to provide to help usability.
For the purposes of at least getting this completed, I have scaled down a lot of what is involved in programming plugins to the bare basics, but should you feel inspired to delve deeper (and I hope that you do, as I plan to), there are some resources below to reference to, not the least of which are from the WordPress Codex, the repository of documentation for all things WordPress.
Resources:
http://codex.wordpress.org/Writing_a_Plugin
http://codex.wordpress.org/Determining_Plugin_and_Content_Directories
http://codex.wordpress.org/Function_Reference/wp_enqueue_script
http://htmlpurifier.org/docs/enduser-utf8.html
http://codex.wordpress.org/Plugin_API
http://adambrown.info/p/wp_hooks