The problem is…

Most (e-Commerce) themes is that they’re designed to show off the products in the best light possible, and as a result they tend to be image heavy. This is an approach that really doesn’t work well if you’re selling code. Currently my store relies on screenshots on products.

While I think this is really useful in terms of people understanding the functionality available in the plugin, it’s not great for people navigating the store, or “selling” people on the product. So – I’ve decided I need product “icons” of some form.

I’ve not yet decided what they’ll be, or how complex they’ll be. My design skills might stretch that far, or I may be looking for an illustrator who can help me out – but I’m not yet convinced that’s what will be required. 

Choosing a theme

As part of my original research on this project, I’d looked closely at WP e-Commerce, and WooCommerce – both of which have a broad selection of lovely looking themes. Discounting the really image heavy themes there’s still a great deal to choose from.

Since I settled on Easy Digital Downloads, and because it’s not a plugin I’ve spent a lot of time theming, I really wanted something that worked out-of-the box. Unfortunately, while there are a couple of nice themes, there’s not really as broad a choice as there is with other plugins – I think this is the only area I’d score the plugin down in. 

I settled on a shortlist though:

• Quota
• HumbleShop
• Forelight
• Shop Front

Forelight is great, and would be fantastic for someone selling digital art or similar, but I felt it relied too much on imagery. Quota and Shop Front also got discounted as great as they are, they were a bit too plain. I thought I’d have too much design to do to make them feel polished. In the end, I settled on HumbleShop (Be careful, there’s a normal, and an EDD version of the theme available on the net – make sure you grab the right one).

Aside from throwing a few warnings during installation, I’m pretty happy with this choice so far. As you’d expect from someone who tinkers a lot, I expect I’m going to be throwing a few improvement patches the authors way – we’ll see how that goes. However – first impressions are that it’s going to deliver the sort of experience I’m looking for.

Styling it up

Of course, I won’t be leaving HumbleShop as-is. I’ve created a child theme already and have started playing around with styling and colour schemes. I’ve been browsing colourlovers.com for colourscheme inspiration. Again I had a shortlist (Higher, Wordofmouse & Worf, Winter Olympics, and Breakfast Berries), but after a discussion with some trusted friends – I settled on Wordofmouse & Worf:

Color by COLOURlovers

Actually – when I say “settled” on – that might not be entirely true – after applying it to HumbleShop, I’m not quite sure it works, so it may be back to the drawing board. We’ll see…

The post Designing the plugin store appeared first on Lee Willis.

I’m pretty happy with the theme in action on Stewart’s site, but I realise that people do strange and interesting things on their WordPress sites, so before I release the theme, I’m looking for people to test and provide feedback.

Interested? Check it out here.

The post WordPress Photoblog Theme 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.