I love the debate that Jeff has started over at performancing about URL fields.

It started with this post where Jeff quoted me as saying:

This kind of spam, and in fact all spam, is a symptom of the misguided(IMO) approach to comments that says that a commenter should be ‘rewarded’ with a link that gives google juice.

…

Jeff even went so far to remove the URL field from his own blog: www.jeffro2pt0.com to test the reaction (My reaction was to include my URL in my comment).

Jeff has now following this up with another post asking whether the URL a person enters should even dictate whether to publish a comment, or mark it as spam?

Personally I don’t think it should, but, it can be indicative of what I think really matters, and that is the spirit with which the commenter approaches the blog.

If you comment for no reason other than to get your link there, and I will admit that I have done that myself on (rare) occasions, then I don’t care what you have to say, or what your URL is, you should not bother.

If you are motivated to consider commenting because the link will appear but do actually have something to say on the topic, then I think that is fair enough. I often have something to say but hold back, or decide not to, so if the link helps to break through that and encourage conversation then I am all for it.

The rub is that there is no real way to judge, so we are back with the URL.

My solution (I wrote a plugin to do it) is to add the URL beside the name so visitors can see where it links to exactly, and to make it clicakble using Javascript, for the benefit of my visitors. You could argue that this disavantages the people who comment and join in, but I don’t buy that.

Going back to my original comment, on the first post above, for me search juice is neither a right or a privilege; it exists for the sole purpose of making the search engine more relevant and I simply don’t see what relevance comments on someone else blog have to the value of my website.

My website doesn’t deserve higher placement on a search because I praised your LOLCats! and the same goes for every other site out there.

My last few posts have tended to feature Habari quite strongly. Truth be told I love it as a platform and I think it may be the future*. However, I am conscious that this is a WordPres blog and so I have taken steps to offer a choice of reading material by separating this blog into a WordPress version and a Habari version.

The Habari section, reachable by using the Habari category link, is running on Habari and the WordPress version is running WordPress, of course, and shortly they will be using the same theme. The exact same theme. In fact they will both load the theme from the same directory. What fun! (or should that be ‘what fun?’)

For a sneek-peek of the the new theme, the Habari section is already running it and once I complete the sidebar and WP specific bits I will use it here as well.

With that, I should be able to return to full WordPressy goodness here which happily coincides with the very welcome return of WordPress Weekly with Jeffro, and his new guest host Keith Murray who should be able to bring the view of a developer to bear on the whole thing. Nice!!

I’ll be sat up with a case of generic caffeine based beverage at oh-hell O’Clock here in the UK and I’ll try not to be too hard on Jeff in the chatroom. See you there.

*Don’t worry, I won’t be answering every question about WordPress problems with ‘of course, if you were using habari…’.

This week Automattic have acquired Intensedebate, and Disqus have announced the release of their public API. This has got me thinking.

I’ve previously felt that these 3rd party bolt-ons are of little real value to the blogging world, and for self-hosted blogs I still fell there is some merit in that. The featureset for Intensedebate is:

• Comment threading
• Reply by e-mail
• Importing / Exporting
• Commenter profiles
• Reputation points and voting
• Moderation / Blacklisting
• Widgets
• RSS Tracking
• Twitter
• Friendfreed
• Open ID
• Gravatar
• HTML Formatting

The Disqus feature set seems to be broadly the same.

So where is the value? None of these features is particularly interesting in and of itself; even when combined, the additional features don’t massively enhance commenting over the features that can (and have) been built into WordPress by the core team and plugin authors.

The real benefit is in meta-data.

Imagine being able to find the other blogs that your commenters have in common, and from there the blogs the commenters on the first set share in common, and you start to see the picture.

Now tie that data to one of the largest content networks out there, WordPress.com. Now you can connect those commenters with data about the content of those blogs, pre-categorised and tagged for easy use. Suddenly owning that kind of data really makes sense. If Facebook’s future is in search, then perhaps so is the future of WordPress.

This clearly makes sense for Automattic, and I imagine they will be able to use that data to provide some new services, or enhance the ones they have, Akismet in particular, but for those running self-hosted installations I am still uncertain as to the value.

It seems, to some extent, that this is yet another opportunity to give away your data for the benefit of others so each blog owner is going to have to ask themselves whether the added value it brings is worth more than the value you are giving away. Even if you can’t monotise that data yourself you want to be sure to get value when you ’sell’ it on.

