Featured images (also referred to as “post thumbnails”) are nice features to include in WordPress themes, but there are times where I question their implementation.
I know, I know: talking about stuff like this can come off as frivolous, but I think that if you deeply care about what you’re working on, then evaluating the decisions – every one of them – that go into your product matters.
And since featured images are a decision that need to be made when working in theme development matter, then it’s worth evaluating their implementation.
The Challenges of WordPress Featured Images
Sure, the purpose (well, purposes) they serve is great. As explained in the Codex:
Post Thumbnail, now Featured Image, is an image that is chosen as the representative image for Posts, Pages or Custom Post Types. The display of this image is up to the theme. This is especially useful for “magazine-style” themes where each post has an image.
And from a developers standpoint, it’s really easy to include support for them in your theme, but from a user’s perspective, I think that it still leaves something to be desired.
I think that there are times that it makes sense to use featured images, but then I also think that there are times where using features images isn’t necessarily the best idea.
Something as simple as featured images can’t really present that many challenges, right? For some, maybe not. For others, maybe so.
I’m of the latter.
Through Our Developer Goggles
When I look at the purpose of featured images and I look at how various themes implement them, I can’t help but think that sometimes we – as developers – put our developer-goggles on and end up building support in for the featured image rather than thinking about the actual user experience of them.
Probably the coolest set of goggles I ever owned.
For example, one of the things that I love most about WordPress is support for editor-style.css. That is, I love the fact that we can style the way elements look within the post editor such that we know how it’s going to look on the front end.
This reduces saving drafts, toggling back and forth to the public view of the site and the editor, and overall closes the gap between what the user is typing (or, rather, what they see) and what they will see when the post is published.
This isn’t the case with Featured Images.
Instead, the option appears as a post meta box on the side of the post editor Dashboard and though it uses nice features, such as the Media Uploader, it doesn’t give the user a sense for how the image is going to be presented within the context of the post.
There is a disconnect between what the user sees in their post editor and how the post will be displayed to site visitors.
Sure, you can argue that once the user has defined a post thumbnail and then generated a preview of the blog, then they have an idea, but does the fact that users have to toggle back and forth between views to get a feel for how it works undermine features like editor-style.css?
I mean, if you’re going to have to toggle back and forth between views at all, should we even bother with styling the content of the post editor?
Of course! Just because a single feature has you swapping between views of a site doesn’t mean that we still shouldn’t strive to close the gap of what the user sees and what they experience.
If nothing else, it “lightens to load” of what the user has to process when they hop over to the public-facing view of the site: All they have to look at is the post thumbnail – not the post thumbnail, headlines, images, paragraph text, un/ordered lists, anchor, quotes, and so on.
Anyway, this still doesn’t get us to solving the challenge that featured images present: When should themes implement them, and when should they not?
An Implementation Dilemma
My rule of thumb is this: If the feature image is something that can’t be done within the post editor, then add support for featured images.
For example, let’s say that your featured image is going to be displayed at 100% width under the post title and post meta data but before all of the content in the post. This is something that can be done using the post editor and the media uploader – just drop an image in before your content, right?
But if your post thumbnail is going to be a small image beside the post title or appear, say, above (or maybe even behind in some rare, creative cases) the post title and post meta data, then it makes sense to implement the feature.
This still leaves a problem, though: What do we do about various plugins and/or third-party sites and tools that look specifically for a post thumbnail when generating a link to the site?
In some cases, larger sites are pretty good at being able to grab the first image from the post (or even the first few images of the post) and letting us set them as a featured image in a link. Other times, an image simply won’t be retrieved.
If you’re a WordPress developer and you’re writing tools that look specifically for featured images, then I’d urge you to consider broadening the scope of your feature just a bit so that it looks for at least the first image in the post.
None Shall Pass; You Shall Not Pass The Impasse
If you’re someone who doesn’t incorporate featured images into your theme, but want to be able to leverage the functionality of a third-party service that expects a featured image, then you’re somewhat at an impasse:
- Add support for featured images and break the user experience
- Don’t add support for featured images and lose third-party functionality
Is there a third option? Maybe. It’s weak, though.
- Duplicate the featured image functionality so that whatever image is set as the post thumbnail also displays in the post editor above the post content (if – and only if – the image is going to appear between the title, post meta data, and the content).
Honestly, though I think this is a workable solution, I’m not a fan of it because it negatively impacts the user’s experience. How do you delete the featured image? Using ‘Featured Image’ meta box or using the post editor? Is the featured image controlled by the meta box, by the media uploader, or both, and so on.
Though I lay all of this out, I’ve already shared my stance on it and it can be simplified as this:
If it can’t be done with the post editor, then implement the post thumbnail feature.
As far as third-party tools and utilities are concerned, it just doesn’t make that big of a difference to me (nor have I heard a convincing argument as to why it should). I haven’t seen a case where a utility hasn’t pulled in an image, hasn’t allowed me to select from a set of images extracted from the post, upload my own image, or tastefully display post information without a featured image.
More WordPress Navel Gazing
I know that stuff like this can sometimes come off as pointless to think about, or as something that isn’t a big deal, but the thing is that I do think it matters if you deeply care about the things that you’re building for other people.
Navel Gazing. Literally.
And questioning every little feature, detail, and nuance of what you’re going to release matters even if it’s something as trivial as a featured image because I think that the little decisions within a broader scope of a project end up making or breaking how a person feels about a product once they’ve used it.
I think one of the big (dare I say, basic) issues surrounding the usability of WordPress featured images is context. Without clear, identifiable (to the user) context, the featured image box is inherently ambiguous. Some themes use a featured image one way, others use it another. I’ve seen lots of instances of “where does this actually pop out on the front end?”.
Posts, food menu items, speakers, galleries, todo lists etc etc all use a featured images in different ways. In the context of blogging, the featured image meta box sits well. You expect, for a blog post that the featured image will appear as the lead image for that post.
What I would like to see, is the ability to contextualise within the featured image API. Supports featured image is not enough. Even something so simple as defining featured image labelling per post type would be an improvement i.e. Featured Image – Speaker Profile image.
Nailed it. This is why I think adding support for it should be done so sparingly – the user isn’t completely sure where the image will appear until after they’ve added one, saved a draft, and previewed the post.
That’s an interesting idea. Cool :).
Great post brother, I whether I delivered mine correctly or not on my rebuild, I did think long and hard about what and how I wanted to present the images to the readers.
Yep – the little things need considerations, too :).
I never think of this, but reading your possible solutions got me thinking that there’s one more possibility:
Find first images when the post / content is saved or published then stored it as post meta. I think
transition_post_statushook will do the work. On the template side, replacethe_post_thumbnailwith custom made template tag that will:Look for WordPress’ featured image
If we couldn’t find WordPress’ featured image, pull the first image stored on the post meta
If there’s no image at all, pull default image
To support images which are added before the theme is activated, a plugin that will loop on the previous post to find first image and store it as post meta should be developed.
That sounds workable to me. What do you think?
This sounds like something that’d make an experimental plugin, but I wouldn’t want to see it in core because it still breaks the experience of what the user expects to happen.
In this case, though, they don’t necessarily know that the first image is going to be set as their featured image. When they know that, it may end up impacting the images they select for their post.
Ultimately, it comes down to making sure that users are well aware of how what they’re doing will appear on the front end of the site.
“so that it looks for at least the first image in the post.”
I have done this several times but I must say there are times when no featured image is desired and the post ends up slapping some random image to represent the post in archives or search results.
I actually find myself needing both a thumbnail image (for archive or other areas) and a true “featured” image as in a post head. Usually this needs to be placed by the developer in a way that the image does not expand beyond a certain height or maybe you want it below the date and author, etc. Leaving the post layout entirely to the end user will surely result in inconsistencies. That is where we as developers need to set rules and boundaries for these types of things.
All in all, I really don’t see a need for a change because developers need a way to target things consistently for design and functionality purposes and this is the best way for now. For example, the post date or author is not in the edit area itself, yet it appears on the front end in the template.
This usually (though not always) is a result of the other site grabbing the first image it finds in the content and treating it as the featured image.
Completely agree with you!
Agree up to a point – it may be the “best way for now,” but it’s really the only way and we shouldn’t confuse the two. To that end, I think we need to come up with something that’s a little more user friendly than disjointing the featured image so much for the content.
Of course, having a programmer go in and add code that has no UI and has inconsistent results for the users can be disruptive, too. There’s a balance to eventually be struck.
I totally agree with this point. It confuses many beginners. First of all they have no idea what image size is ideal to go with their theme. Secondly, they have to learn it the hard way by setting up a featured image, previewing it, edit the image, reset featured image, preview again.
I think it would be nice if there were pointers used after theme activation to let users know the ideal size for featured image.
If you mean the WordPress pointers that showed up earlier in the 3.x versions, then I dunno – I find those distracting; however, having a short description above the anchor for adding a featured image could go a long way in leveling out expectations, IMHO.
“If you’re a WordPress developer and you’re writing tools that look specifically for featured images, then I’d urge you to consider broadening the scope of your feature just a bit so that it looks for at least the first image in the post.”
The issue there Tom is – to the best of my knowledge – WP doesn’t have any function to do that. So it would mean writing a regex to find the first img tag, look for the class “wp-image-XXXX” and extract XXXX which is the attachment ID.
Some will say WP provides functions to get attachments. The problem is attachments stay attached even if they are removed from the post.
Attached and embedded are two quite different states.
This has been an issue I’ve dealt with regularly over the last four years with plugins that look for the first attached image.
Thinking about it, I could get the first attached img src, see if it is in the content. But damn that is still messy and hacky.
Either way seems to involve scanning the content, and is hacky.
So, I strongly encourage the use of featured image when it may be used as more than just the first inline image. e.g. in sliders, magazine-style excerpt layouts, etc
BTW I am hoping you or someone will say, “Geez, Chris, ya numpty! Didn’t you know about function wp_xxxxxx() that grabs the first embedded image?!” This is one time I’d really like to be wrong!
OT: What flavour of Markup do we use in comments here?
Markdown :)
Ik. Thought about it and decided to do the regex. It doesn’t seem to slow things down too much. Tho still feels hacky.
$thumb_id = get_post_thumbnail_id();
if (!$thumb_id) {
preg_match("/(?<=wp-image-)(\\d)*/uimx", get_the_content(),$matches);
$thumb_id = (!empty($matches[ 0 ]) ? $matches[ 0 ] : false);
}
So that gives me the featured image, and if not available, then the first image in the content. And if there isn't one, then no image.
If you wanted to get all the images in the content, preg_match_all would be used.
I think you can use
get_attached_mediato find the images that are still attached to the post.I don’t know if the order in which they are returned are consistent with the order in which they are added to a post, though – I’d venture to say that they are ordered by the ID of their attachment, so you’d still need to run a comparison between the attached images and its place in the post.
At any rate, using
has_post_thumbnailalong withget_attached_mediamay go a long way in helping to automate some of this.Thanks, Tom. Tested and it does the same thing. Returns all attached images, whether embedded in the content or not. :(
So, besides my hacky regex, still no luck with a WP function that returns attached images that are also embedded.
Hmm, in my (limited) experience, my instinct has always been to see what I can use from WordPress out of the box versus creating additional fields or functionality if I don’t have to – so the same logic goes for featured images. Is that not always how developers should be tackling projects?
I can understand the disconnect UI wise if you can preview content on the dashboard, but not with the image, but that’s also assuming that there isn’t a really complex design where even the editor style wouldn’t really give you a realistic preview of the post (e.g. a “post” with custom fields or a layout that isn’t simply just a date/title/content – a good example would be perhaps a masonry layout where posts take on this “pinterest” feel and have let’s say, an image to the left/right and content opposite of it.)
So maybe the editor style can help give an idea of previewing the single view of a post, but depending on design, would still lack replicating the experience 100%. And so if that’s the case, then the featured image feeling detached from UI would be irrelevant, correct?
I’ve also had some 50/50 experiences with just using the first image in the content as a fallback – there was a case where posts were imported from a non-WordPress site and the structure of the content was terrible. (Think empty divs and empty p tags and no one was going to go into their billion posts and correctly format them – eek!) The imported content didn’t have the new design in mind, and so, any images it grabbed, even with some css tweaks, it didn’t always have favorable results on the front-end. Because of that, I’d almost rather provide a required custom field or some other way to guarantee a good fallback versus depending on an image from imported posts that may be a mess? Or maybe even a placeholder? Would love to get your take on this.
This post has given me some food for thought though – and I think I’ll definitely re-evaluate using featured images from this point on. Thanks for sharing your thoughts on it! :-)