This can be useful for a hacker to get the username right. A good idea is to display a generic message as given below.

You can easily achieve that by adding the following line to your themes ‘functions.php’ file.

add_filter('login_errors',
            create_function('$no_login_error', 
                            "return 'Oops! Wrong Credentials.';"));

The second argument to the ‘add_filter’ creates a anonymous callback function. This is equivalent to the following.

function no_login_error() {
    return 'Oops! Wrong Credentials.';
}
 
add_filter('login_errors','no_login_error');

WordPress File Monitor
WFM monitors your WordPress installation for any added, deleted or changed files. When a change is detected an email is sent to a specified address. Currently does not support multi-site installations.

Ultimate Security Checker
Ultimate Security Checker helps you identify security problems with your WordPress installation. It scans your WordPress blog for hundreds of known threats, then gives you a security “grade” based on how well you have protected yourself.

For example you could have a ‘donate’ button on a sidebar that displays only if the user is browsing from France. Or you could hide a particular paragraph in a post for users from a particular country. This can be used by marketing people to deliver targeted content to audiences.

Developers and designers could also use the plugin to load different stylesheets based on the users country. Services like hulu.com uses techniques such as this to constrain viewership to a particular country.

You can buy the plugin from here.

Take the popular WP-Super-Cache plugin. I frequently make changes to my blog from a FTP client, and every time I’ve to login to the WordPress admin and clear the cache so that I can see the latest changes reflected. At times this can be tiring. It would be nice if one could have a desktop app that interfaces with the remote WP-Super-Cache instance. This is exactly what we will do in the current post.

RPC interface plugin

WordPress provides the XML_RPC interface to remotely post content to your blog. By default this interface is disabled for security reasons. But it can be a wonderful way to communicate with your WordPress plugins. WordPress has an extensive set of actions and filters which allow you add/change/remove low level features via plugins and themes. Using this technique plugins can expose new XML-RPC methods for your WordPress blog. A skeleton code to do the same is given below.

add_filter('xmlrpc_methods', 'my_xmlrpc_methods');
 
function my_xmlrpc_methods($methods) {
	$methods['new_rpc_method'] = 'my_method';
	return $methods;
}
 
function my_method($args)
{
   // Do all your custom programming here
}

The following is a short plugin that exposes a few of the WP-Super-Cache functions to the outside world as an RPC interface. This enables you to control a few WP-Super-Cache functions like disabling cache, enabling cache, clearing cache and checking cache status from another program. This program can be a desktop Adobe AIR application, a JavaScript plugin or another PHP application. The code for the complete plugin is shown below.

To make this all work you will first have to activate the XML-RPC interface for your WordPress blog. You can activate the same from the admin > settings > writing > Remote Publishing section. The XML_RPC interface is controlled by your ‘xmlrpc.php’ file on your server.

<?php
 
/*
Plugin Name: Wp SuperCache API
Plugin URI: http://www.codediesel.com
Description: Expose a few Wp-SuperCache function for RPC
Version: 0.8
Author: Sameer Borate
Author URI: http://www.codediesel.com
*/
 
/* Add your custom RPC method to the Wordpress RPC methods list */
add_filter('xmlrpc_methods', 'my_xmlrpc_methods');
 
function my_xmlrpc_methods($methods) {
	$methods['wpSuperCacheRPC'] = 'my_cacheStatus';
	return $methods;
}
 
function my_cacheStatus($args)
{
    // Parse the arguments, take note that they're in the correct order
    $username	= $args[0];
    $password	= $args[1];
    $action	= $args[2];
 
    global $wp_xmlrpc_server;
 
    // Let's run a check to see if credentials are okay
    if (!$wp_xmlrpc_server->login($username, $password)) {
        return -1;
    }
 
    if(function_exists('wp_cache_is_enabled')) {
        global $cache_path;
 
        switch($action) {
            case "cache_status"  : return wp_cache_is_enabled(); 
                                   break;
            case "cache_enable"  : wp_cache_enable(); 
                                   break;
            case "cache_disable" : wp_cache_disable(); 
                                   break;
            case "cache_clear"   : prune_super_cache($cache_path, true); 
        }
    }
}
 
