To help explain how this can be achieved, we will be creating a plugin called “Ajax Example“, stored in the folder “ajax-example” inside the plugin directory of your WordPress install.

Further information on creating a WordPress plugin can be found on WordPress.org and other resources, so won’t go into too much detail here.

First we need to create a file called “index.html” and copy the following into this file:

<?php
/*
Plugin Name: Ajax Example
Plugin URI: http://wp.me/pWbfz-dB
Description: Simple example of how to integrate front-end ajax requests via your plugin.
Version: 0.1
Date: 2011-09-01
Author: Steve Whiteley
Author URI: http://flav36rs.com
*/

class Ajax_Example
{
	public function __construct()
	{
		// ...
 	}
}

$ajaxExample = new Ajax_Example();

?>

We will be using the OOP structure for this plugin instead of the prefixed function format, however could be converted with ease. This class provides the skeleton structure of our plugin, you should save this file to our “ajax-example” folder before we start to add more functionality.

The next step is to include the JavaScript file that performs the AJAX request, which is called by the “init” action hook added to the class constructor method:

add_action( 'init', array( &$this, 'init' ) );

Then we add the init function to the plugin, which includes calls to insert the JavaScript file (wp_enqueue_script) and set the parameters required by the external file (wp_localize_script).

public function init()
{
	wp_enqueue_script( 'ajax-example', plugin_dir_url( __FILE__ ) . 'ajax.js', array( 'jquery' ) );
	wp_localize_script( 'ajax-example', 'AjaxExample', array(
		'ajaxurl' => admin_url( 'admin-ajax.php' ),
		'nonce' => wp_create_nonce( 'ajax-example-nonce' )
	) );
}

Additional parameters can be added to array if they are required, the two mentioned should be the minimum that are required.

While we’re here, we should add the function that handles the response generated by the AJAX request. Notice here that we check the nonce value that is defined in the function above and set the content type before returning the encoded JSON array.

public function ajax_call()
{
	if ( ! isset( $_REQUEST['nonce'] ) || ! wp_verify_nonce( $_REQUEST['nonce'], 'ajax-example-nonce' ) )
		die ( 'Invalid Nonce' );
	header( "Content-Type: application/json" );
	echo json_encode( array(
		'success' => true,
		'time' => time()
	) );
	exit;
}

Create “ajax-example/ajax.js” and copy the following snippet into this file. In order to perform the AJAX request, we use the jQuery .getJSON() method. Alternative methods could be used depending on the type of request you are performing.

jQuery.getJSON(
    AjaxExample.ajaxurl,
    {
        action: 'ajax-example',
        nonce: AjaxExample.nonce
    },
    function( response ) {
    	alert( response.success );
    }
);

Unfortunately this won’t actually do anything until we add two hooks to extend the built in AJAX functionality. These are added to the class constructor, the first (wp_ajax_nopriv_ajax-example) provides access for logged in users, the second (wp_ajax_ajax-example) for anonymous / non-logged in visitors.

if ( is_admin() ) {
	add_action( 'wp_ajax_nopriv_ajax-example', array( &$this, 'ajax_call' ) );
	add_action( 'wp_ajax_ajax-example', array( &$this, 'ajax_call' ) );
}

Please be aware that when using these hooks, they are called from within is_admin(), otherwise they are not correctly set.

The full contents of the plugin file “ajax-example/index.php” should be as follows:

<?php
/*
Plugin Name: Ajax Example
Plugin URI: http://wp.me/pWbfz-dB
Description: Simple example of how to integrate front-end ajax requests via your plugin.
Version: 0.1
Date: 2011-09-01
Author: Steve Whiteley
Author URI: http://flav36rs.com
*/

class Ajax_Example
{
	public function __construct()
	{
		if ( is_admin() ) {
			add_action( 'wp_ajax_nopriv_ajax-example', array( &$this, 'ajax_call' ) );
			add_action( 'wp_ajax_ajax-example', array( &$this, 'ajax_call' ) );
		}
		add_action( 'init', array( &$this, 'init' ) );
	}

	public function init()
	{
		wp_enqueue_script( 'ajax-example', plugin_dir_url( __FILE__ ) . 'ajax.js', array( 'jquery' ) );
		wp_localize_script( 'ajax-example', 'AjaxExample', array(
		    'ajaxurl' => admin_url( 'admin-ajax.php' ),
		    'nonce' => wp_create_nonce( 'ajax-example-nonce' )
		) );
	}

