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 path to the plugin’s file. In most cases you can simply use the __FILE__ constant here. Alternatively, you can also specify the path relative to the “plugins” directory, e.g. “my-cool-plugin/my-cool-plugin.php”.
• $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 core motivation for the experiment was to test the prevalent assumption that people coming from search engines are the ones most likely to click on ads. To this end, I used a little piece of JS that would present different ads to people based on how they arrived on this site – either directly, from a search engine, from another kind of external site, or from a different page on the same site. All the ads were visually identical but were tracked separately.

(See the original announcement and the first summary for more details.)

The visitor segmentation script has been running uninterrupted for more than five months, allowing me to collect CTR and CPM data on more than 10 000 AdSense clicks. Overall, the trends look stable enough that running it for a while longer probably wouldn’t change the results. So now is a good time to post one final summary and declare the experiment concluded.

Internal Traffic Wins

At least on paper, it does. Out of all possible traffic sources, internal traffic – i.e. people who browse more than one page into the site – has the highest click-through rate and the highest eCPM. However, it also accounts for the least number of ad impressions. In a nutshell, internal traffic is valuable but rare.

Conversely, search engine traffic comes third in terms of CTR and eCPM, but brings the most money due to a high number of impressions.

The full results are below. To comply with AdSense ToS which prevent me from displaying the actual numbers, the results have been normalized to display the relative CTR and eCPM of various traffic sources.

Source Data

The above results are based on:

• > 18 000 clicks.
• > 400 000 impressions (73% search engine traffic).

All data was collected during an uninterrupted 168 day period (2010.03.09 – 2010.08.24) on this very same site. Results may be different for other sites.

Source Code

The source code of micro-tweet is exactly 137 characters, which is short enough to fit in a single tweet :

import sys,twitter as t;p=sys.argv;a=t.Api(*p[1:3]);m=a.GetFriendsTimeline()[0];print m.user.name+':',m.text;p[3:] and a.PostUpdate(p[3])

Installation

1. Install Python.
2. Install the simplejson library.
3. Install the python-twitter library.
4. Copy the client source code (above) and paste it into a new file. Save it as “micro-tweet.py”.

Usage

To run the client, execute micro-tweet.py using the Python interpreter and pass your Twitter username and password as the script arguments. This will output the latest tweet from your friends time line:

python micro-tweet.py username password

To post a status update, pass the tweet text as the third script argument. The following example will again output the latest tweet from your friends time line and post “Your tweet here!” (sans quotes) to Twitter:

python micro-tweet.py username password "Your tweet here!"

Note that the tweet text needs to be enclosed in quotes for it to be posted properly. Use "double quotes" on Windows and 'single quotes' on *nix-like systems. You will not receive any confirmation as to whether your tweet was posted successfully or not. To check, visit twitter.com or fire up a different Twitter client.

Why micro-tweet?

Just for fun

micro-tweet was a little project I did over the weekend. The goal was to see if I could squeeze the essential features of a “real” Twitter client – reading and posting tweets – into less than 140 characters. It also served as a nice work-out for my rusty Python skills.

And yes, I’m aware that using a pre-existing library to interface with the Twitter API might be considered “cheating”, but it would be downright impossible to fit the script into the size constraints without it. The API endpoint URLs alone would probably be long enough to push the script over the limit.

In practice, dbDelta is fragile, undocumented and prone to fail silently when something goes wrong. It can only parse queries tailored to its idiosyncratic requirements, doesn’t know how to drop obsolete columns, isn’t aware of character sets and collation, chokes on extra whitespace… Nasty, but evidently Good Enough™ for most plugins, even for WordPress itself. It’s still better than doing schema updates manually, and in most cases you can work around the limitations.

Then again, sometimes you can’t. Just a few days ago I ran into a situation that dbDelta just couldn’t handle (due to the aforementioned lack of collation awareness). This prompted me to refactor dbDelta into something more flexible. The result was the blcTableDelta class – still somewhat finicky with regards to query syntax, but much more flexible otherwise.

In the remainder of this post discuss how my version compares to the built-in dbDelta function, explain how to use it, and provide the source code.

Advantages

My version of dbDelta is by no means perfect – or, for that matter, even particularly good. That would require implementing a full-blown SQL parser, which is clearly overkill for a utility function that gets called only once or twice per install. Instead, it’s just Better Enough™. Here’s how blcTableDelta fares when compared to dbDelta :