?>

Note that the functions I’ve used in the plugin: wp_cache_is_enabled(), wp_cache_enable(), wp_cache_disable(), prune_super_cache() are defined in the WP-Super-Cache plugin to accomplish their respective tasks.

RPC interface client

A sample PHP RPC client to work with the above code is shown below. Here we request the ‘cache_status’ function from the remote server.

<?php
 
/* XML_RPC Client to access the above plugin functions */
 
function wpSuperCacheRequest($rpc_url,$username,$password, $action)
{
    $params = array($username,$password,$action);
    $request = xmlrpc_encode_request('wpSuperCacheRPC',$params);
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_POSTFIELDS, $request);
    curl_setopt($ch, CURLOPT_URL, $rpc_url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_TIMEOUT, 10);
    $data = curl_exec($ch);
    curl_close($ch);
    return $data;
}
 
$rpc_server = "http://your-wordpress-site.com/xmlrpc.php";
 
/* Return '0' if cache is disabled or  '1' if enabled */
$action = 'cache_status';
 
/**
  * Action can be any of the following :
  *
  * cache_status
  * cache_enable
  * cache_disable
  * cache_clear
  */
 
/* 'USER', 'PASSWORD' is your WordPress admin credentials */
$data = wpSuperCacheRequest($rpc_server,'USER','PASSWORD', $action);
echo $data ;
 
?>

If you have never used a XML_RPC code on your machine you could get the following error after you run the above client program.

Fatal error: Call to undefined function xmlrpc_encode_request()

To rectify just enable the following line in your php.ini (on Windows).

extension=php_xmlrpc.dll

Testing the interface

Now when you run the above client program, it will connect with the remote WordPress site with the help of the plugin and control the wp-super-cache functionality.

When you use the ‘cache_clear’ function in the above client program and you want to check if the cache is actually cleared on the web server, make sure that you click on the Regenerate cache stats link in the wp-super-cache admin section to refresh the status. Not doing so will probably show you the old data and you may wonder why the code is not working.

But I’ve doubts whether this will be useful with pagination that just shows ‘next page’ and ‘previous page’ links. Still I think it is worth looking into. To see the concept in action you can check the pagination links on the current blogs home page. The present iteration just displays the post titles; adding click-able links to the displayed post titles will be another good idea (currently implemented removed, but still in testing phase).

Creating the concept

For building the preview I used the wp-paginate WordPress plugin and modified a couple of functions to extract the post titles. The preview tool-tip uses the excellent jQuery qTip2 plugin to display the post titles on hovering over the pagination links.

Although this looks like extra investment in time for a small return; in my opinion it somewhat increases the usability for the user.

The plugin just doesn’t glue together RSS feeds, or use a proxy server to modify your site’s look— It creates a full-fledged theme, completely separate from your desktop theme that offers most of WordPress’ native features, & works with other plugins, too.

The plugin requires WordPress 3.1 or higher.

Disclaimer: The above link to WPtouch Pro is a affiliate sponsorship.

Logging WordPress SQL queries

By default WordPress doesn’t log any queries. But you can instruct WordPress to do so by adding the following configuration option to your WordPress ‘wpconfig.php’ file.

/* wp-config.php */
 
define('SAVEQUERIES', true);

Once that is done you can add the following lines at the end of your WordPress themes ‘footer.php’ file.

/* footer.php */
..
global $wpdb;
print_r($wpdb->queries);
.
.

This will display the SQL statements executed by your WordPress installation in a raw format as shown below. It displays a total of three items – the executed query, the execution time of the query and the function that called the query.