I for one won’t be jumping on the 3rd Party Boat until I see something a little more exciting; how about you?

In my last post I wrote about the concept of desiging dual use themes, that is themes that will work across multiple platforms. I don’t mean themes that are ported to another platform, but one single theme that will work on both. That is what I am doing for my re-theme of this site, and in this post I will explain how I have gone about it.

There are enough similarities between the WordPress theme system and the Habari, rawPHP theme engine that it is fairly easy to switch between the two. Despite this there are also some very significant differences.

WordPress uses PHP functions as template tags. These functions use the GLOBAL keyword to access the data in the main classes. Habari outputs the information straight from the classes.

//WordPress
<?php the_title(); ?>
 
//Habari
<?php echo $post->title_out; ?>

The different approaches also mean the loops work differently. The WordPress loop uses a function to change the post class to the next post. Habari uses a foreach loop because the classes can be accessed directly:

//WordPress
<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
    //post content
<?php endwhile; else: ?>
<p><?php _e('Sorry, no posts matched your criteria.'); ?></p>
<?php endif; ?>
 
//Habari
<?php foreach( $posts as $post ) { ?>
    //post content
<?php } ?>

The important point about these differences is that it creates several possible methods of making the theme work.

Option 1 - IF

It is easy to determine whether the theme is running on WordPress or Habari. There are a lot of constants and classes that are unique. I chose to test the $theme object to make sure it extends the Theme class.

if ( isset( $theme ) && is_subclass_of( $theme , 'theme' ) ) {
	define('WORDPRESS',0);
	define('HABARI',1);
} else {
	define('WORDPRESS',1);
	define('HABARI',0);
}

I’ve also set constants for both WordPress and Habari so the code can be a bit clearer as to what platform is being tested against.

The problem with using IF statements to test these constants is it means adding a great deal of complexity to the code, and duplicating large chuncks of HTML. Not Ideal.

Option 2 - Emulate

Emulating either of the platforms seems like a good idea, but doing it within the theme itself is likely to bring difficulties. The theme engines load the content in different ways, so scope things in different ways, and this is likely to add a lot of extra work.

Option 3 - The third way

Option 3 is to let go of the way themes work on both platforms and create a new set of controls to act as a translator between the two. This is the method I decided to use.

The method

First things first, I needed a way to run code independently for each platform. Thankfully WordPress themes look for and include functions.php automatically, and Habari themes look for theme.php. Each platform ignores the file of the other so adding platform independent code is no problem.

Habari looks for an instantiates the class in this file as the variable $theme, so it seemed logical to group all the functions inside this class, and do the same for WordPress. Using this method, I could then convert every theme function call to a public method of $theme. I just need to make sure the methods are named the same in both classes.

To make things a little easier I also used a hook in the WordPress version to get the $post and $posts variables.

For example, The WordPress title tag method now looks like this:

public function post_title(){
	return apply_filters( 'the_title', $this->post->post_title );
}

The class defined in theme.php that Habari will load looks like this:

public function post_title(){
    return $this->post->title_out;
}

In both cases I am simply returning a value, so the theme uses:

echo $theme->post_title();

Note that in the WordPress version I added a hook to collect the global $post and $posts object and bring them into the class so that there is no need to use global in each function.

The loop

Obviously this is all fine until we come to multiple posts. The WordPress loop and Habari loop operate in very different ways to each other. Habari uses a simple foreach loop on the $posts object to return each $post object, and WordPress uses a function in a while loop to test if there is a next post. To make them both work together I needed to use the same loop for each. It seemed most logical to use something closer to the WordPress model:

while ( $theme->next_post() ) {
    //post data here
}

The code in both classes is exactly the same:

public function next_post(){
	$current = current($this->posts);
	if ( $current == false ){
		reset($this->posts);
		return false;
	} else {
		$this->post = $current;
		next($this->posts);
		return true;
	}
}

Template Hierarchy

To deal with the differences in template hierarchy I simple decided to go with the Habari version. Rather than mess about with the template system and rewrite it I have simply added an include statement into the WordPress files. index.php includes home.php; although WordPress will use home anyway but won’t work without an index.php file. archive.php includes multiple.php and so on.

Complexity

Of course the whole theme is more complicated than what you see here, and I still have some way to go. I have written a menu builder, a lot more replacement theme tags, and a stylesheet that outputs different colours and graphics links depending on platform, but hopefully this peek should give you the gist of it.