	public function ajax_call()
	{
		if ( ! isset( $_REQUEST['nonce'] ) || ! wp_verify_nonce( $_REQUEST['nonce'], 'ajax-example-nonce' ) )
			die ( 'Invalid Nonce' );
		header( "Content-Type: application/json" );
		echo json_encode( array(
			'success' => true,
			'time' => time()
		) );
		exit;
	}

}

$ajaxExample = new Ajax_Example();

?>

Other things to consider when using the example code provided above are that you should probably ensure jQuery is loaded and possibly only add the the scripts to the pages that they are required, rather than globally.

This functionality was tested with WordPress 3.2.1, it may however change and be simplified in future releases.

The option value is a serialized array of the active plugins saved in alphabetical order according to the plugin directory and file name, for example:

Array
(
	[0] => akismet/akismet.php
	[1] => example-plugin/index.php
)

You can however alter the order of the plugins in the array, which will in turn set the order in which the plugins are loaded by WordPress.

The first step towards adjusting the order is to add the following action to your plugin file, which is most likely to be /my-plugin/index.php or /my-plugin/my-plugin.php.

add_action( 'activated_plugin', 'my_plugin_load_first' );

Next you need to include the functionality to perform the actual re-ordering. The following function will fetch the existing list, check that your plugin is in the array and if so remove then append it to the beginning, before finally saving the altered list to the database.

function my_plugin_load_first()
{
	$path = str_replace( WP_PLUGIN_DIR . '/', '', __FILE__ );
	if ( $plugins = get_option( 'active_plugins' ) ) {
		if ( $key = array_search( $path, $plugins ) ) {
			array_splice( $plugins, $key, 1 );
			array_unshift( $plugins, $path );
			update_option( 'active_plugins', $plugins );
		}
	}
}

It should not be necessary for you to adjust anything specified here other than modifying the name of the function used to suit the namespace used by your plugin.

One final thing to consider is only adding this action when the dashboard or administration panels are being displayed, by making use of the is_admin() conditional tag.

Please note that modifying this option is not something I recommend people do unless absolutely necessary, and it my situation it proved to be very useful.

If you are not a plugin author intending to use this functionality within a plugin, you should place the following code examples into your theme’s functions.php file.

The first filter “manage_edit-comments_columns” is used to adjust the table headings by appending a column called “My Custom Column” to the end of the table headings.

function myplugin_comment_columns( $columns )
{
	$columns['my_custom_column'] = __( 'My Custom Column' );
	return $columns;
}
add_filter( 'manage_edit-comments_columns', 'myplugin_comment_columns' );

The second filter “manage_comments_custom_column” will populate each comment row with data. It checks that the column ID matches that set in the function above (“my_custom_column”) and outputs “Custom Data for ID:” followed by the comment ID  for each row.

function myplugin_comment_column( $column, $comment_ID )
{
	if ( 'my_custom_column' == $column ) {
		echo 'Custom Data for ID: ' . $comment_ID;
	}
}
add_filter( 'manage_comments_custom_column', 'myplugin_comment_column', 10, 2 );

Outputting this text isn’t really that useful to anyone, instead you will more likely want to show some actual data related to the comment. One thing you may want to do is adjust the function to display some meta data stored for the comment.

function myplugin_comment_column( $column, $comment_ID )
{
	if ( 'my_custom_column' == $column ) {
		if ( $meta = get_comment_meta( $comment_ID, $column , true ) ) {
			echo $meta;
		}
	}
}

The above snippet assumes that meta key is the same as the column ID (“my_custom_column”) and you only want to add a single column, but what if you want to add multiple columns and show different data?

function myplugin_comment_columns( $columns )
{
	return array_merge( $columns, array(
		'custom_column_one' => __( 'Custom Column One' ),
		'custom_column_two' => __( 'Custom Column Two' ),
		'custom_column_three' => __( 'Custom Column Three' )
	) );
}
add_filter( 'manage_edit-comments_columns', 'myplugin_comment_columns' );

function myplugin_comment_column( $column, $comment_ID )
{
	switch ( $column ) {
		case 'custom_column_one':
		case 'custom_column_two':
			if ( $meta = get_comment_meta( $comment_ID, $column , true ) ) {
				echo $meta;
			} else {
				echo '-';
			}
		break;
		case 'custom_column_three':
			echo 'Third Column Data';
		break;
	}
}
add_filter( 'manage_comments_custom_column', 'myplugin_comment_column', 10, 2 );

The above will add three columns to the edit page, the first two will try to lookup comment meta data and the third output the text “Third Column Data” for the sake of this example.

Similar function and filter combinations can be used for adding columns to the other admin pages. Just adjust the filters used by replacing {type} with either ‘posts‘ or ‘pages‘ in the filters below, however we will not go into further detail here.