Array
(
    [0] => Array
        (
            [0] => SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
            [1] => 0.004619836807251
            [2] => require, require_once, require_once, require_once, is_blog_installed, wp_load_alloptions
        )
 
    [1] => Array
        (
            [0] => SELECT option_value FROM wp_options WHERE option_name = 'sidebars_widgets' LIMIT 1
            [1] => 0.0015749931335449
            [2] => require, require_once, require_once, require_once, do_action, call_user_func_array, wp_widgets_init, register_widget, WP_Widget_Factory->register, WP_Widget_Recent_Comments->WP_Widget_Recent_Comments, is_active_widget, wp_get_sidebars_widgets, get_option
        )
.
.

As you can see the raw information is not interesting to look at and it also clutters the actual site. A better way is to use FireBug and FirePHP to log the SQL queries without interfering with the WordPress output.

Installing FirePHP

Before starting you need to have FirePHP and FireBug installed. FirePHP uses FireBugs console window to output the debug messages. Once you have installed FirePHP and FireBug, you need to install the FirePHP server libraries. Copy the FirePHP server libraries to your WordPress themes directory. For e.g ‘wordpress\wp-content\themes\default\FirePHPCore’.

If you are unfamiliar with FirePHP a nice tutorial can be found at Six Revisions.

Displaying formatted information with FirePHP

Once we are done with the above setup, you can add the following code at the end of your WordPress themes ‘footer.php’ file, replacing the code we previously added.

<?php
 
    /* footer.php */
 
    require_once("FirePHPCore/FirePHP.class.PHP");
 
    global $wpdb;
 
    $query_table[] = array("SQL", "Execution Time", "Calling Function");
    $expensive_query_time = 0;
    $expensive_query = "";
    $total_time = 0;
 
    foreach($wpdb->queries as $query)
    {
        $query_table[] = array($query[0], $query[1], $query[2]);
        /* Get the most expensive query */
        if($query[1] > $expensive_query_time)
        {
            $expensive_query_time = $query[1];
            $expensive_query = $query[0];
            $total_time += $query[1];
        }
    }
 
    $total_queries = count($wpdb->queries);
    $firephp = FirePHP::getInstance(true);
 
    /* Display the queries in a formatted table */
    $firephp->group('Query', array( 'Collapsed' => false,  
                                    'Color' => '#000'));
    $firephp->table($total_queries . " queries took " . 
                    $total_time . " seconds.", $query_table);
 
    /* Display the query summary */
    $firephp->group('Query Summary', array( 'Collapsed' => false,  
                                            'Color' => '#000'));
    $firephp->log($total_queries, 'Total Queries');
    $firephp->log($expensive_query, 'Expensive Query');
    $firephp->log($expensive_query_time, 'Expensive Query Time');
 
?>
</body>
</html>

Refresh your WordPress page and you should see the following output in the FireBug console. Click on the image below to view the complete debug screen. (Some queries have been removed for size.) As you can see FirePHP displays a nicely formatted output than the previous one.

Modifying the query data returned by WordPress

WordPress by default saves and returns the following three parameters for each SQL query:
1. SQL query
2. Query Execution time
3. The method chain that called the query.

The code section where this happens is located in the query() method of the ‘wp-db.php’ file in the WordPress ‘wp-includes’ directory. The following snippet shows that section of code:

/* wp-db.php */
.
.
// Log how the function was called
$this->func_call = "\$db->query(\"$query\")";
 
// Keep track of the last query for debug..
$this->last_query = $query;
 
// Perform the query via std mysql_query function..
if ( defined('SAVEQUERIES') && SAVEQUERIES )
    $this->timer_start();
 
$this->result = @mysql_query($query, $this->dbh);
++$this->num_queries;
 
if ( defined('SAVEQUERIES') && SAVEQUERIES )
    $this->queries[] = array( $query, $this->timer_stop(), 
                              $this->get_caller() );
 
.
.

You can modify the code to add some extra parameters as per your requirements, or modify the format in which it is returned. For example you could add code to save the data to a xml or csv file for latter retrieval and analysis.

Note: Turning on the define(‘SAVEQUERIES’, true) option can slow down your WordPress site, so make sure you disable it after your work is done.