The custom update checker integrates closely with the upgrade system already built into WordPress, producing a seamless user experience. Observe :

An upgrade notice for a privately hosted plugin.

The 'Plugin Information' window with placeholder data.

(Excuse my marketing-speak. It’s a thing. On with the practicalities of the matter.)

Download

• Client library (requires PHP5 and WP 2.8 or later)
• Example plugin
• Example metadata file

Quick-start Guide

This section describes the quickest way to get automatic updates working for your plugin. Here’s what you’ll need to do: create a metadata file for your plugin, host it somewhere publicly accessible, and tell the update checker where to find it.

Lets start with the metadata. Copy the JSON code below into a new file and replace the placeholder values with your plugin’s info.

{
    "name" : "My Cool Plugin",
    "slug" : "my-cool-plugin",
    "download_url" : "http://example.com/plugins/my-cool-plugin.zip",
    "version" : "2.0",
    "author" : "John Smith",
    "sections" : {
        "description" : "Plugin description here. Basic HTML allowed."
    }
}

(This is the minimal amount data required to make automatic updates work. In most cases, you will probably want to add a couple more fields. See the metadata docs below for details.)

Most of the fields should be pretty self-explanatory, with one possible exception – the “slug”. WordPress expects all plugins that support automatic updates to have a unique textual identifier called the “slug”. Normally, slugs are assigned by the official plugin directory. For a private/commercial plugin that’s hosted elsewhere you’ll have to make something up. If unsure, just use the plugin’s file name without the “.php” extension (my-cool-plugin/my-cool-plugin.php becomes my-cool-plugin).

Upload the metadata file you just created to your web server. It doesn’t matter where exactly you put the file or how you name it. The important thing is for its URL to be accessible from wherever someone might install your plugin.

Next, copy the “update-checker” directory from the client library archive to your plugin’s directory. Then fire up your favourite code editor and add the following lines to the top of your plugin file:

require 'plugin-updates/plugin-update-checker.php';
$MyUpdateChecker = new PluginUpdateChecker(
    'http://example.com/path/to/metadata.json',
    __FILE__,
    'your-chosen-slug'
);

(If you followed my advice and used the plugin’s file name as the slug, you can omit the third parameter of the PluginUpdateChecker constructor.)

And that, believe it or not, is it.

The PluginUpdateChecker class will handle the rest. It’ll check the metadata file every 12 hours and, if it discovers that a new version has been released, twiddle the right bits in the undocumented WP API to make it show up as a standard upgrade notification in the “Plugins” tab. Assuming you’ve set up the download_url correctly, users will be able to install the update with a single click.

The rest of this post will be devoted to a more in-depth discussion of the update checker class and the metadata format.

The PluginUpdateChecker class

This class is the core of the update checker. It’s also the only part of the updater that you should need to deal with unless you decide to  extend the library yourself.

Class constructor

All configuration settings should be specified by passing them to the PluginUpdateChecker constructor. It takes the following parameters :

• $metadataUrl – The full URL of the plugin’s metadata file.
• $pluginFile – The fully qualified path to the plugin file. In most cases you can simply use the __FILE__ constant here.
• $slug – The plugin’s ‘slug’. If not specified, the filename part of $pluginFile (sans “.php”) will be used as the slug.
• $checkPeriod – How often to check for updates (in hours). Defaults to checking every 12 hours. Set to zero to disable automatic update checks.
• $optionName – Where to store book-keeping info about updates. Defaults to “external_updates-$slug”.

checkForUpdates()

Manually trigger an update check. This is especially useful when you’ve disabled automatic checks by setting $checkPeriod (above) to zero. This method takes no parameters and returns nothing.

addQueryArgFilter($callback)

Register a callback for filtering query arguments. Whenever the update checker needs to retrieve the metadata file, it will first run each filter callback and attach the query arguments that they return to the metadata URL. This lets you pass arbitrary data to the server hosting the metadata. For example, commercial plugins could use it to implement some kind of authorization scheme where only users that have the right “key” get automatic updates.

The callback function will be passed an associative array of query arguments and should return a modified array. By default, the update checker will add these arguments to the metadata URL:

• installed_version – set to the currently installed version of the plugin.
• checking_for_updates – set to 1 if checking for updates, absent otherwise (i.e. when loading data for the “Plugin Information” box).

This method takes one parameter – the callback function.

addHttpRequestArgFilter($callback)