If you have any questions let me know and I will add to this post as needed. For the technically minded I have attached the header.php, multiple.php, theme.php and functions.php files to download: Sample code for cross compatible themes

Every now and again you read a post that makes such an obvious point that you wonder why it hasn’t been made before. The benefits of hooks over plugin-specific functions is one of them.

WordPress hooks, whether they be actions or filters, are simple bits of code that plugin authors can use to attach events to. Most of these hooks are deep within functions in the WordPress core, but some are within the standard template files. The following line comes from the default comment form:

do_action('comment_form', $post->ID);

This particular hook is used to add extras, such as the subscribe to comments tick box, at the bottom of the comment form.

The usual course of action if there isn’t a hook where a plugin author wants one is simply to define a function and ask the blog owner to insert it into their theme. This does cause some problems though, the biggest being that when you switch the plugin off the function will cease to exist and error messages will sully your theme. Not ideal.

The approach that W-Shadow is advocating is that instead of writing a new function, the plugin author should attach events to a hook that doesn’t exist yet and ask the blog owner to insert the hook instead. That way, when the plugin is deactivated, no errors will occur. But even better, if plugins that want to achieve similar things all use the same hook then they will be interchangeable.

My plugin doesn’t have the one killer feature that you want, but a similar plugin does? Just turn mine off and the other on. Job done.

I haven’t had much time to really think it through, but it seems to me that a really good extension of this would be for plugin developers to get toghether to define a load of hooks to help make the benefits a reality. For example, plugins that create menus could attach to hooks called ‘main_menu’, ’secondary_menu’, or ‘footer_menu’.

I do think there is scope for this to bring about some interesting results.

A few days ago Leland wrote at Themelab to ask is there a market for porting WordPress themes over to other platforms. He mentioned Drupal, Chyrp and Habari in particular. Having given it some I think he asked the wrong question. A better question would be: should themes work across multiple platforms?

In some cases this is a non-question but between WordPress and Habari there is scope for making one theme work on both platforms.

Right now the market for Habari themes is small but Habari is reaching the point where people are going to start trying it out, and when they do there is a strong chance that they will want to keep their theme. If it is true that Habari is the next WordPress.org (and this is possible, although by no means certain) then getting in early could be to your advantage.

In my next post I will explain how to do it and demonstrate how I have gone about creating a theme that works on both WordPress and Habari.

Include WordPress in a list of content management solutions and the “WordPress aint a CMS” comments will surge forth as inevitably as water flows toward the sea. But what is it that makes one piece of software a Content Management System, and another a lowly blogging tool?

My opinion, for what it’s worth, is that people expect a CMS to have feature X or N and as a result will classify any software that doesn’t have it as something else, but is that a mistake? I have always been in the camp that says that if you can manage content with it, it is a content management system, and therin lies the problem. Can you manage content with WordPress, or just publish it?

Before I go any further it is worth considering what the owner needs. For a very small business most traditional content management systems are massively over-specified. I think this is probably true for most small and medium sized companies as well. As you look at the features WordPress lacks consider what kinds of business are actually going to benefit from them.

With that said, let’s move on.

User management

The most obvious requirement is good user controls. With WordPress you can specify who can create a page and not publish it. This is a start, but can you limit an individual to posts within a particular topic, give them publish access in some places but not others?

There is certainly scope for better controls, but for small businesses the controls that are already there may well be sufficient.

Version Control

WordPress was long criticised for the lack of version control, and it now has it, but it is fairly basic. While WordPress can certainly help make sure nothing is lost, and allow you to compare one to the other as an audit tool it is limited.

Again a good question is how much control is needed? If you want to use your CMS as your audit trail then WordPress won’t cut it, otherwise it is probably enough.

Workflow Management

A key part of a content management system is the workflow tools. WordPress separates writing and editing but there may be more steps in the process: author, designer (editor, formatter, call it what you will), PR sign off, information architecture, etc. Larger businesses may have several different people that must sign off on the content. You may also need review and expiry dates when content is automaticlaly removed. WordPress doesn’t do that.

One workflow feature that I have always wanted (although not enough to develop it myself) is the ability to create an entire site based on draft content. Financial services firms (an no doubt many other industries) must gain approval from a qualified person within an organisation before publishing. If you make big changes, looking at a page at a time without the ability to navigate around can be painful.

Once again though, how many businesses actually need this, and how many only want it because it is available from other systems?

Menu Control