• manage_{type}_columns
• manage_{type}_custom_column

Please note that the above functions have only been tested using WordPress 3.2.1 and cannot guarantee they will work correctly or the same in older versions.

The problem with using the ID class to identify an individual page is that a page ID can quite easily change when working with a development version or even migrating your blog from one install to another.

One solution to this problem is to append the post type and slug as a class name to the body, e.g. ‘page-about‘ or ‘post-hello-world‘.

Simply add the following to your functions.php file to automatically append the classes:

function add_body_class( $classes )
{
    global $post;
    if ( isset( $post ) ) {
        $classes[] = $post->post_type . '-' . $post->post_name;
    }
    return $classes;
}
add_filter( 'body_class', 'add_body_class' );

Note: This method will also apply to individual post pages and custom post types.

When the issue of removing the Admin Bar first cropped up, the solution was to remove the associated init action, however this is not the correct method of disabling it and should not be used.

remove_action('init', 'wp_admin_bar_init');

Instead, you either use the show_admin_bar filter and simply return false:

function hide_admin_bar() {
    return false;
}
add_filter( 'show_admin_bar', 'hide_admin_bar' );

Or alternatively call the show_admin_bar function directly:

show_admin_bar( false );

If you are disabling the bar from within an init action it is important that you correctly pass the priority value, otherwise some of the assets may remain (such as the JavaScript file) and cause unwanted behaviour.

Using a priority of 9 seemed to be be the most successful from my experiments, although other possibilities may be used:

add_action( 'init', 'my_init_function', 9 );

There are a number of comments in the source code of 3.1, discouraging you from using the previous method of removing the wp_admin_bar_init action, so encourage anyone to update the method they are using.

All of the methods mentioned here can be used in either your plugin file or functions.php file.

If you need to add additional class names to the defaults without having to manually add them every time you insert a new image, you can make use of either the get_image_tag_class or get_image_tag filters.

The first of the two filters is get_image_tag_class, which allows you to add a value or change the class attribute completely:

function add_image_class($class){
	$class .= ' additional-class';
	return $class;
}
add_filter('get_image_tag_class','add_image_class');

The second function is a little more flexible and provides the ability to alter the image tag completely, thus providing functionality to add the image dimensions to the class names as shown in this example:

function add_image_class_dimensions($html, $id, $alt, $title)
{
	if (preg_match('/width="(d+)" height="(d+)"/', $html, $dimensions)) {
		list(,$width, $height) = $dimensions;
		$html = str_replace(
			'class="',
			'class="wp-image-width-'.$width.' wp-image-height-'.$height.' ',
			$html
		);
	}
	return $html;
}
add_filter('get_image_tag', 'add_image_class_dimensions', 10, 4);

In brief, this function matches the dimensions found within the image tag (width and height) and appends them to the front of the class attribute.

Applying both of these filters will output something similar the following code in the TinyMCE editor:

<img class="wp-image-width-200 wp-image-height-100 alignnone size-full wp-image-123" title="Image Title Here" src="/wp-content/uploads/2010/12/my-image.jpg" alt="" width="200" height="100" />

To make use of this functionality you will first need to add the filter and function to your theme’s function.php file. Once this is done, add a new image to your post or page and you will see the custom class names are appended to the image tag. They will not be applied to any existing images within your content, you will have to insert them again from the media library for the changes to be applied.

These are only two examples of what results can be achieved, further adjustments and alterations can be easily added using the two get_image_tag filters.

One way this can be achieved, without resorting to custom page meta inputs, is to simply enable support for excerpts on pages.

The excerpt content section that is visible on the post edit screen will then be displayed on the standard page content editing screen.

This can be achieved very quickly and easily by including the following lines in the theme functions.php file:

    // Enable excerpts for pages...
add_action('init', 'enable_page_excerpts');
function enable_page_excerpts()
{
    add_post_type_support('page', 'excerpt');
}

There are a few downsides to using this method, so it is advised that you use with caution.

To prevent this happening but leave the auto conversion of double line-breaks into paragraph tags, I had a dig into the wpautop function that runs before the content is outputted to the screen.

This function accepts two parameters, the first is the content to be formatted and the second determines whether to convert remaining line breaks into <br /> tags.

Because the wpautop filter is automatically applied to the content, we first need to remove that by adding the following to our functions.php file:

remove_filter('the_content', 'wpautop');

Then we must apply the formatting function again but this time set the the second parameter to false and prevent the additional <br /> tags appearing.

function wpautopnobr($content) {
	return wpautop($content, false);
}
add_filter('the_content', 'wpautopnobr');

