Standardized "Meta" Hooks

[mtekk]

While THA currently provides a nice basic set of theme hooks, for some common theme features there is not an obvious choice to use among the existing hooks. Case in point, breadcrumb trails. While one could assume they belong within tha_header_bottom, tha_header_after is still a valid location, as are a few other places. This ambiguity makes it difficult for plugins to hook into the correct spot (have to start making bad assumptions).

It would be nice to have something like tha_breadcrumbs (preferably a filter). While a call to it could be placed directly within a theme (via something like tha_breadcrumbs()), the way I see it being used is within a function that hooks into an already existing THA hook (such as tha_header_after). Hence why I called it a "Meta" hook.

This was spawned by the discussion between Ryan and Brian on the WP Candy Podcast Ep. 34.

[zamoose]

Hmmm. This definitely bears some further thinking -- most of (if not all of) the rest of the hooks have been of the positional variety, while these are more semantic.

Can you think of some other such "meta" hooks that would make sense in your typical use case?

[chipbennett]

This definitely moves away from template location-based action hooks, into contextual content filters. If we can standardize on these as well, it can only help the overall goals of the project.

The only problem is that implementing such filters universally would be much more tricky, because while adding in a do_action() at a semantic template location is trivial, passing content through an apply_filters() call is non-trivial. Most Themes don't currently pass their content through such filters, and implementing them would require much more effort.

That said: most Themes that currently implement custom hooks implement both action hooks and filter hooks. So, adoption of standard filters would be simple. Here are all the filters I currently use in Oenology:

• loop_footer
• loop_header
• loop_no_posts
• post_404
• post_footer_avatar (could genericize as post_author_avatar)
• post_footer_license (could genericize as post_license)
• post_footer_metadata (could genericize as post_meta)
• post_header_date_year
• post_header_date_weekday
• post_header_date_day
• post_header_date_month
• post_header_date (could genericize as post_date)
• post_header_metadata
• post_header_taxonomies (could genericize as post_meta_taxonomies)
• post_header_title (could genericize as post_title)
• post_header_thumbnail (for featured image in the post header)
• site_footer
• site_header

Definitely breadcrumb_navigation should also be on the list. (I need to implement a filter for that in Oenology)

So, here would be my starting list of suggested filters:

• tha_breadbrumb_navigation
• tha_loop_footer
• tha_loop_header
• tha_loop_no_posts
• tha_post_404
• tha_post_meta
• tha_post_meta_author
• tha_post_meta_avatar
• tha_post_meta_date
• tha_post_meta_taxonomies
• tha_post_title
• tha_site_footer
• tha_site_header

[mtekk]

I guess I see this from a plugin author's point of view (as someone who happens to write a very popular breadcrumb plugin), hence the specific example. Using a filter, to me, makes more sense for the specific case of breadcrumb navigation. A theme may provide basic functionality for this, but a more advanced plugin may want to replace the entire contents with its "better" trail. A filter allows this without having to know (or determine) the vendor specific function hooked and unregistering it.

Initially, when I was thinking about this, the other uses were navigation related, such as archive traversal (older, newer post links, replacement with other things such as pagination) could benefit from this as well. Though, I agree with Chip's take on this.

[chipbennett]

I guess I see this from a plugin author's point of view (as someone who happens to write a very popular breadcrumb plugin), hence the specific example.

Absolutely!

In fact, in Oenology, I use a similar approach (that will shortly be converted to a proper filter) in which I check for Yoast Breadcrumbs, and let it override my Theme's breadcrumb output. Using a filter would prevent Theme developers from having to check explicitly for every known type of Plugin - once Plugin developers implement the filter, of course.

I think the navigation-related content would generally fit into filters such as loop_header and loop_footer (which, I assume, would in turn be output via loop_before and loop_after). But the nice thing about using the filters is that they leave the Theme developer free to determine where in the template a certain type of content is output, while retaining the ability for Plugins to override the specific content.

In other words: as the Theme developer, I can decide where in the template I want the breadcrumb navigation to be output, while still enabling you, as the Plugin developer, to override the breadcrumb content (without needing to know where in the template that content is being output).

Needless to say, I'd love to see this make it into the Theme Hooks Alliance code.

[mtekk]

But the nice thing about using the filters is that they leave the Theme developer free to determine where in the template a certain type of content is output, while retaining the ability for Plugins to override the specific content.

Exactly! Doing this makes themes extensible in a practical manner and everyone's life a little easier.

[zamoose]

Someone throw up a pull request with perhaps an additional example file and/or a tha-meta-hooks.php.

[teohhanhui]

Just to add to the use cases:

I needed a tha_comments filter hook, where the callback gets passed the entire output of the comments template. Similar to WordPress core's the_content filter hook.