[wp-trac] [WordPress Trac] #18561: Better Way to Insert Things Below Individual Posts
WordPress Trac
wp-trac at lists.automattic.com
Wed Dec 21 17:36:54 UTC 2011
#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
More information about the wp-trac
mailing list