• More lenient with whitespace – no more ridiculous requirements like “there must be exactly two spaces between the words PRIMARY KEY and the definition of your primary key”.
• Detects changes not just in column data type, but also in collation settings and NULL/NOT NULL/AUTO INCREMENT flags.
• Can optionally remove obsolete columns and indexes.
• Returns a complete query log, including execution status and any MySQL error messages.
• Doesn’t choke on “IF NOT EXISTS”.
• Has slightly better documentation.

The downside is that this class isn’t nearly as battle-tested as the native dbDelta function. It also doesn’t support INSERT queries.

Usage

Here’s a simple example of how to use the blcTableDelta class :

//Define the table structure you want to achieve.
$sql = <<<EOM
prefix}example_table` (
	`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
	`name` varchar(100) NOT NULL DEFAULT '',
	`another_field` text  COLLATE latin1_general_cs    not null,
 
	PRIMARY    KEY   ( `id` ),
	INDEX named_index(name)
);
EOM;
 
//Call the static delta() method
list($messages, $query_log) = blcTableDelta::delta($sql);
 
//Output the execution log
print_r($messages);
print_r($query_log);

The static delta() method can take up to four arguments :

• $queries - a string containing one or more CREATE TABLE queries, separated by semicolons.
• $execute – whether to apply the required schema changes (True) or just return the generated queries (False). Defaults to executing the queries right away.
• $drop_columns – whether to remove columns that are present in the current table but not in the corresponding CREATE TABLE query (True), or leave them alone (False). Defaults to removing the columns.
• $drop_indexes – same as the previous argument, except for indexes.

The function returns an array with two elements. The first element is a list of human-readable messages explaining what schema changes would need to be performed to update the database. The second returned value is the query log. Each item of the query log array is also an array, with up to three keys :

• “query” – the generated SQL query.
• “success” – a True/False flag indicating whether the query was executed successfully. Present only if the $execute argument was set to True.
• “error_message” – the MySQL error that occurred when executing the query. Only meaningful when “success” = False.

Source Code

The source code is too long to include in the post, so I’ve placed it in a separate .zip archive. Download it here. Just place the .php file found therein somewhere inside your plugin’s directory and include it before calling blcTableDelta::delta.

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?

Whether we have free will is not a question of science. Nor is it a question of religion. And, despite the protestations of many, it is also not a question of philosophy.

Free will is mostly a matter of terminology.

Most people treat “free will” as something obvious, but it can be surprisingly hard to nail down the specific meaning of those two words. If you go and ask a random passer-by what they think free will is, they’ll probably say it’s something like “having a choice” or “your actions not being predetermined”. Answers like that are typical, but they don’t really stand up to scrutiny.

Choice

Lets consider choice first. If “free will” stands for “free choice”, then what choice is “free”? Computers can make choices – often incredibly complex and important ones – but no-one considers them to have free will. This is because a computer’s choice is deterministic: the same inputs will always produce the same outputs. No matter how complex the algorithm it runs, a computer’s behaviour is ultimately predetermined. Therefore, it does not have free will.

But then, how is a human different? Sure, our minds are much more complex than any computer program ever written. And certainly, our choices are influenced by a multitude of factors that would be meaningless to a machine – goals and aspirations, genetics, upbringing, unconscious urges, societal pressure, and so on. And maybe even the goals and aspirations of our mystical souls and the almighty god(s), assuming such entities exist.

And yet, that is still just a list of (very many) inputs. If that’s all that goes into making a choice, we are as deterministic as computers. Given the same set of goals, preferences, societal pressures, mystical influences and so on, we would make the same choice every time. The very notion of making a choice implies that you select one of the alternatives based on some sort of criteria (AKA inputs and algorithms); implies some amount of determinism. If it didn’t, you could just as well flip a coin.

Chance

Sadly, that is exactly what many explanations of “free will” end up with. Chance. Randomness. Quantum physics! Anything to escape the dread of a predetermined destiny.

Alas, that turn of the free will argument just leaves me confused. Am I to understand that “free will” means behaving randomly? How is that better? After all, if your choice is random then it wasn’t really your choice. This stands in stark contrast with the common assumption that having free will means being able to make your own choices.

Since neither deterministic nor random choice are suitable for explaining free will, some have argued that it’s actually an amalgam of the two. Personally, this “Free Will cake mix” leaves me unimpressed. And it’s certainly not what the majority of people mean when they say “I have free will”.

