On balance, this is a huge improvement, however a coupe of features that were in the previous version, and that I want to use on my current project went AWOL. Fortunately, because the plugin now uses standard WordPress functionality for storing its data – these are pretty easy to knock together. So – my first major need was for a widget to show “recent ads” in a sidebar. Here’s a screenshot of the widget in action:

If you want to give it a try out – you can grab it here – just install it as a standard WordPress plugin, activate it, and the widget will be available under Appearance > Widgets in your WordPress admin area.

The post WordPress Classified Ads Widget appeared first on Lee Willis.

It’s even worse than that, because the same issue also affects Custom Taxonomies.

Now, much has been made of Custom Taxonomies, and of Custom Post Types, and rightly so. Custom Post Types and Custom Taxonomies are great facilities that really start to move WordPress away from a blogging tool, and into the realms of a a CMS and application development framework.

I’m a big fan of Custom Taxonomies, and I’ve written about what you can do with them before, and I’ve used them in anger on real WordPress sites. Custom Post Types are a little newer, and I’ve only just started working with them.

So – why the outrageous statement about them being broken?

Well, the good news is that I don’t think Custom Taxonomies, and Custom Post Types themselves are broken – what is broken is the theme support that goes with them.

Anatomy of a WordPress theme

To explain this in detail, you first have to understand a little about how WordPress themes work. Themes in WordPress consist of a number of files, which will be used according to the template hierarchy. That is, if WordPress is trying to display the home page it will look for home.php. If it’s found in the users theme (or child theme) then it will be used to display the page. If WordPress is displaying a single post then it will look for single.php and use that to display the page.

The important thing to note is that each of these pages, whether it’s home.php, single.php, archive.php or page.php is responsible for the whole of the page. Let’s consider an example of a web page layout from a typical website:

Breaking this down, there are the following main areas:

In this example, the page is made up of a site header (Yellow), some sidebars (Green) and a site footer (Blue). The main article/archive is contained in the white section. This is a fairly typical layout. If you were building this in WordPress, a fairly common approach would be to call get_header() at the top of all of your template files, get_sidebar() after that, then have the code to display the page content, and finally a call to get_footer().

get_header(), get_sidebar() and get_footer() are really just convenience functions that include specific theme files, making it easy to have standard headers, footers, sidebars etc. across your whole site.

So, this leaves us with this:

Custom Post Type Theming

So – what’s all this got to do with Custom Post Type theming then? Well, those of you paying attention will have realised that the Template Hierarchy provides support for theming both the display of single posts of a custom post type (Via single-{post_type}.php) and archives of posts belonging to a custom taxonomy (Via taxonomy_{taxonomy}.php or taxonomy_{term}.php).

On the face of it, this all seems fine. If you’re building a site, then you write a small chunk of code to register your custom post type, maybe add some meta boxes to the admin page to capture information specific to your post type, then throw together a template page to display it all.

Let’s take a custom post type of “Movie” as an example. We’d register it, set it up, and probably add some additional information beyond just the main content, particularly we might associate the post-type with the “Director”, and “Actor” taxonomy. This would allow us to show information about the director, and actors involved in the film on the “Single Movie” view – as well as create taxonomy archives by Director, or Actor.We might also add a meta-box to capture the movie running time, and maybe a review score (“9/10” etc.)

So, we wander off to our theme, copy single.php to single-movie.php and add in some code to fetch the taxonomy information, and display it where we want, and also to fetch and display the running time, and review score.

Job done.

The Problem

What if you’re writing a plugin that implements the movie Custom Post Type? Your end-user’s theme won’t have a single-movie.php file – so WordPress will fall back to using single.php – which of course won’t pull back the Director, Actor, Running Time and Review information. So what do you do?

The obvious thing is to supply a single-movie.php that the user can use. Now rewind a little, to where I said that theme files were “responsible for the whole of the page”.

This is where we hit our problem. We can assume that our single-movie.php should call get_header(), get_sidebar(), display our custom post type data, and then call get_footer().

But what about people who have a right-hand sidebar? What if the users theme has a bunch of standard page-furniture that isn’t included in header.php or footer.php, but included in each of the various single.php, archive.php?

Now we start to see the problem. It’s virtually impossible to distribute code that registers a custom post type, and be able to use the Template Hierarchy to display it – your only real option is to let WordPress fall back to single.php and then filter the_content, and then build your own “theme” infrastructure to let users “theme” the content.

This is bad because it’s reinventing the wheel, bad because it makes it difficult for theme authors to provide support for your cool plugin out-of-the-box, and bad because it’s unintuitive.

The same problem exists for taxonomy_{taxonomy}.php as well so you can’t create nice taxonomy views for the taxonomies your plugin creates.

Ideally, we want to be able to provide a template that is just responsible for displaying the post itself, (ie the white box only in the images above), and have the rest of the page displayed by other files in the user’s theme.

How we get there is beyond me though … answers welcome below!

The post Why Custom Post Type theming is broken in WordPress appeared first on Lee Willis.

