WordPress Plugin Development Basics

WordPress plugin development

WordPress is by far one of the best content management systems, with a fantastic framework for customisation. The use of plugins, themes and multi-site options has made it very attractive. In this article, we will walk through the basics of developing plugins for WordPress. We will learn how to implement a single sign-on between WordPress and another Web application using cookies.

Plugins are used to add new features or services to the WordPress system — could be an easy way to customize the CMS further, add an enhancement, or whatever. Instead of changing the core programming of WordPress, you can add functionality with plugins.

Before developing a new plugin, the best practice is to first search the WordPress plugins repository to find if someone has already created a plugin for the facility you’d wish to enable using your plugin.

Creating a plugin

To create a well-structured WordPress plugin, you should follow certain steps, as given below.

Folder

The plugin should be stored in the wp-content/plugins/ directory, relative to the WordPress installation.

Plugin name

You should choose a unique name for your plugin. If you are planning to contribute it back to the community, you should verify that it does not conflict with any existing plugins.

Plugin files

The plugin may comprise one or more PHP scripts. The PHP script names should be unique, and should not conflict with the names of scripts used by other plugins. You may also logically split functions across multiple PHP scripts.

README file

The more you document, the more it benefits your users. You  should include a README file with explanations about the plugin.

Tip: You can log in as an administrator in /wp-admin/, and edit the plugin’s source code. You will be able to edit all files that are part of the plugin. You may not need shell or FTP access to modify and upload your plugin.

File headers

The plugin details should be specified in the header section, in a predefined format. The WordPress system extracts the plugin information from this section, and displays it to the users. For example:

<?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 
*/ 
?>

Plugin development

There are two ways to do plugin development:

  1. Using hooks
  2. Using templates

In this article, we will look at how to create plugins using hooks. There are two types of hooks:

  1. Actions
  2. Filters

Actions

The core WordPress system launches the Action hook at specific points during execution, or during specific events. The plugin can specify one or more PHP functions to execute, using the Action hook.

Filters

The core WordPress system launches the Filter hook to modify the text of various types before adding it to the database, or before sending it to the browser. The plugin can specify one or more PHP functions to modify specific types of text, using the Filter hook.

Options

The plugin data can be stored in a database, using the Options interface. The developer can design the plugin to capture configuration data from the administrator, and store the values in the database.

Single Sign-On plugin

The use-case for creating this plugin is to facilitate Single Sign-On (SSO) between a WordPress system and another Web application, which should store the user credentials in cookies, perhaps in an encrypted format. The user credentials could be the username, password and email address. The Web application should set the cookies when the user logs in to the system.

The WordPress plugin may use an authenticated filter hook to authenticate the user. This filter hook would read the encrypted user credentials from the cookie, decrypt the values, and authenticate the user using the WordPress API.

The plugin can be designed to create the account, automatically, if it does not already exist. The functions you could employ to authenticate the user, with the Authenticate filter hook, are as follows:

  1. wp_create_user()
  2. get_userdatabylogin()
  3. WP_User class

The cookie information, like the cookie name, domain, encryption algorithm and mode, can be configured using the Options interface. This information is stored in the database. The Options interface is accessible to site administrators.

Tip: The Web application and the WordPress system should share a common domain name. For example, if the Web application is installed at app.foo.com, the WordPress system should be installed at blog.foo.com. The cookies should be stored using the domain name, foo.com. Otherwise, cookies are not accessible between the two systems.

Once the SSO plugin is installed, users will not see the WordPress login screen. If they access any page that requires authentication, they will be automatically logged in, based on the values set in the cookies. If they are not logged in to the Web application, they will be redirected to the login page in the Web application.

Once logged in there, they will be redirected to the WordPress system, where they will be logged in automatically. If the account does not exist in the WordPress system, it will be created automatically.

Tip: To allow users to log in to the WordPress site, you should create a separate login page. This URL can be used to bypass the Single Sign-On system.

To know more about WordPress plugin development, you can refer to the plugin Development section in the developer documentation.

  • http://www.eluento.com/ The E-Luento

    Nice article. Just copied its content to my site

All published articles are released under Creative Commons Attribution-NonCommercial 3.0 Unported License, unless otherwise noted.
Open Source For You is powered by WordPress, which gladly sits on top of a CentOS-based LEMP stack.

Creative Commons License.