[wp-trac] [WordPress Trac] #18561: Better Way to Insert Things Below Individual Posts

[WordPress Trac]

#18561: Better Way to Insert Things Below Individual Posts
-------------------------+------------------------------
 Reporter:  jane         |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  3.2.1
 Severity:  minor        |  Resolution:
 Keywords:               |
-------------------------+------------------------------

Comment (by chipbennett):

 Replying to [comment:113 aaroncampbell]:
 > > I think `post_intents()` in this case is a bit more descriptive than
 `post_extras()`.  We have a lot of things in the WP ecosystem that are
 poorly named as is ... so let's try to keep an eye on what it is we're
 trying to build, what standards we may/may not be trying to reflect, and
 try to keep on target.  "Extras" is too ambiguous IMO.
 >
 > It was the first thing that came to mind.  I'm on board with
 `post_intents()` if that's the way we decide to go.  Having said that, I'm
 not sure that everything that would go in that area would be web intents.

 At the risk of bike-shedding, might I suggest `post_meta` or
 `post_metadata`?

 I ''do'' like the idea of having such a hook, separate from `post_before`
 and `post_after`, so that the Theme developer has more flexibility in
 putting the Post's "meta" information (which could include social links,
 taxonomy, author info, timestamp, etc.) wherever is appropriate for the
 Theme.

 Replying to [comment:113 ericmann]:
 > As much as I like the idea of a set of hooks, I think that many hooks
 might just clutter things up. Don't get me wrong, I like having plenty of
 hooks, but some of the advanced "frameworks" out there already do this.
 And some are essentially unapproachable for newer theme devs. I get more
 "how do I do X with Genesis? I can't find the right hook!" emails than
 anything else.

 The "frameworks" should be able to support standard hooks with little to
 no problem.

 I use hooks in Oenology, and don't see any problem with incorporating
 standard hooks. For example, for the `body_before` standard hook, I have
 one called `oenology_hook_extent_before`, that gets called via custom
 function `oenology_hook_post_before()`:

 {{{
 function oenology_hook_post_before() {
     do_action( 'oenology_hook_post_before' );
 }
 }}}

 To incorporate the standard hook, I could just change that to:
 {{{
 function oenology_hook_post_before() {
     do_action( 'body_before' );
     do_action( 'oenology_hook_post_before' );
 }
 }}}

 (There are other ways, of course; that's just one.)

 The "framework" Themes would be free to include ''other'' custom hooks, of
 course - but that shouldn't preclude them from supporting standard hooks.
 But ultimately, the sooner that core establishes a set of standard hooks,
 the sooner the developers of the "framework" Themes can be encouraged to
 begin to integrate support for those standard hooks in their Themes.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18561#comment:114>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software