Ever since I have been using WordPress it has been based on categories. Tags are a relatively new thing, that I have never used, and even newer in the core. Interestingly Habari currently has only tags and I think this difference is quite an interesting one.

Generally people tend to think of categories fairly strict divisions that define the main topic of a post and tags as more specific, but loosly used, labels that are actually closer to index entries than an organisational structure.

The nature of blogs means that it is rarely possible to pre-define the content that will be included and this means that categories often get a little overgrown and need pruning back once in a while. Tags on the other hand are much more fluid and so can be left to grow where they will.

When it all comes down to it though they are both labels that apply to content. The only difference is in the way that we think about them, and use them. In fact the biggest difference is the user interface.

I’ve spent that last month doing little else but organising information and trying very hard not to assign lables to the various parts of the hierarchies so as not to confuse people with terms they expect to refer to something else and even so it has taken me some thought to get my head around the difference, or lack of difference, between tags and categories.

Only using tags (or only using categories) seems to offer a lot of flexibility. It lets you use plugins and naming structures to create hierarchies without the need for WordPress or Habari to actually be written to meet individial needs.

The differences, and uses, of tags and categories are well ingrained in people’s minds now and, let’s be honest, a lot of people do not want to consider their site taxonomy in greater depth than the default provides, but I think it would be interesting to just stop using categories in WordPress and switch to tags. It would certainly simplify some things.

I spent ages trying to find out how to do this. I knew it existed because I read about it but had no idea what to look for to find it. So this is a quick reminder write up.

If you write a plugin that creates an admin page, from WordPress 2.6 (I think) there is a new way to deal with the information the user posts from the form.

In the old days the form handling code would go at the top of the admin page function, or it could be hooked into other actions like the template selector. Now WordPress will create a custom hook.

In the admin page add a hidden form field called ‘action’ with a value of {pluginname}_{action}-{object}; so if you are updating a comment you might use ‘myplugin_comment-update’. You also need to change your form so it posts to admin-post.php.

Admin post will load all the WordPress functions and things, then create a custom hook called: ‘admin_post_’ + your action name. So you can create a new function for handling your form data and trigger it (using the same example) with add_action( ‘admin_post_myplugin_comment-update ‘myfunction’);

It is explained further on this page: http://codex.wordpress.org/Handling_POST_and_AJAX_Requests

I decided earlier on that I wanted to have a blog running Habari; it is one thing to write nice things about it and quite another to use it in anger and live with it over time. I mentioned the flickr integration on twitter and more details were asked for so that that is the purpose of this post.

I had started a blog to write about photo techniques (what few I have) but never did much with so this seemed well placed to convert to Habari. I deleted the WordPress files, added Habari and it is up and running.

I haven’t done much to it yet. Over time I will tinker and learn. You can find it here: http://www.eloquium.co.uk

Habari comes with some plugins bundled, two of which I used on the new blog. One is a WordPress database importer which seemed to work well, the other a flickr gallery. I have taken a screencast of the gallery and included it below.

You should note that I haven’t used WordPress to integrate with Flickr so I don’t know what the plugins are like. If you have used them then please drop the name of the plugin and any comparisons you would like to make with the video.

If you haven’t tried Habari, whatever the reason, you should also have a look at my last post where I asked for people’s reasons why they haven’t given Habari a try.

Most of the people that read this blog should be WordPress users and plugin fans so you know what a good blog platform looks like and have your finger on the pulse of blogging software. I hope I have a reasonable cross section of users from experts to novices. So here is my question:

Have you tried Habari? and if not why not?

I have tried most blog platforms, although I will admin that for most of them I haven’t checked back for a while, but I like to play with things, not just to host a blog, but be on the lookout for cool new stuff. I think Habari fits that bill and it is fun using it but it doesn’t seem to have the buzz that I would expect.

Buzz means people, and that means you, so what is stopping you? I would like to know.

I have been debating what to do with the Fun with Sidebar tabs plugin and I have now come to a conclusion: I am going to replace it.

Update A beta version of the replacement is available here: http://www.wp-fun.co.uk/2008/09/06/wordpress-plugin-fun-with-widget-structures/

