Writing Your Own Plugin

With an understanding of the concept of hooks, it’s time to get your feet wet by writing your own plugin. Doing this is fun and can open up a whole new world of possibilities.

There is a sizable plugin repository already at http://wordpress.org/extend/plugins/, but sometimes you may have to write your own to accomplish a task no one else has or to do it better. Whether you write the plugin for your own use or release it to the world, you are sure to begin to understand the plugin building process better the more you do it.

Every plugin requires a set of headers for use in the plugin. You should try to come up with a unique name for the plugin. WordPress reads these headers and uses them in a variety of ways, including displaying them inside the WordPress administration panel (referred to as the WordPress Admin) and determining whether there are upgrades available for the plugin.

In this text, I walk through the steps to build a plugin that adds copyright text throughout a blog. To do this, you must first create a new folder inside of WordPress’ wp-content/plugins/ folder that you’ll call copyright-notices and then create a new file inside that folder called copyright-notices.php. The headers for this plugin might look like the code shown below:

The headers are self-descriptive but it is important to note that only a plugin name is absolutely required. WordPress parses this data out for use in the WordPress Admin.

All plugin files are created with the PHP scripting language. Though PHP files can have HTML in them, unless otherwise specified, every file must begin with the PHP opening tag

You can optionally add a closing

at the end of the file, but if you do, ensure there is no extra whitespace or your blog will break.

Extending the WordPress Admin

Development of administrative interfaces for a plugin is often where plugin development begins. Conscientious plugin developers provide some sort of interface for managing their plugin without having to resort to asking the end user to go in and edit a file.

However, taking this kind of approach to plugin development ensures problems later on when the plugin is upgraded, because any modifications made to the plugin will be overwritten. It’s much better practice to actually store setting data in the database and avoid hard coding it in the plugin itself.

Aside from the upgrade complications involved in not having a WordPress Admin page, there is also a usability question. Most WordPress users are non-technical users.

They don’t know what to do with PHP or object-oriented programming. They don’t know what a curly brace means or why semicolons are important. Making them dive into the code to configure the plugin is a recipe for making sure the plugin doesn’t have a high adoption rate.

Fortunately, WordPress offers a large number of hooks and functions inside the WordPress Admin that assist in creating new administrative plugins.