Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Standardized "Meta" Hooks #9

Open
mtekk opened this Issue · 6 comments

3 participants

John Havlik Doug Stewart Chip Bennett
John Havlik

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.

Doug Stewart
Owner

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?

Chip Bennett

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
John Havlik

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.

Chip Bennett

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.

John Havlik

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.

John Havlik mtekk referenced this issue in mtekk/Breadcrumb-NavXT
Closed

Theme Hook Alliance Support #30

Doug Stewart
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.