The plugin was expanding to the point that it was more than a simple tabbed sidebar plugin, it was based on pre-2.5 widget handling which added a lot of code than was unnecessary, and the interface was becoming difficult to use.

I also wasn’t really happy with the way the javascript moved content around and I needed to find a solution to the css specificity problems.

All of these are good reasons to update it; however, this is by far my most popular plugin and changing things so much would likely cause problems for a lot of people who update automatically without knowing these changes are coming.

I have now completely rewritten the plugin and I am polishing the edges ready for the first beta. The new plugin will be called Fun with Widget Structures.

One change that won’t necessarily be popular is that the new plugin won’t be compatible with PHP4.

Jeffro has published an interesting post over at Weblog Tools Collections about the blame for plugin problems being laid at the door of the WordPress core team, and I think he has a point, but as a minor plugin author I also see things from a slightly different perspective.

In my book there are two different aspects to the releases. Security releases should happen when they happen and if things break then so be it. Feature releases are slightly different.

When a feature release comes out plugins are changed for that and people start developing against the new feature set. It might be necessary to revise, or do away with a plugin or it may open up lots of potential. Either way there can be a lot of work and for part-timers it can be very difficult to find the time. Six months really isn’t a lot of time when you are developing and fixing a plugin, only for a new release to come out and it all need doing again. Two months is even less. Not an excuse, but a frustration none the less.

One of the hardest things about plugin development is that when a plugin does anything unexpected the author is subject to a hell of a lot of queries and support requests from users. I have lost count of how many updates I intended to make that never got to code stage because the evening I planned to do it coincided with a user having problems and asking for help. Most end users don’t know enough about the technology to even begin to investigate what it is about their own setup that may cause issues.

The number of users that use my plugins are trivial compared to things like Ajax Edit Comments and I still find the support requests hard to deal with, so much so that I am thinking of retiring my most popular plugin.

The point of WordPress is to make it easy to use without any knowledge so plugin authors need to be prepared to provide a lot of help to people, but a community of part-timers like me means they won’t always get that support and changing WordPress too often makes it less likely.

What all this means is that each WordPress release could trigger weeks of queries and they may not actually be anything to do with the release itself. With new releases users start to tweak things again the requests all need to be investigated.

I do think that the WordPress team should be aware of the major plugins, but I don’t think they should develop to ensure compatibility or even test them. That is the problem that Microsoft has and it weights them down a lot. It is no bad thing that development of the product is seperate from the plugins that run on it. On the flip side though everyone needs to understand (even assume) that this is the case and that upgrade will break things. They need to assume they will need to get stuck in or discard plugins regularly.

I guess my conclusion would be to ask the question: why do features need to be rushed out? 2.6 was ahead of schedule and while it did add some good things really what is the rush? Is the competition really there to necessitate feature releases more than once a year? are there any features in 2.6 that were essential to get out two (ish) months after the last major update? I really think it could have waited until November. Security updates are essential and can’t wait but there is a lot to be said for stability.

Way back in the mists of time, following an article on Weblog tools collection, I started looking at writing an uninstaller for WordPress plugins. There was a significant interest in this at the time so I wrote a patch and submitted it to core where it stayed for some time.

The process was documented in three posts: Fun with uninstallation part 1, part 2 and part 3. Note that the sample plugins that are linked to in these posts have been removed as some users were misunderstanding them and using them despite the fact that they were practically useless.

My hope that the patch would be included in WordPress 2.5 was not to be. 2.6 has also been released. Finally though, thanks to Jacob Santos who pushed it along, with 2.7 it will be possible for plugin authors to write an uninstall routine.

How to write the uninstall routine

The final implementation is actually closest to my first attempt. It bypasses the problem of creating hooks in a plugin that will not be active and does not add to the core more than it has to.

To produce the uninstaller you need to include a separate file (uninstall.php) within the plugin folder. This should include all the code needed to remove options, database tables, etc.

This file will be run when the plugin delete routine runs, so it will not be possible to uninstall the plugin without deleting it. If the plugin is deleted manually, using FTP, then the plugin will need to be re-uploaded before anything can be uninstalled.

