Introduction to WordPress Plugin Development

Writing a simple plugin
In the last two modules, I talked about why you might want to write a plugin for WordPress, and what things you need to think about before you get started. In this module, I'll show you how to actually start writing a plugin that does something. The first thing every plugin needs is the standardized plugin header. It looks like this. The only field that is absolutely required is the plugin name. That is if you were making a plugin for your own use you can skip everything else and just include the name. However, there are other fields that will provide more information on the plugins page. And several of the fields are required for the information to appear and for the plugin to be accepted into the WordPress. org repository. The fields that are used by the WordPress. org plugin page are author, version, plugin name, and author and plugin URI. Plugins hosted on WordPress. org automatically alert the users of the plugin when there are updates available. The update engine uses the plugin version from the plugin header to know if an updated version of the plugin is available. Therefore, it's important to have a consistent versioning system and stick to it, rather than changing to a completely different versioning system mid-stream. Some examples of commonly used versioning systems are the typical semantic versions <major>. <minor>. <bugfix> used by WordPress core, or date-based version. For example 13, 05, 22, used by Web Sharks authors of S two member and Quick Cash. For more information about file headers, plugin theme, and readme, check out the codex document on file headers.

Advanced plugin fundamentals
You now have all the tools you need to go forth, and start writing plugins. This module will build on that foundation, to add additional functionality and options for your plugins, as well as proper standards for validating data before saving it to the database, and sanitizing it before displaying it on the page to prevent against potential security issues. We'll start with the Settings API. The WordPress Settings API has been around for a long time since WordPress 2. 7. And it's built to make theme and plugin options easy to develop. The Settings API enables developers to build options pages with settings forms that are handled by built-in systems. Adding a new setting isn't hard. With register setting, you just define an option group, how the setting is stored in the database, a name of a setting to save, and an optional sanitization callback, which we'll cover later. An example setting could be register_settings, my_cool_settings, some_setting. You probably won't want to just run the register_setting function by itself, so you can hook it to an action, which will execute it when WordPress is dealing with other setup functions. So, your setting would actually look more like this. The admin_init action fires when the WordPress admin is being initialized, and is the recommended hook to use for registering settings. You can also unregister a setting with the unregister_setting, which will deregister settings that have been previously set. This is mostly used for deactivation or uninstallation hooks. More information about register_setting on the Settings API is available in the Codex.