A few months ago, WordPress UX Lead Jane Wells posted a request to WordPress’ Trac ticketing system. The idea was to find a better way to insert “stuff” below WordPress posts:
Inserting the sharing and like rows at the bottom of the post text before the byline/classification metadata seems wrong. It should go below that, so it is closely related to commenting, not part of the content itself. The plugin-generated widget is not “by” the post author, after all.
I haven’t used very many social media plugins for exactly this reason. Nor have I ever used a “related posts” plugin. They always seem to conflict with one another and build up a bunch of unnecessary cruft below my content.
So for the past few months, I’ve been thinking about different ways to handle this.
The Art of Manliness adds an author box, a Facebook "like" button, a related content gallery, and a subscription feature to the bottom of each post.
Template Parts
My first idea was to just use a template region within a WordPress theme.
Each individual theme would call some variety of get_template_part() to set up whatever region is being used.
Plugins would then provide content for these templated regions. So get_template_part('social_media') and get_template_part('related'), for example.
The problem with this, though, is one of standards. What template regions will be supported? How will new ones be developed? After the battle over post formats, this isn’t a particular standard I want to battle.
Post Intents
Another developer suggested modelling system after the emerging Web Intents standard.
Basically, a new function would be added to WordPress to output various registered post intents – share this, “like” this, subscribe to updates, etc.
Individual plugins would then register these intents and their various actions, but leave it to the theme to style the presentation.
I was entirely sold on this idea. Well, until a long Twitter conversation with Helen Hou-Sandi:
When you take things like photo galleries, related posts, and actions other than social media integration into account, the concept of post intents no longer makes sense.
New Action Hooks
Chris Pearson add a personal "follow me" Twitter link, a "Tweet this" link, and several other action items below his posts.
I love having a large number of action hooks to use when I’m building a theme. I can move content around, add custom views to my content, manipulate the display. The sky’s the limit.
So when several developers suggested that we just add a few action hooks before and after the post content, I was intrigued.
But really, this is what themes are already doing. And merely adding a few extra action hooks just gives plugin authors the ability to inject their own markup into the flow of your otherwise well-built design.
Considering some of these add-junk-to-the-bottom-of-my-content plugins already break the display, why would they function any different if I gave them a specific hook to tie in to?
My Proposal – Post Supplements
Instead, I have in mind a hybrid of a new action hook and registering a new object: post supplements.
Think about widgets for a second. There’s a specific area to display widgets (the sidebar), each widget is registered with WordPress and placed in this area, and a well-coded widget leaves much of its markup to the theme (before_widget and after_widget).
So think of two things:
- A new object defined by WordPress:
WP_Supplement - A new action hook/function used by WordPress to output registered supplements in the theme
The theme can register supplements (one for sharing, one for related posts, one for a photo gallery, one for an about-the-author box, etc). Various plugins can also register supplements.
Then, just like with widgets, these supplements can be added to the theme.
Widgets use add_action( 'widgets_init', create_function( '', 'register_widget("Foo_Widget");' ) );
Supplements could use add_action( 'supplements_init', create_function( '', 'register_supplement("Foo_Supplement");' ) );
Decisions, Not Options
I don’t envision a UI for this feature. Everything can be handled programatically – supplements appear on screen in the order in which they were added to the system. Likewise, they can be unregistered the same way.
This keeps the WP interface lean and mean, but still gives us a more efficient way to add content to a post in exactly the place the theme designer intends: do_action( 'post_supplements' ) or wp_post_supplements().
The theme designer would be in complete control of the position of these elements, what styling (if any) separates them from the content of the post, and what styling (if any) distinguishes them from one another.
This would be non-trivial to build, so before I dig in to the code I want to solicit feedback on the idea.
Does this make sense from a usability standpoint?
Yes, public evidence that I win!
This is totally going above and beyond what I was thinking about – I was literally thinking about just add_theme_support() and a new template tag that was just a do_action() wrapper. I think there might even be a patch or two on #18561 to that effect.
I think I like where this is going, but I need to chew on the overall class/object part some more. I am also not sold on the supplements moniker, somehow. Basically, though… so long as additions (supplements!) are able to be unhooked elsewhere and reordered programmatically, I’m good with it. It’s awesome to see where my likening to widgets took your mind! I think this makes you the genius
I’m not totally committed to the “supplements” moniker just yet. I won’t be bound to a name until I (or someone else) actually writes up some code. I just want to avoid something overly ambiguous like “extras” or too steeped in existing paradigms like “widgets.”
But it would definitely need to be paired with a theme_supports() check for backwards compatibility.
Interesting…
Since you’re likening this to widgets I wonder why not just use a custom sidebar in your loop includes? I think you could get the functionality you want and get the built-in UI you’re proposing not to build.
My brain isn’t fully wrapped around this, and I suspect there’s an easy answer.
Two reasons:
1) To separate this entirely from sidebar widgets. Right now, a lot of plugins just add filters to `the_content` in order to add their extra displays at the end of individual posts. This is bad, and the practice Jane’s original ticket hopes to fix.
2) I don’t want to add a UI for this at all. Not that I don’t want to build one, but this isn’t the kind of thing you’ll be configuring too much, and adding an extra UI module to WP just to set up the “extras at the bottom of the post” is too much overhead.
I really like the widget comparison, but I would think it needs to be taken a step or two further.
Site owners are really going to want to be able to control what order their “supplements” go in (in the example you gave, the author bio first, and subscription banner last makes a lot of sense and wouldn’t make as much sense if it were done the other way around) – and I could also see the need to display a different list of supplementals based on post type, category, etc.
Why wouldn’t you simply create a wrapper around the existing WP_Widget class and add a UI for that?
That’s definitely a possibility … but I’m hoping we can solve the issue without making WP more complicated.
Right now: there’s a UI for managing widgets (sometimes for several different sidebars), a UI for managing which plugins are adding content to your site, separate UIs for many of these plugins, a separate UI for managing page menus … for someone who’s goal is to just write this is burdensome and distracting.
But more tech-savvy developers should still be able to modify things and choose their own order. Which is why I suggested action hooks. They have built-in priorities, but can be unhooked and re-ordered to at the developer’s pleasure.
Oh — by which I mean that I suspect there’s an easy answer to my question — not an easier answer to your problem. ; )
There is a fundamental difference between these “supplements” and widgets. These supplements are meant to be tied to the post’s content as a part of the loop, not as a part of the overall template. Yes, there needs to be flexibility for the theme author to choose how they are placed, but on a base level they need to be related to a post’s content, whereas a widget area is more related to the layout of the template being used. I hope that makes sense outside of my own head.
To illustrate, I’ll offer up my own blog, which is a very lightly modified version of BonPress: http://blog.helenyhou.com/ . If you look at archive pages, the share buttons (so yes, intents in this case) appear in the meta of the post in the loop, after the_content(). But if you look at a single post (e.g. http://blog.helenyhou.com/2011/10/cooking-project-atks-cooking-for-two-2011/ ), you’ll notice that the buttons are now up at the top, still with the post’s meta, but before the_content(). In neither place do these buttons show as in the actual content area itself, and perhaps they shouldn’t, because they are not content. Filtering the_content() to achieve these additions is not only not flexible, as the ticket was created to address, but is also not really semantic at all. I had to place these buttons myself, in the code. If I want to change services, or if AddThis updates something, I will have to do it again myself instead of just updating a plugin. Plus, your average user, and especially those on WordPress.com, can’t or won’t edit template code.
Also, there is definitely core lead support for per-page widget UI, but somebody needs to come up with a user-friendly of doing it. I think adding yet another drag and drop area named something totally different would actually defeat ease-of-use – if something should be a widget, then it should be in a widget area, which really can be placed anywhere, not just in a sidebar (but I’ve not seen one used in a loop, and the idea of widgets that can *only* be used for an individual post would not make sense to your average user). This particular template tag should really just contain things that you can turn on or off. If you *really* want to reorder them, you can dig in, but I think it should stay simple. We as developers often forget that your average user wants it to “just work”, and having the need to go into yet another interface and drag them into place, especially if you’re just turning on one (which again, I would guess many or most would do), seems to over-complicate the matter.
It does, and is exactly my point and why I shied away from calling them “widgets,” I only meant to convey a passing similarity with an already well-understood feature. These “supplements” are more contextual than widgets and must be germane to the content to which they’re bound.
I should have specified that I was really replying to other comments, but I’m sure you understand that, too! Threaded comments suddenly seem inadequate (kidding, kidding, can’t imagine how it would work otherwise.)