Given that WordPress 2.7 will include a plugin installer that will let you search for and install plugins directly from the plugin repository without any FTP shenanigans it is reasonable to presume that users will usually delete the plugin through the interface as well.

I think that users might want to uninstall a plugin in order to wipe the settings so it may not be a bad idea to write the uninstaller in a way that allows it to be run manually and to trigger the plugins activation function to reinstall the defaults. I am working on an implementation of this for the next version of my fun with plugins tool.

As this is a WordPress blog I’m not in the business of evanglising Habari, however much it may interest me. I do however want to make it easy for everyone to try it. Most WordPress users will find that it doesn’t yet meet their needs but every WordPress developer should get something out of understanding a bit more about it. The point of this post is a very simple comparison of plugin code.

Habari is a more controlled environment than WordPress. Depending on your view this is either restrictive or liberating and there are arguments both ways. Notably the file structure is controlled.

With WordPress you don’t need a plugin folder, and if you have one it can be named whatever you want. With Habari you must have a folder and the plugin file must share that name, using the format [folder name].plugin.php. This is important as it is part of the system that finds and runs plugins.

The file paths to the plugin directory are also different. With WordPress they are stored in wp-content/plugins/ in Habari they are stored in user/plugins/

When you get to the class itself there are more requirements. Habari plugins must exist as a class.

With WordPress there is a choice to create a class and instantiate it, or to put the plugin in plain code. Habari not only requires the plugin to be a class but also requires that the class extends a pre-existing class; the plugin class.

Extending the plugin class, as shown below, means that the plugin already has some built in actions. I will explain the benefit of this a little further down.

The other imediate difference is how the plugin information is defined. Here is a comparison:

WordPress:

/*
Plugin Name: My First Plugin
Plugin URI: [insert the plugin url here]
Description: This is a test plugin
Author: Andrew Rickmann
Version: 0.1
Author URI: http://www.wp-fun.co.uk
*/
 
class my_first_plugin
{
 
}
 
$my_first_plugin = new my_first_plugin();

Habari:

class my_first_plugin extends Plugin
{
  function info()
  {
    return array(
      'name' => 'My First Plugin',
      'version' => '0.1',
      'url' => '[insert the plugin url here]',
      'author' => 'Andrew Rickmann',
      'authorurl' => 'http://www.wp-fun.co.uk',
      'license' => 'Apache License 2.0',
      'description' => 'This is a test plugin',
    );
  }
}

The differences so far are minor so I won’t dwell on them too much; however, you should note that in Habari you should not instantiate the class. Habari will take care of that at the appropriate time.

Hooks

Habari, just like WordPress, uses actions and filters, to trigger activities or alter data during execution. There is a significant difference in the way they are put into practice though.

In WordPress you need to create a constructor within the class so that the code will run when the class is instantiated. You also need to create a function, called anything that you want, and then add a line to the constructor to register that function againts the appropriate hook.

In the example below I have create a function that takes in a string and returns it with an extra paragraph added. I have then registered this function against the filter hook that runs when the content is output (the_content). The result is that every post will have the extra paragraph added to the end of it. The full plugin looks like this:

/*
Plugin Name: My First Plugin
Plugin URI: [insert the plugin url here]
Description: This is a test plugin
Author: Andrew Rickmann
Version: 0.1
Author URI: http://www.wp-fun.co.uk
*/
 
class my_first_plugin
{
	/**
	 * PHP4 Compatible constructor to redirect to the PHP5 version.
	 *
	 */
	function my_first_plugin(){
		$this->__construct();
	}
 
	function __construct(){
		add_filter('the_content', array(&$this,'modify_post_content') );
	}
 
	function modify_post_content($content){
		return $content . '<p>An extra line added to the end of the content</p>';
	}
}
 
$my_first_plugin = new my_first_plugin();

Note: in this example I have included a PHP4 constructor to point to the PHP5 constructor. You could just use the PHP4 constructor on its own but this is my preference.

Habari does things quite differently. You cannot create a constructor because the class you extended already uses it. That doesn’t matter too much though because you don’t need one.

With Habari the function name you use defines which hook it will be attached to. For example, naming the function ‘action_plugins_loaded’ tells us that the function will be triggered by an action and the name of the action is plugins_loaded. You can guess when this triggers right? Habari takes care of registering the function.