This can be customised further by checking to see if we are on a page rather than a post and only applying the formatting if that is the case. The required code in it’s entirety is as follows:

remove_filter('the_content', 'wpautop');
function wpautopnobr($content) {
	return wpautop($content, (is_page() ? true : false));
}
add_filter('the_content', 'wpautopnobr');

Although it’s advised you avoid creating tables unless absolutely necessary, it seemed like the correct method to store the data used by this particular plugin.

This method of storage does have it’s downsides, especially when it comes to modifying the table structure. Luckily the dbDelta function comes in really handy in aiding the update process.

There is however one issue that I came across, discovering that is unable to modify a unique key (in this situation a composite index).

After browsing through the source code for the dbDelta function I spotted that something was missing. When including an index in the query, it is not dropped before attempting to recreate it and is therefore ignored when performing an update.

Take for example the following code snippet:

global $wpdb;
$table = $wpdb-prefix.'mytable';
$sql = "CREATE TABLE $table (
	id mediumint(9) NOT NULL AUTO_INCREMENT,
	calendar varchar(255) NOT NULL default 'default',
	year smallint(5) NOT NULL,
	month tinyint(3) NOT NULL,
	day tinyint(3) NOT NULL,
	PRIMARY KEY (id),
	UNIQUE KEY date (year,month,day)
);";
require_once(ABSPATH.'wp-admin/includes/upgrade.php');
dbDelta($sql);

If we make some changes to the SQL statement to add an additional column to the unique index, the index would become something like “UNIQUE KEY date (year,month,day,calendar)“.

This will work if the the table does not already exist, but if it attempts to update the table then the changes to the unique key are ignored.

The short and simple solution is to simply check the table exists and then drop the index manually before calling the dbDelta function.

if ($wpdb->get_var("SHOW TABLES LIKE $table") == $table) {
	$wpdb->query("ALTER TABLE $table DROP INDEX date");
}

I’m not sure if this is actually a bug with the function or whether it wasn’t supposed to allow for updates on indexes in the first place, either way the problem can be quite easily resolved.

The plugin stores a custom post meta entry for any post or page that requires a subtitle, in order to append this field to the search query I required the use of two actions.

• posts_where_request
• posts_join_request

Each of my plugins use a class based format, so the following examples will be provided in that format. This could quite easily be changed to regular functions

The first action is called when the class is instantiated:

class MyPlugin {
	function MyPlugin()
	{
		add_action('posts_where_request', array(&$this, 'search'));
	}
}

The first argument passed to this action is a string containing the where clause for the search query.

When the action is called we have also reached a point where we can check whether we are carrying out a blog search “is_search()“.

function search($where)
{
	if (is_search()) {
		global $wpdb, $wp;
		$where = preg_replace(
			"/(wp_posts.post_title (LIKE '%{$wp->query_vars['s']}%'))/i",
			"$0 OR ($wpdb->postmeta.meta_key = '_mymetakey' AND $wpdb->postmeta.meta_value $1)",
			$where
		);
		add_filter('posts_join_request', array(&$this, 'search_join'));
	}
	return $where;
}

All that we do here is include the meta key search by finding the post_title clause and inserting the meta key clause after it, using the preg_replace() function.

(Note: I have used the meta key “_mymetakey”, you will need to replace this with the key matching your custom meta data.)

The where condition is now in place, but we will need to add on the post_meta table, making use of the second action “posts_join_request” included in the function above.

function search_join($join)
{
	global $wpdb;
	return $join .= " LEFT JOIN $wpdb->postmeta ON ($wpdb->posts.ID = $wpdb->postmeta.post_id) ";
}

Putting all the basic functionality together you will have something along the lines of this:

class MyPlugin {
	function MyPlugin()
	{
		add_action('posts_where_request', array(&$this, 'search'));
	}
	function search($where)
	{
		if (is_search()) {
			global $wpdb, $wp;
			$where = preg_replace(
				"/(wp_posts.post_title (LIKE '%{$wp->query_vars['s']}%'))/i",
				"$0 OR ($wpdb->postmeta.meta_key = '_{$this->tag}' AND $wpdb->postmeta.meta_value $1)",
				$where
			);
			add_filter('posts_join_request', array(&$this, 'search_join'));
		}
		return $where;
	}
	function search_join($join)
	{
		global $wpdb;
		return $join .= " LEFT JOIN $wpdb->postmeta ON ($wpdb->posts.ID = $wpdb->postmeta.post_id) ";
	}
}

There are however a few possible pitfalls that I have yet to address, the main one being that the meta_value field is not indexed.

I’m not sure whether to try and automatically add an index to the field or add an additional option on my plugin settings page to create the index.