I wrote recently about building a brand directory using a fantastic feature of WordPress called “Taxonomies”. Now that that feature is live I’ve realised that a number of my favourite WordPress plugins simply don’t support taxonomies.

Among the casualities were Google XML Sitemaps, and the otherwise excellent Headspace2.

Now, the beauty of open source is that when you get an itch like this, you can go and scratch it. So, I whipped out my coding gloves and set to work.

The results are below:

Google XML Sitemaps

The patch below will ensure that the pages for all of your taxonomy terms are listed in your sitemap – helping Google find the pages quicker.

http://www.leewillis.co.uk/patches/google-sitemap-generator/include_taxonomies.txt

HeadSpace2

The patch below lets you add %%term_description%% so you can populate your META tags properly on your term pages – great for us and our product directory.

http://www.leewillis.co.uk/patches/taxonomy_support_for_headspace/patch_v2.diff

Both of these have been submitted to the plugin authors – so hopefully they’ll get included by default in a future release. If you find them useful – please add to the threads here:

Google XML Sitemaps

Headspace2

The post Custom Taxonomies In WordPress Plugins appeared first on Lee Willis.

WordPress lets you categorise your posts according to “tag”, and “category”. Which is fine. However, for some time now WordPress has supported a concept called “Custom Taxonomies”. Which is a long winded way of saying “We’ll let you choose how your organise and present your posts – however you want”.

This isn’t something I’ve ever felt the need to use before (I’m happy enough with tags on this blog) – however having used them recently I’ve really begun to appreciate how powerful they are – and I’m amazed that more people don’t use them to create a more sensible structure to their WordPress sites.

That said, I’m a bit of a geek, who’s not averse to diving into code, and isn’t intimidated by a set of cryptic API documentation

The Business Case

So, what can taxonomies do for you?

The site I built this for is a resource all about baby slings, the different types, the different brands, and people’s experiences, of finding, choosing, and using them.

Tagging just seemed to create a big, hard-to-navigate tag cloud that didn’t create an easy way for people to find the right content on the site that was going to be useful to them (Feedback has suggested that people are either looking for information about a particular brand, or a specific type of sling irrespective of brand).

The How-To

So, out went the “tags” (We removed them from most old posts, don’t add them to new posts, and got rid of the “tag-cloud”). Next step was to install Joost de Valk’s Simple Taxonomies plugin. This is one of Joost’s simpler plugins. In general all it does is let you create a taxonomy, and manage the terms within that taxonomy.

Actually, as an aside – I suspect this is why custom taxonomies haven’t really taken off. Out-of-the-box you have to create code to set them up and use them for effective site navigation. If the functionality provided by Joost’s plugin was in WordPress core, and theme authors really started coding for this stuff, I’m sure it would fly, but I digress …

So, using the plugin, we created two taxonomies – “Brands”, and “Sling Types”.

Next step was to go back through our posts (Fortunately this was in the early days of the site!), and correctly “tag” the posts against the right taxonomies. So on the SnugBaby review, we set the “Brands” to “SnugBaby”, and the “Sling Types” to “Mei Tai”.

Now we’ve got all of our posts beautifully organised, but we don’t have a way to view them. Before we get to that though, there’s just one more step. For every “term” (ie, for every brand, or sling type) we need to provide a description. Your new taxonomies can be found in the “Posts” section of the WordPress backend, simply click on the taxonomy, e.g. “Brands”, then work your way down the list adding a useful description.


Now we can actually start presenting this information sensibly!

Theme Work

Now, we’re going to use that list of “terms”, and their descriptions, to create a top-level list of “brands”. Download the file below, and save it in your WordPress theme directory. We called it “brand-directory.php”, but the name doesn’t really matter.

brand-directory.php

This will create a new page template called “Brand Directory” (If you want to change the name, edit the comment at the top of the file).  Now create a page in WordPress, provide some content that you’d like to use as an introduction, and set the page template to this new file:

Basically all this file does is display the page content you created:

<?php the_content(); ?></p>

followed by each one of the terms that you’ve used, along with it’s description:

$terms = get_terms(‘brands’);

foreach ($terms as $term) {

echo $term->description;

and a link to all of the posts that have been assigned to that term:

$wpq = array (‘taxonomy’=>’brands’, ‘term’=>$term->slug);
$query = new WP_Query ($wpq);
$article_count = $query->post_count;

if ($article_count) {
echo “<a class=\”taxonomy-rel-link clearfix\” href=\”/brands/”.$term->slug.”\”>”.$article_count;
} else {
echo “<span class=\”taxonomy-rel-link\”>$article_count”;
}

echo ” related article”;
if ($article_count!= 1) echo “s”; else echo  “”;
if ($article_count>0) {
echo ” – click to view</a>”;
} else {
echo “</span>”;
}
echo “<br />”;;

And there you have it, a dynamic data driven directory that keeps itself up to date whenever you “tag” a brand – all you have to do is add a description for the brand!

For an example see the “Get Your Hands Back!” brand directory here.

The post Using WordPress taxonomies to create a product directory appeared first on Lee Willis.