Register a callback for filtering the various options passed to the built-in helper function wp_remote_get that the update checker uses to periodically download plugin metadata. The callback function should take one argument – an associative array of arguments – and return a modified array or arguments. See the WP documentation on wp_remote_get for details about what arguments are available and how they work.

This method takes one parameter – the callback function.

addResultFilter($callback)

Register a callback for filtering plugin info retrieved from the metadata URL.

The callback function should take two arguments. If the metadata was retrieved successfully, the first argument passed will be an instance of PluginInfo (see the source for a description of this class). Otherwise, it will be NULL. The second argument will be the corresponding return value of wp_remote_get (see WP docs for details). The callback function should return a new or modified instance of PluginInfo or NULL.

This method takes one parameter – the callback function.

Metadata format

The automatic update system uses a JSON-based file format to describe plugins.  Essentially, the entire file is one big JSON-encoded object (AKA hash-table or associative array). Each field – or array key – represents a piece of information about the latest version of the plugin. The full description of all available fields is here.

For the sake of simplicity, both general metadata and update-related information are stored in the same file. If this is undesirable, you can replace the plain JSON file with a script that checks for the presence of the the “checking_for_updates” query parameter and emits just the update-related fields if its set to “1″.

What Went Wrong?

A quick check of the server’s error_log revealed the problem: the plugin was running out of memory.

[19-Aug-2010 15:47:44] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 11145167 bytes) in /home/foo/public_html/wp-content/plugins/wp-dbmanager/wp-dbmanager.php on line 101
[20-Aug-2010 15:47:49] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 10929395 bytes) in /home/foo/public_html/wp-content/plugins/wp-dbmanager/wp-dbmanager.php on line 101
[21-Aug-2010 15:47:38] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 10693507 bytes) in /home/foo/public_html/wp-content/plugins/wp-dbmanager/wp-dbmanager.php on line 101

Alas, this was not all that surprising. Due to the way the mail() function works in PHP, WP-DBManager must read the entire backup file into memory before emailing it. Since the database gets bigger and bigger with each new post and comment, it will one day inevitably exceed the maximum amount of memory that PHP scripts are allowed to use and thus crash the plugin.

There are many ways to fix this problem, but most of them will only buy you some time. Increasing PHP memory limit will work in the short-term, but eventually the WP database will grow large enough to exceed the new limit. Similarly, cleaning up the DB – e.g. by removing old post revisions – can make it small enough that the backup file fits in the available memory. But that, too, is only a temporary solution.

The Fix

Ideally, the plugin shouldn’t even need to read the entire file into memory. It’s just the “convenient” design of the built-in mail() function that demands this. To solve the “allowed memory size of XXX bytes exhausted” problem once and for all, we need to replace mail() with something more flexible.

So, after an hour or two of hacking, I managed to rig WP-DBManager to use the free Swift Mailer library instead. Among the library’s many features is the ability to send file attachments of virtually any size without worrying about memory limits. Thus enhanced, the plugin should be able to handle large backups without a hitch.

You can download the fixed version below. I’ve successfully installed it on my site and the periodic backup emails are rolling in again (yay!). Note, however, that due to the inclusion of the Swift Mailer library the plugin now requires PHP 5.2 or later. Make sure your server has that before trying to install the modified version.

wp-dbmanager-modified.zip (190 KB)

The next major release of the Broken Link Checker plugin is nearing completion. Some of the highest voted ideas have been implemented, the user interface has been re-worked and many bugs have been fixed. Interested? Play with the alpha version, check out new features before anyone else, submit last-minute feedback. I’m especially interested in your thoughts about the new interface – layout, colours, wording.

What’s New

Implemented and available right now :

• Individually pick the types of content to check for links.
• Check drafts, scheduled and private posts.
• Colour-coded “Status” column in the link table.
• Show/hide columns selectively.
• “Compact” table view – each row becomes exactly two lines, no text wrapping. Slick.
• Select how many links per page to display.
• New URL editor.
• Tabbed interface for the settings page.

Implemented, but not yet public. Probably reserved for a “Pro” version :

• Check embedded YouTube, DailyMotion and Vimeo videos.
• Specialized checker algorithms for RapidShare, Mediafire and MegaUpload links.
• Custom post type support.
• Check plaintext URLs.

Screenshots

The new “Broken Links” page (click to enlarge) :

The new settings page :

Thoughts?

But first, here are a few screenshots – to whet your appetite, so to speak.

