As I promised, here is an article to help you program your WordPress Plugin.
Many WordPress Plugins achieve their goals by connecting to one or more WordPress Plugin “hooks”. The way Plugin hooks work is that at various times while WordPress is running. WordPress checks if any Plugins have registered functions to run at that time, and if yes, the functions are run. These functions adjust the default behavior of WordPress.
For example, before adding the title of a post to browser output, WordPress first checks to see if any Plugin has registered a function for the “filter” hook called “the_title“. If yes, the title text is passed in turn through each registered function. The final result is what is printed. So, if your Plugin needs to add some info to the printed title, it may register a “the_title” filter function.
Another example is the “action” hook that’s called “wp_footer“. Right before the end of the HTML page WordPress is generating, it checks to see whether any Plugins have registered functions for the “wp_footer” action hook. Then it runs them in turn.
One more way for a WordPress Plugin to add functionality to WordPress
Creating custom Template Tags. Someone who needs to use your Plugin can add these “tags” to their theme, in the sidebar, post content section, or wherever it is appropriate. For example, a Plugin that adds geographical tags to posts might define a template tag function called geotag_list_states() for the sidebar. It lists all the states posts are tagged with, with links to the state-based archive pages the Plugin enables.
To define a custom template tag, you just have to write a PHP function and document it for Plugin users on your Plugin’s home page and/or in the Plugin’s main PHP file. It would be great to give an example of exactly what needs to be added to the theme file to use the function, including the <?php and ?> when documenting the function.
Most WordPress Plugins need to get some input from the site owner or blog users and save it between sessions. They need it to use in its filter functions, action functions, and template functions. This information must be saved in the WordPress database, in order to be persistent between sessions.
There are four ways for saving Plugin data in the database:
- You should use the WordPress “option” mechanism (described below). This method is good for storing relatively small amounts of relatively static, named pieces of data , the type of data you’d expect the site owner to enter when first setting up the Plugin, and rarely change thereafter.
- Post Meta (a.k.a. Custom Fields). Good for data associated with individual posts, pages, or attachments.
- Custom Taxonomy is for classifying posts or other objects like users and comments and/or for a user-editable name/value list of data consider, especially when you want to access all posts/objects associated with a given taxonomy term.
- Create a new, custom database table. This way is appropriate for data not associated with individual posts, pages, attachments, or comments, the type of data that will grow as time goes on, and which doesn’t have individual names.
WordPress has got a mechanism for saving, updating, and retrieving individual, named pieces of data (“options”) in the WordPress database. Option values may be strings, arrays, or PHP objects (they will be “serialized”, or converted to a string, before storage, and unserialized when retrieved). Option names are strings, and they must be unique, so that they don’t conflict with WordPress or other Plugins.
It’s also actually a good idea to minimize the number of options you use for your plugin. For instance, instead of storing 10 different named options consider storing a serialized array of 10 elements as a single named option.
Hope this article will help you in Programming your WordPress Plugin!