This for me is a biggie. Where is the option to create and control site menus? Listing all the pages is not an option in a working site as there will inevitably be pages you do not want in the list. If I used WordPress for a client CMS this is something I would need to create before going any further.

Form Builder

There is a great plugin that does everything you would ever want to do so it isn’t an issue, but the fact that it isn’t in core when many more basic things are being added tell you that WordPress isn’t moving toward business users, but away from them.

In writing this I looked at a lot of other functionality offered by content management systems but frankly most of it seems to be very situation specific. The kind of features that no one knows they want until they are offered it. How many companies really need banner ad management?

So, having considered these things do I still think that WordPress is a content management system? No. I think it is a content control system, or a content publishing system, but I do think it is enough for most companies provided they can put in place their own management processes. Having said that, blog content is still content, no? My opinion on most complicated CMS systems is that they are trying to throw a software solution at a people problem. WordPress can do anything you want with the right plugins but even without them I would take it over the alternatives.

I have just discovered Wordle. Wordle can take the contents of your blog, your last.fm profile (if you go through Master Giraffe), or just any text you type and turn it into a handy daigram, like the one below.

I’ve been reading a lot about child themes at ThemeShaper; about how you can override parts of a theme without modifying the theme itself, and it occured to me that, assuming it is possible, there may be something to be gained by chaining child themes together.

The basic idea behind child themes is that your main theme is built to be extensible and alterable, and then you apply a child theme to that in order to add colour or override parts of the base theme. Ian Stewart’s thematic is an example of the base theme.

It occured to me that if you could chain these child themes, i.e. base one child theme on another, you could create a series of interchangeable parts, none of which would need alteration, and all of which could be extended or added to by others.

For example, imagine 20 different choices of headers, 10 different types of page menu, 30 different types of post, all topped off with hundreds of colour and typography combinations.

I have no idea how practical it is, or even if it is possible. But it is something to think about.

I’ve been pretty scathing about some aspects of WordPress over the past few weeks both here and in the comments of a few other blogs. That being the case I thought it was about time I wrote about some of the things that I really like about the current development version of WordPress; the version that will become 2.7 in the next few months.

Admin Stuff

There is a new option in each post screen that allows the uselss crap you never use to be removed, leaving only a nice clean interface. The fact that drag and drop is back also means that you can order what’s left to create a start to finish workflow (or should that be WordFlow?). My entire post screen now looks something like this:

It is also now possible to reply to comments from the admin panel. choosing to reply to a comment brings up a nice floating box for your well thought out reply.

It is finally possibly, god knows why this wasn’t always available, to upload files from the media manager instead of having to create a new post.

And lastly a new quick edit option allows some of the core settings of posts and pages to be altered from the manage page. These are settings such as the page title, slug, publication status, whether it can accept comments or trackbacks, as well as categories and tags.

Development Stuff

For a long time I have thought that WordPress was missing functionality when it comes to the site menu. Every theme has one and yet the controls for it are woeful. The new function wp_page_menu() will generate the HTML for the menu including customisable home page text (if you want the home page included), the option to specify a class, change a sort order or to get the result as a string instead of echoing it.

This is a step in a direction, but it is very basic and some might want more from it. As a basic theme template tag it is the right choice though. It fits in with the rest of the WordPress theme template tags in philosophy and output and will remove some of the development burden for theme authors that aren’t really familiar with PHP.

wp_page_menu('show_home=Home&menu_class=menu);

WordPress 2.7 will support threaded comments by default and with that comes a template tag to take the work out of outputing those comments.

wp_list_comments($comment);

This is interesting to me for a few reasons. Firstly it rolls up the default comment HTML into the function, so while you can overide this I think it is likely that it will mean less variation in the way comments are marked-up. Most people tend to copy the default theme anyway but some themes do vary alot. The second reason is that to overide the comment HTML you include a function name to call instead. This means that even if you want to use different HTML it may be best placed in the functions.php file or at least in a separate file that the functions.php calls as an include. Either way it helps to keep the templates cleaner.

I have already written about the plugin uninstall mechanism so I won’t go into that again but it is interesting. Back in the days of 2.3 there was a lot of interest in this, promted by an article on weblog tools collection, and my posts on the subject still recieve a fair degree of attention.

It goes without saying that things could change either a little or a lot before 2.7 comes out, and I am sure there is more to come. In the meantime I would to hear about the things that you are most looking foward to about 2.7. What is your favourite new features?