Want those neat buttons in your plugin? Read on.

Hackety-Hack

The area that holds the “Screen Options” and “Help” links is internally known as “screen meta links”. There is no official API for adding new links to this area. Fortunately, the DOM structure that represents the buttons is relatively simple, so we can attach an extra button with just a few lines of JavaScript.

<script type="text/javascript">
(function($){
	$('#screen-meta-links').append(
		'<div id="my-screen-meta-link-wrap" class="hide-if-no-js screen-meta-toggle">' +
			'<a href="http://example.com/" id="my-screen-meta-link" class="show-settings">Foo</a>' +
		'</div>'
	);
})(jQuery);
</script>

You’ll also need to add some extra CSS to the page to make the new button show up correctly :

<style type="text/css">
#my-screen-meta-link-wrap {
	float: right;
	height: 22px;
	padding: 0;
	margin: 0 6px 0 0;
	font-family: "Lucida Grande", Verdana, Arial, "Bitstream Vera Sans", sans-serif;
	background: #e3e3e3;
 
	border-bottom-left-radius: 3px;
	border-bottom-right-radius: 3px;
	-moz-border-radius-bottomleft: 3px;
	-moz-border-radius-bottomright: 3px;
	-webkit-border-bottom-left-radius: 3px;
	-webkit-border-bottom-right-radius: 3px;
}
 
#my-screen-meta-link-wrap a.show-settings {
	background-image: none;
	padding:0 6px 0 6px;
}
</style>

These style will make your button look just like the default ones – light-grey background and dark-grey text. You can easily modify the CSS to change your button’s appearance. For example, the green “Upgrade” link pictured in one of the above screenshots has the equivalent of these extra styles applied :

#my-screen-meta-link-wrap {
	background-color: #00C31F; 
}
#my-screen-meta-link-wrap a.show-settings {
	font-weight: bold;
	color: #DEFFD8;
	text-shadow: none;
}
#my-screen-meta-link-wrap a.show-settings:hover {
	color: white;
}

No API? Make one.

Even such a simple hack can get cumbersome if you need to use it more than once or twice. After using it in several plugins, I went ahead and wrote a wrapper script that hides all the JS/CSS machinations behind a simple PHP interface. Here’s an example plugin that employs my custom API :

<?php
/*
Plugin Name: Screen Meta Links Demo
Plugin URI: http://w-shadow.com/
Description: Demonstrates how to add new links alongside the "Screen Options" and "Help" links on Dashboard pages.
Version: 1.0
Author: Janis Elsts
Author URI: http://w-shadow.com/blog/
*/
 
//Load the custom button API
include 'screen-meta-links.php';
 
//Simple example. Adds a screen meta link to example.com 
//to the main Dashboard page.
add_screen_meta_link(
	'meta-link-example2',  //Link ID. Should be unique.  
	'Example Link',        //Link text.
	'http://example.com/', //URL
	'index.php'            //Where to show the link. 
);
 
//Advanced example. Demonstrates how to add one link to 
//several different pages and how to set link attributes.
add_screen_meta_link(
	'meta-link-example2', 
	'Advanced Link', 
	'http://example.com/', 
	//An array of page/screen IDs specifying where to display the link. 
	array(
		'options-general.php', //Settings -> General	
		'post',                //The post editor
		'page',                //The page editor
	), 
	//Additional attributes for the link tag.
	array(
		'target' => '_blank',
		'title' => 'Open "http://example.com/" in a new window'
	)
);
 
?>

You can download a working example here. The screen-meta-links.php file is included in the archive. Feel free to use it in your own plugins.

While Screen Options were already present in older WP versions, only the latest 3.0 release finally introduced a sane way to add your own content to this panel – the screen_settings filter. This filter is completely undocumented, so I thought it would be helpful to create a short tutorial on how to use it. Hence this post.

The screen_settings Filter

This screen_settings filter is applied to the additional HTML code that is to be appended to the Screen Options box. The callback function attached to this filter will receive two arguments: the current HTML code and an undocumented “screen object”. This object represents the current Dashboard screen. It has an “id” property which can be used to figure out which page/screen you’re on and only attach your extra HTML to specific pages.

Note that a “screen” is not the same thing as a page or a menu. For example, both the “Add Post” and “Edit Post” pages are considered to be the same screen. Luckily, in most cases you can (ab)use the convert_to_screen function to convert the page slug to a screen object. You can then compare the converted object’s and the current screen’s “id” attributes to check what page your script is executing on.

