Spam Fritters

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.

Now with added Habari

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…’.

What’s the benefit of 3rd party commenting services?

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?

Cross Platform Themes: WordPress & Habari

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