Mmm, free will.

Conclusion

As far as I can tell, free will is a confusion, a meaningless phrase. NB : I’m not saying that free will is an illusion. What I really mean is that to say “free will” is the same as to say “colourless green ideas sleep furiously”. Instead of asking whether something has free will, we should instead ask specific questions, e.g. “what factors guide its decisions?” and “is its behaviour deterministic or random/semi-random?”.

Coincidentally, the arguments used in this post are very similar to the standard argument against free will. Fancy that.

Image credit : kefir @ sxc.hu

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

It got me wondering – could one write a program that converts any image into pure CSS & HTML?

As it turns out, that’s already been done. However, I was pretty sure it could be done better – despite limiting the maximum output resolution to 100×100, the CSS/HTML code produced by the aforementioned converter was truly humongous. Surely I could improve on that. Thus I went ahead and wrote my own image to CSS converter anyway.

The result, lovingly code-named “Pure CSS Perversion”, produces remarkably space-efficient* HTML and CSS code for a wide range of input images. You can try it out here.

*Only in the context of image-to-CSS conversion. It’s laughably inefficient when compared to most image file formats.

Awesome Features

• Highly perverse HTML/CSS coding
  Almost as space-efficient as storing your images in uncompressed bitmaps!
• Glorious 256 color palette
  Evokes fond memories of DOS and VGA.
  
• Dithering support
  Greatly improves image quality with only an enormous increase in file size.
  
• Cross-browser compatibility
  Tested in Firefox 3.6, Opera 10.53, Chrome 6.0, and even Internet Explorer 8.
• Supports JPG, PNG and GIF
  Also supports PCX, ARJ and ponies. Okay, not really.

Examples

Click a screenshot to go to the corresponding converter results page.

You can find more examples on the converter’s homepage.

Descent Into Optimization

For those interested in such things, here is a detailed explanation of how the converter works, including a tedious step-by-step account of how I arrived to the current algorithm. You can also download the source code.

1. Starting Simple
The simplest way to encode an image as HTML/CSS is to convert each image pixel to a separate <div> element 1×1 pixels in size and use an inline style attribute set the div’s background color to that of the pixel. Example :

<div class="css-image">
   <div class="row">
      <div style="background: #abcdef; width: 1px; height: 1px;"></div>
      <div style="background: #abcdef; width: 1px; height: 1px;"></div>
      <!-- more pixels -->
   </div>
   <div class="row">
      <div style="background: #abcdef; width: 1px; height: 1px;"></div>
      <div style="background: #abcdef; width: 1px; height: 1px;"></div>
      <!-- more pixels -->
   </div>
   <!-- more rows/scanlines -->

This produces good-looking results, but the amount of HTML code quickly balloons out of control. Even a modest 200×200 picture would result take up over 1 MB when encoded in this way, which is wasteful and can even crash some browsers.

2. Palletise and Cassify
The easiest way to reduce the file size of the “pure CSS” image is to convert it to a palette-based format and create a new CSS class for each palette color. This is what my first version of the image-to-CSS converter did.