add_filter('screen_settings', 'screen_options_demo', 10, 2);
function screen_options_demo($current, $screen){
	$desired_screen = convert_to_screen('plugins.php');
	if ( $screen->id == $desired_screen->id ){
		$current .= "Hello WordPress!";
	}
	return $current;
}

The above code will append the line “Hello WordPress!” to the Screen Options box on the Plugins page.

For some pages – e.g. the main Dashboard page and post/page editor – you’ll need to figure out the corresponding screen ID by yourself. See the set_current_screen function in /wp-includes/template.php for clues.

If you specify a page that doesn’t have its own screen options, the Screen Options box will be added automatically and its contents will be set to the HTML code returned by your callback function. You can also compare the screen id against the hook name returned by add_submenu_page and its ilk to display custom screen options on plugin pages.

A More Convenient Form

Personally, I think the screen_settings filter is too low-level for most situations. Do you really want your callback to be executed on each and every admin page, and worry about converting between “pages” and the undocumented “screens”? And then duplicate that code (boo!) in each new plugin where you want to use this WP feature? Also, the extra settings fields added via this filter lack the tasty AJAX autosave feature used by the native screen options fields, which means you’d have to reimplement that as well.

With that in mind, I wrote a wrapper script that handles all that for you. The script has one public function named add_screen_options_panel which makes adding extra screen options panels as easy as adding extra menus. The function takes these arguments :

• id – the string to use in the ‘id’ attribute of the settings panel. Should be unique.
• title – Title of your new settings panel. Set to an empty string to omit title.
• callback – Function that fills the panel with the desired content. Should return a string of HTML.
• page – The page(s) on which to show the panel.  This can be either a string specifying a single page file name (e.g. “plugins.php”) or the hook name returned by add_submenu_page (e.g. “settings_page_my_plugin”), or an array of page filenames/hook names.
• save_callback – Optional. The name of the function that will save the settings contained in the panel.
• autosave – Optional. If set to true, panel contents will be automatically submitted (via AJAX) when the value of any field in the panel changes, and the specified save_callback function will be called with the field values. Defaults to false.

Here’s an example of how this function is used in the latest version of my Raw HTML plugin:

include 'screen-options/screen-options.php';
 
//Add our panel to the "Screen Options" box
add_screen_options_panel(
	'rawhtml-default-settings',       //Panel ID
	'Raw HTML defaults',              //Panel title. 
	'rawhtml_default_settings_panel', //The function that generates panel contents.
	array('post', 'page'),            //Pages/screens where the panel is displayed. 
	'rawhtml_save_new_defaults',      //The function that gets triggered when settings are submitted/saved.
	true                              //Auto-submit settings (via AJAX) when they change. 
);
 
/* ...more code here...  */
 
/**
 * Generate the "Raw HTML defaults" panel for Screen Options.
 * 
 * @return string
 */
function rawhtml_default_settings_panel(){
	$defaults = rawhtml_get_default_settings();
 
	//Output checkboxes 
	$fields = array(
		'disable_wptexturize' => 'Disable wptexturize',
		'disable_wpautop' => 'Disable automatic paragraphs',
		'disable_convert_chars' => 'Disable convert_chars',
		'disable_convert_smilies' => 'Disable smilies',
	 );
 
 	$output = '';
	foreach($fields as $field => $legend){
		$esc_field = esc_attr($field);
		$output .= sprintf(
			'<label for="rawhtml_default-%s" style="line-height: 20px;">
				<input type="checkbox" name="rawhtml_default-%s" id="rawhtml_default-%s"%s>
				%s
			</label><br>',
			$esc_field,
			$esc_field,
			$esc_field,
			($defaults[$field]?' checked="checked"':''),
			$legend
		);
	}
 
	return $output;
}
 
/**
 * Process the "Raw HTML defaults" form fields and save new settings
 * 
 * @param array $params
 * @return void
 */
function rawhtml_save_new_defaults($params){
	//Get current defaults
	$defaults = rawhtml_get_default_settings();
 
	//Read new values from the submitted form
	foreach($defaults as $field => $old_value){
		if ( isset($params['rawhtml_default-'.$field]) && ($params['rawhtml_default-'.$field] == 'on') ){
			$defaults[$field] = true;
		} else {
			$defaults[$field] = false;
		}
	}
 
	//Store the new defaults
	rawhtml_set_default_settings($defaults);
}