To achieve the same effect as the WordPress plugin above the plugin needs a filter function called ‘filter_post_content_out’.

class my_first_plugin extends Plugin
{
  function info()
  {
    return array(
      'name' => 'My First Plugin',
      'version' => '0.1',
      'url' => '[insert the plugin url here]',
      'author' => 'Andrew Rickmann',
      'authorurl' => 'http://www.wp-fun.co.uk',
      'license' => 'Apache License 2.0',
      'description' => 'This is a test plugin',
    );
  }
 
  function filter_post_content_out($content){
  	return $content . '<p>An extra line added to the end of the content</p>';
  }
 
}

Priorities

The last difference I want to compare in this post is setting priorities. Both WordPress and Habari let you set the priority of the function by asigning it a priority number. Lower numbers take priority and therefore run sooner than functions with higher numbers. With WordPress the default is 10, for Habari the default is 8.

In WordPress you add the number to the registration function in the constructor. The following will register the function with a priority of 5:

add_filter('the_content', array(&$this,'modify_post_content') , 5 );

With Habari the priority for every function is set in another function, called ‘set_priorities’, by creating and returning an array. Adding the following function has exactly the same effect as including the number in the code for WordPress:

function set_priorities(){
    return array(
      'filter_post_content_out' => 10,
    );
  }

Setting the priorities for more than one function would require an entry in the array for each function.

Habari is similar enough to WordPress for the plugin system to not be totally alien, but it is different and requires a little thought. It is also worth noting that the documentation is a long way from the WordPress codex so a bit more work is required to figure things out. I figured out this hook by looking at the template tags in the theme and guessing. It is logical though so I only had to guess once.

The key difference is that with WordPress you create your functions and then tell WordPress they exist and what they should be attached to, but with Habari it checks if specifically named functions exist and if so runs them. Each part of the plugin process has a function named assigned to it from setting the plugin information (the ‘info’ function), to setting priorities (the ‘set_priorities’ function). It is more restrictive, but quite logical and easy to pick up.

If you want a headstart (albeit a small one) on your first Habari plugin then you can enter some basic details and download a zip file with the correct file and folder name from Fun with Habari Plugins. The WordPress version of Fun with Plugins is available as ever.

The next post will focus on other aspects of Habari plugins such as creating admin pages and extra utilities that are available.

I updated the version of WordPress running on my local installation this morning to find some interesting changes that, if they remain, could impact on your plugins.

This is the view that awaited me:

Each of the menu items on the left open and close as needed. Templates contains everything that is in the design tab now. Utilities features the new inbox (which seems to include notifications about WordPress and maybe new comments, but it doesn’t do anything yet) and some of the contents of the manage menu.

I’m not quite sure how I feel about it yet as I haven’t had much time to try it out, but there is a limit to how many admin changes people should accept so whatever happens with it lets hope they stick with it for a while. Personally I think the admin should be black (black is the new light blue).

Sitepoint has an article that looks at the trade off between simplicity and features .

The article looks at a paper which argues that the suggestion that a greater number of features equals lower usability and that fewer features equals greater usability is a false assumption that needs to be challenged.

The point of the article is ultimately to state that what people want is more capability and easier to use products.

What I find interesting about the argument between simplicity and features is that sometimes they both actually reduce the capability.

Take widgets for example. Widgets exist to make it easier to quickly change the contents of your sidebar. But, once you start using widgets you are also constrained by them.

How often are you asked by someone how they get a widget that replicates a particular template tag?

Before widgets it would be a case of adding the tag to the sidebar code. Users would be forced to learn how. But with widgets you don’t need to learn how to do this, or you want it in a position that the widgets won’t let you add manually, so you are constrained.

I have a theory that the more development that is done on a product like WordPress the lower the barrier for use is. This, in turn, means that more features are needed to help users accomplish things that they don’t have the technical knowledge to do themselves. This adds to the complexity which reduces usability and leads to the need for simplification. This reduces the options.

The process brings in new users and provides capability to a larger number of users, but at the same time the overall capability of the product and its user base gradually lowers making way for a new product to meet the needs of the more technically competent.