<style>
div { width: 1px; height: 1px; float: left; }
.color1 { background: #abcdef; }
.color2 { background: #f00000; }
/*....*/
</style>
...
<div class="color1"></div><div class="color2"></div>

As you can see, I’ve also moved the rules that apply to all DIVs to a separate CSS block.

3. Run-Length Encoding
To further reduce the code size, we can detect continuous runs of the same color and encode each of them using only a single, wider <div>. To avoid explicitly writing out the width of each element, lets generate CSS classes for widths :

<style>
.width2 { width: 2px; }
.width3 { width: 3px; }
.width4 { width: 4px; }
.width5 { width: 5px; }
</style>
...
<div class="color1 width3"></div>

All <div>’s have a 1-pixel width by default, so we don’t need a “width1″ class.

4. Shorter Class Names
All those “colorA” and “widthB” class names are wastefully long. Lets shorten them to a single-letter prefix and a hex-encoded index.

<style>
.c1 { background: #abcdef; }
.c2 { background: #f00000; }
/* ... */
.w9 { width: 9px; }
.wa { width: 10px; }
.wb { width: 11px; }
</style>
<div class="c2a wf"></div><div class="c2 wa2"></div>...

5. Default Colors
We can squeeze out a few more bytes by determining the color that’s most frequently used in a given row and adding it as the background color to the container element. Then we can omit the color class from those elements that match the most common color.

<div class="c2">
    <div class="c1"></div>
    <div><!-- matches the row's background color --></div>
    <div class="c3"></div>
</div>

6. Perversion Begins
Hmm, look at all those byte-hogging <div> elements – each eating up 3 bytes on tag name alone. Plus, we’re forced to waste another 6 bytes on the completely useless closing tag! That will not do.

Luckily, the closing tags are optional for <p> and <li> elements. We can rework our HTML structure to make use of this.

<div class="css-image"><ul>
   <li>
      <p class="c1 w2">
      <p class="c3">
      <p class="cba w5">
      <!-- more pixels -->
   <li>
      <p class="c1 w2">
      <p class="c3">
      <p class="cba w5">
      <!-- more pixels -->
 
   <!-- more rows -->
<ul></div>

7. Going Classless
We’re also wasting 5 bytes/div on the “class” attribute, so lets get rid of it and use custom attributes instead.

<style>
p[c="1"],li[c="1"]{ background: #abcdef; }
p[c="2"],li[c="2"]{ background: #f00000; }
/*...*/
p[w="9"]{ width: 9px; }
p[w="a"]{ width: 10px; }
p[w="b"]{ width: 11px; }
</stlye>
<!-- ... -->
<p c="1"><p c="16" w="5"><p c="ab">

It may not validate, but it works. Who cares about validation anyway?

8. Even More Perversion
Well, that’s probably the limit of size optimization. We need to specify the background color and width somehow, so we can’t completely eliminate the attributes. We could remove the quotes from attribute values and format our output like “<p c=1 w=ab>”, but that’s it. Right?

Actually, there is a way to compress the output even more. We can use the attribute name itself to specify pixel color and width. Observe :

<style>
p[c1],li[c1]{ background: #abcdef; }
p[c2],li[c2]{ background: #f00000; }
/*...*/
p[w9]{ width: 9px; }
p[wa]{ width: 10px; }
p[wb]{ width: 11px; }
</stlye>
<!-- ... -->
<p c1><p c16 w5><p cab>

Yes, that actually works. It even works in Internet Explorer 8 (when in standards mode).

9. Huffman And Friends
In any given image, some colors are more common than others. For example, a picture of a lush countryside might have a lot of greens, whereas a beach photo would be predominantly blue and yellow. Our current algorithm is not aware of that – it simply enumerates all colors in sequential order, assigning attribute names as it goes. There’s no relation between the color and the codename it gets.

We can reduce output size by assigning shorter attribute names to more common colors. This is known as Huffman coding, and is one of the simplest algorithms used for lossless data compression.

The general idea is thus :

• Iterate over the image and record how many times each color is seen.
• Sort the list of colors by their frequency.
• Assign shorter names to more common colors, longer ones to rare ones.

In fact, we can use this idea to eliminate the color vs. width attribute distinction completely. Lets look at our HTML stucture again :

<p c1><p c16 w5><p cab><p ce2><p c1 w12><!-- ... -->

If we forget the “<p …>” wrappers for a moment…

c1 c16 w5 cab ce2 c1 w12

…it’s just a string of codes! Some more common, some less. We don’t need to know what each of them means to assign a optimally short and unique name to each one.

The actual implementation is somewhat complicated, but the HTML/CSS it produces is very space-efficient. This is what the output of my final algorithm looks like (line breaks inserted for clarity) :

<style>
p[a]{width:6px;}
p[b],li[b]{background:#dfdbda;}
p[c]{width:9px;}
p[d],li[d]{background:#dfe3e8;}
p[e],li[e]{background:#d4d5dc;}
/*...*/
</style>
<!-- ... -->
<div class="css-image"><ul><li y><p d f><p b c><p d a><p b xb><p o><p b _g><p e><p b l><!-- etc -->

Improve On That

Unbelievable though it may seem, this is still not the limit of size optimization for “pure CSS” images. For example, you could use variable-width right and left borders on the <p> element to encode additional pixels in a single element. This would decrease the HTML size at least by another 20%. You could also replace the primitive RLE algorithm I used in my converter with something more advanced. There might also be some interesting HTML hacks I haven’t even thought about.

I’ll leave that as an exercise to the reader