And here’s the result :

You can download the wrapper script here. To use it in your plugin, just drop the “screen-options” folder into your plugin’s directory and include the screen-options.php file. Then call the add_screen_options_panel function as described above.

Bonus: the file is structured in a way that lets multiple plugins execute it without causing conflicts

• Broken Link Checker forum
• Admin Menu Editor forum
• Eclipse Link Cloaker forum

If you use any of these plugins and you think that they could be improved, head over to the corresponding forum and post your idea!

Even if you’ve already sent me your suggestion using e-mail or blog comments, you should still go to the appropriate forum and post it there. This will give other users the opportunity to vote and comment on them. Suggestions that are supported by multiple users are likely to be implemented much sooner than they would otherwise be

If this catches on I will eventually create feedback forums for my other WordPress plugins.

On a completely unrelated note, here is a picture of a playful feline :

(Clicken sie das bild to enlarge)

Crash-Course In Output Buffering

As the name implies, output buffering lets you buffer the output of a PHP script.  Once you initialize a buffer using the ob_start() function, any output that would normally be sent to the browser is stored in the buffer instead (exception : HTTP headers are still sent immediately). You can then process the buffer’s contents and send a modified version to the browser, or discard the buffer entirely if you like. PHP will also automatically flush any active buffers at the end of the script’s execution.

One of the ways to manipulate the output is to create a callback function that takes the current contents of the buffer and returns a new buffer. Then you just pass the function name to ob_start() and it will be automatically called when the buffer is flushed or cleaned. This is the method that we’ll use to filter WP-generated pages.

Filtering WordPress Pages

Enough with theory, lets see some code! Here’s a simple example plugin that uses output buffering to attach the current URL and page size to each page generated by WordPress :

<?php
/*
Plugin Name: Page Filter Example
Plugin URI: http://w-shadow.com/blog/2010/05/20/how-to-filter-the-whole-page-in-wordpress/
Description: Demonstrates how to filter the entire page in WordPres. 
Version: 1.0
Author: Janis Elsts
Author URI: http://w-shadow.com/
*/
 
 
/**
 * Initialize output buffering.
 */
function ws_set_up_buffer(){
	//Don't filter Dashboard pages and the feed
	if ( is_feed() || is_admin() ){
		return;
	}
	//Start buffering. Note that we don't need to
	//explicitly close the buffer - WP will do that
	//for use in the "shutdown" hook.
	ob_start('ws_filter_page');
}
add_action('wp', 'ws_set_up_buffer', 10, 0);
 
 
/**
 * Buffer callback.
 *
 * @param string $html Current contents of the output buffer.
 * @return string New buffer contents.
 */
function ws_filter_page($html){
	//As an example, lets append the current URI
	//and page size to the generated HTML.
	$info = sprintf(
		"<!-- \nPage : %s\nHTML size : %d bytes\n -->",
		$_SERVER['REQUEST_URI'],
		strlen($html)
	);
	return $html . $info;
}
 
?>

Tips and Notes

There are some things to keep in mind when using output buffering to filter WordPress pages.

• You probably don’t want to filter each and every page. For example, the Dashboard and the RSS feed should most likely be excluded (unless you’re specifically targeting them, of course). Use conditional tags to check whether the current request refers to one of those pages.
• Many conditional tags won’t work properly until after WP has finished parsing the current request. To mitigate this, attach your buffer initialization routine to an action that runs after the query has already been parsed. The “wp” action is a good choice.
• You don’t need to explicitly close/flush your output buffer – WordPress will do that automatically. See wp_ob_end_flush_all() in /wp-includes/functions.php.
• Beware of conflicts with optimization-related plugins. To make pages load faster, some of them will set up their own buffer and compress page contents with the gzip algorithm. This can make those pages appear as unreadable gibberish to your script. To avoid that, make sure your buffer is initialized after the other plugin’s buffer. Some hook priority tweaking may be required.

And now you know how to filter the whole WP page

Here’s a screenshot (click to enlarge) :

To begin, you’ll need to enter your WordPress.org account credentials in Plugins -> WordPress.org Account. This is necessary because only registered users can vote on plugins in the official plugin directory. When that’s done, the plugin will add the star rating widget and the “Works” and “Broken” buttons from the WordPress.org directory to each plugin listed in the “Installed Plugins” tab, allowing you to rate and vote on them without leaving the Dashboard.

The plugin will also attempt to retrieve your past ratings from WordPress.org and pre-fill the rating widgets with your current votes.

Download

vote-for-plugins.zip (17 KB)

Requirements

• PHP 5
• WordPress 2.9+

Installation

1. Upload and activate.
2. Go to Plugins -> WordPress.org Account and enter your WordPress.org user name and password.
3. Go to Plugins -> Installed Plugins and cast yer’ votes

Known Issues & To Do

• When you first install “Vote For Plugins” it doesn’t know which of your plugins are listed in the official directory (and thus can be voted on) and which aren’t. So it tries to err on the side of optimism and may initially add the rating widgets to some plugins that can’t actually be rated.
• Fetching past ratings takes longer than it should.
• Voting on several plugins at a time would be handy.

Does this unconventional conclusion remain true  in the long-term? Today I’m going to post a follow-up study that discusses just that. The long-term results were… different.

Newly Charted

As of today, the visitor segmentation script has collected 52 days’ worth of data. This is five times the duration of the previous experiment (which lasted just over a week), so the results presented below are presumably much more accurate that those I posted last time.

Without further ado, here’s the updated CTR chart :

Units hidden to comply with AdSense ToS.

The updated study shows that visitors arriving from external sites (except search engines) are those who yield highest click-through rate. In the previous analysis, this group occupied the second-to-last spot. Internal visitors, who were the previous “leaders” – if one may use that word to describe people very likely to click on Internet ads – now fall into the second place. Search engine visitors come third. Finally, direct visitors – i.e. people who arrive via browser bookmarks or by typing in the URL – are still the least likely to create advertising income.

Here’s a chart comparing the old and new results :

Darker shades represent the previous results, lighter ones – updated research.

Of course, we also need to consider eCPM. eCPM represents the average earnings per 1000 impressions. Again, I can’t show you the actual numbers due to AdSense rules, but this chart should give you a general idea of the relative financial value of various traffic sources :

Interestingly, this is pretty close to what we saw in the previous study – internal visitors generate the most valuable clicks. External and search visitors share the second spot, and direct traffic is the least valuable advertising-wise.

Here’s a comparison with the previous results :

The past is dark, the present light. Future not shown.

Conclusions

Despite the updated rankings, the overall conclusion is the same one I arrived to last time – on this site, the CTR of search, external and internal visitors is very close. Showing ads only to one kind of visitors wouldn’t make much sense.

Likewise, the main take-away for other AdSense users is still this : don’t rely blindly on stuff you read on a blog somewhere; test any suggested optimization techniques yourself.

I think that the fact that I got slightly different results this time only reinforces the validity of that advice

If you’re feeling courageous, you can download the in-development version and try out the new features right now, bugs and all. The final & reasonably stable version should be ready in a week or so.

You can find a full list of new features and changes below. Any user suggestions not on this list won’t get implemented for v. 0.9, but they still remain on my to-do/idea list for the plugin, and may well be realized eventually.

What’s New

The big changes :

• Checking comment links.
• Email notifications.
• Run the link checker when you’re not logged in (via Cron).
• Recheck selected links via Bulk Actions.
• Suspend checking if the server is overloaded.
• The confusing “Discard” button is gone; replaced by a “Not broken” action link.
• Better handling of false positives. If you mark a link as “Not broken”, the plugin will memorize the server response that made it think the link was broken, and treat the link as working unless/until it gets a different response when it checks that link again.
• Support for custom checking algorithms, e.g. for dealing with YouTube and RapidShare links (not implemented yet, but the required scaffolding is there).

The minor stuff :

• Additional icons (from FamFamFam) for the link table.
• The “Delete sources” action asks for confirmation before deleting anything.
• Long HTTP headers in the log no longer cause the “Details” section to expand ridiculously.
• FTP, mailto:, javascript: and other links with unsupported protocols now show up in the “All links” table.
• The rarely used “Exclude” link is gone. You can still exclude links by adding the URL or domain to the exclusion list in settings.
• Editing links via the plugin’s interface creates new post revisions (where applicable), so you can revert the changes if something goes wrong.
• Searching by link text now uses simple pattern matching, not full-text search.
• Added Czech translation.
• Requirements upped to WP 2.9+

To Do

Things that need to be done before the final release :

• Test and tweak email notifications.
• Test and tweak load limiting.
• Update localization files.
• Make “Trash” links use AJAX, where possible.
• Obsess over the wording of error messages.
• Code clean-up.