Make WordPress Core

Opened 12 years ago

Closed 8 years ago

Last modified 8 years ago

#21506 closed enhancement (wontfix)

Standard Theme Hooks

Reported by: mfields's profile mfields Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Bundled Theme Keywords: dev-feedback
Focuses: Cc:

Description

During the hack day at WordCamp SF, Konstantin Kovshenin and I sat down to work out a solution to allow for better communication between themes and plugins. We propose that core introduce 4 new hooks into the default WordPress themes allowing plugins to add custom markup relative to common theme elements. While many other theme locations could be recognized, we have only included hooks that we could provide at least three use common use cases for.

header_after: Allows custom markup to be inserted after all visual header elements have rendered. Possible use cases for this hook include:

  • Breadcrumb navigation.
  • Links to social profiles.
  • Advertising.
  • log in/out form.

post_after: Allows custom markup to be inserted after all visual elements have rendered for the current global post object. This hook would fix the issue originally reported in #18561. Possible use cases for this hook include:

  • Sharing links.
  • Related posts.
  • Ratings.
  • Author bio.

comment_after: Allows custom markup to be inserted after all visual elements have rendered for the current global comment object. Possible use cases for this hook include:

  • Upvote/Downvote control.
  • Ratings.
  • Show/hide threads functionality.

footer_after: Allows custom markup to be inserted after all visual elements have rendered for the footer. While this action is similar to wp_footer, it would be possible for the theme author to move this into nested html elements. To my knowledge, wp_footer is intended to fire immediately before the closing body tag. Possible use case for this hook include:

  • Links to social profiles.
  • Advertising.
  • The "small print" or copyright information.

If standardized hooks such as these were recognized by core, it would also have a positive effect on child theming. Theme authors would no longer need to override entire files just to introduce an element of two.

We have prepared 3 patches for the default themes to demonstrate placement of these hooks as well as a plugin to demonstrate their usage.

Attachments (6)

21506.twentyten.diff (5.8 KB) - added by kovshenin 12 years ago.
Theme hooks for Twenty Ten
21506.twentyeleven.diff (11.1 KB) - added by kovshenin 12 years ago.
Theme hooks for Twenty Eleven
theme-hooks-test.php (3.0 KB) - added by kovshenin 12 years ago.
Proof of concept plugin with dummy data
21506.twentytwelve.diff (7.6 KB) - added by mfields 12 years ago.
general-template.php.template-hooks.patch (7.2 KB) - added by chipbennett 12 years ago.
First pass at core-defined template hooks for use by Themes
general-template.php.patch (1.1 KB) - added by barrykooij 12 years ago.
Added '_after' hooks.

Download all attachments as: .zip

Change History (102)

#1 @iandstewart
12 years ago

  • Cc ian@… added

@kovshenin
12 years ago

Theme hooks for Twenty Ten

@kovshenin
12 years ago

Theme hooks for Twenty Eleven

@kovshenin
12 years ago

Proof of concept plugin with dummy data

#2 @kovshenin
12 years ago

  • Cc kovshenin@… added

#3 @hd-J
12 years ago

  • Cc jeremy@… added

#4 follow-up: @westi
12 years ago

  • Cc westi added
  • Keywords dev-feedback removed

I like this alot.

Although we can use do_action in themes like this I wonder whether or not we should wrap the calls like we do for wp_head etc. so that it is even simpler to use in themes.

I would love for us to make this part of 3.5

#5 in reply to: ↑ 4 ; follow-up: @mfields
12 years ago

Replying to westi:

I think that wrapping the hooks in functions like wp_head() would be a great idea. One reason that they were not implemented into the patch for Twenty Twelve was because this theme will need to be backwards compatible one major version. Introducing new functions into the template would break compatibility.

One idea is to introduce these functions into core, but use only the hooks in the bundled theme. When the next version of WordPress is released the hooks can be replaced with the appropriate functions. There may be other, better ways to deal with this too. Just a thought.

#6 @philiparthurmoore
12 years ago

  • Cc philip@… added

#7 @toscho
12 years ago

  • Cc info@… added

#8 @Mamaduka
12 years ago

  • Cc georgemamadashvili@… added

#9 @ocean90
12 years ago

  • Cc ocean90 added

#10 @demetris
12 years ago

  • Cc dkikizas@… added

#11 @obenland
12 years ago

  • Cc konstantin@… added

#12 @sabreuse
12 years ago

  • Cc sabreuse@… added

#13 follow-up: @wycks
12 years ago

  • Cc bob.ellison@… added

What about some before's as well?

before_header
before_loop
before_comment
before_footer

#14 @DrewAPicture
12 years ago

  • Cc xoodrew@… added

#15 in reply to: ↑ 13 @kovshenin
12 years ago

Replying to wycks:

Although the hooks sound like valid ones, we should probably think of possible use cases too, similar to what @mfields did in the ticket description. Can you think of several possible use cases for the hooks you proposed?

#16 follow-up: @iandstewart
12 years ago

I'll preemptively argue against before_header. :) Almost anything I can think of adding to this hook (menus, ads, search forms, etc.) can be positioned visually above the header with CSS while hooking into an after_header hook. Additionally, not using before_header is likely to encourage a semantic outline for our WordPress generated web pages and is likely friendlier to screen readers.

My feeling is that this will also be true for most before_ hooks.

Last edited 12 years ago by iandstewart (previous) (diff)

#17 @lancewillett
12 years ago

  • Cc lancewillett added

#18 in reply to: ↑ 5 @westi
12 years ago

Replying to mfields:

Replying to westi:

I think that wrapping the hooks in functions like wp_head() would be a great idea. One reason that they were not implemented into the patch for Twenty Twelve was because this theme will need to be backwards compatible one major version. Introducing new functions into the template would break compatibility.

One idea is to introduce these functions into core, but use only the hooks in the bundled theme. When the next version of WordPress is released the hooks can be replaced with the appropriate functions. There may be other, better ways to deal with this too. Just a thought.

Backwards compatibility is pretty simple :)

You add a compat.php file into the themes which contains the function definitions wrapped in function_exists checks.

#19 in reply to: ↑ 16 @wycks
12 years ago

Replying to kovshenin:

Replying to iandstewart:

I actually though it would be more semantic , it's a little confusing to use a hook that says "after_header" for something before the header.

It might also be a matter of simplicity if added to the core as a hook, for example if you need to place an advert above the header you can just hook into it without having to go in and adjust the html/css markup.

I am referring more to it's usage as a core hook then in a twenty(x) theme, though I agree that it's probably not worth the overhead, just a thought.

#20 @bradthomas127
12 years ago

  • Cc bradthomas127@… added

#21 follow-up: @kovshenin
12 years ago

I think we should stop using "advertising" or "ads" when talking about use cases for theme hooks, because ads can be literally placed everywhere, even after_first_paragraph_of_the_content ;) Creating standard hooks mainly for advertising is overkill.

Re: header_before and header_after, I agree with Ian, especially with the accessibility part. I think the first thing that should be read out by a screen reader is always the site name, then the navigation menu, but definitely not an ad.

#22 @beaulebens
12 years ago

  • Cc beau@… added

#23 follow-up: @greenshady
12 years ago

  • Cc justin@… added

If the goal is standardization and to get theme authors on board, just offering *_after hooks won't cut it. The way I see it, it's practically useless to have the four proposed standard hooks for *_after but have non-standard hooks for *_before.

Basically, if I created a theme called "Awesome", I'd have these hooks (following .ORG theme repo guidelines, of course):

awesome_header_before // custom hook
header_after // WP hook

awesome_post_before
post_after

awesome_comment_before
comment_after

awesome_footer_before
footer_after

That's actually worse than not having any sort of standardization.

The proposed idea is a step in the right direction, but I could never see myself using it as a theme developer because it would confuse all but the most WordPress-savvy of my users who actually use hooks.

#24 in reply to: ↑ 23 ; follow-up: @kovshenin
12 years ago

Replying to greenshady:

I'm okay with adding more hooks to the initially proposed list, but in order to do so, we have to justify the hooks with use cases. We can't say we need a header_before hook just because we have a header_after hook, right? It's easier to add more standard hooks at a later stage, but not as easy to remove/deprecate them. What would be the use cases for header_before?

#25 @toscho
12 years ago

header_before would be useful to add a skiplink per plugin to themes missing one. Source code order matters here.

#26 @DrewAPicture
12 years ago

I agree with @greenshady that symmetry in creating standard hooks *_before in addition to *_after is important to promote a widely adopted standard.

One solution specifically for the header_before / _after discussion might be to instead go with nav_before / _after.

I can demonstrate very few valid uses for header_before but several for nav_before such as logo/subscription/search-related bits (not to mention ads) and other historically header-related things. nav_after would generally serve the same purpose as header_after.

#27 in reply to: ↑ 21 @wycks
12 years ago

Replying to kovshenin:

I think we should stop using "advertising" or "ads" when talking about use cases for theme hooks, because ads can be literally placed everywhere..

Ok how about header-cats, pictures of cats that need to be in the header.

Joking aside, in terms of the vertical nature of the browser it just makes sense to be able to "hook" into a structural element below and above it. It's more flexible and it should't add any real overhead.

#28 in reply to: ↑ 24 ; follow-up: @greenshady
12 years ago

Replying to kovshenin:

Replying to greenshady:

I'm okay with adding more hooks to the initially proposed list, but in order to do so, we have to justify the hooks with use cases. We can't say we need a header_before hook just because we have a header_after hook, right?

I'd say wrong. We need that hook for the simple purposes of a wider adoption rate by theme developers and to develop a standard. There really is no standard if theme developers are having to create custom hooks to match the "missing" hooks from WordPress.

---

Based on my experience with theme users:

Of the proposed list, the most commonly-used hook is header_after. If adding the *_before equivalents, header_before would also be one of the most commonly-used hooks. The others are not used quite as much by users.

But, probably the most-used of all hooks in my themes would be the equivalent of content_before.

#29 in reply to: ↑ 28 ; follow-ups: @mfields
12 years ago

Replying to greenshady:
I'd say wrong. We need that hook for the simple purposes of a wider adoption rate by theme developers and to develop a standard. There really is no standard if theme developers are having to create custom hooks to match the "missing" hooks from WordPress.

I do not feel that the hooks suggested here would affect the adoption rate or interfere with hooks that already exist in themes. Themes could retain the current hooks that they are using to provide similar functionality as well as support the standard. For existing themes, this is probably the best way to go without breaking backward compatibility with custom plugins and child themes.

Perhaps "after" is not the best naming convention. This relative relationship naturally suggests that something is missing. maybe it would be better represented as ()using westi's suggestion about functions:

  • wp_masthead()
  • wp_post()
  • wp_comment()
  • wp_colophon()

There is no, before or after at all. Theme developers can use this function in the most appropriate place in their theme and plugins no not have to choose whether or not their markup should print above or below the element. The decision making is in the hands of the theme author.

The others are not used quite as much by users.

The purpose behind this proposal is to make communication better between themes and plugins. The only situation I could see an end-user directly interfacing with these hooks is in a parent-child theme relationship. Is this where you see users using hooks?

The problem that we would like to solve is plug-and-play functionality. This is why we've designed the hooks to support common functionality provided directly by plugins. Whenever I see "Open template-file.php and place the following code snippet in the appropriate place." in a plugin's installation instructions, I can't help wonder if there's a way to remove that step. Many end users are not comfortable modifying code and if there is something that we can do so that they do not have to, I think we should. A standard set of hooks is one method that could work.

But, probably the most-used of all hooks in my themes would be the equivalent of content_before.

Interesting. What are some examples of the code printed using this hook?

#30 in reply to: ↑ 29 @greenshady
12 years ago

Replying to mfields:

Perhaps "after" is not the best naming convention. This relative relationship naturally suggests that something is missing. maybe it would be better represented as ()using westi's suggestion about functions:

  • wp_masthead()
  • wp_post()
  • wp_comment()
  • wp_colophon()

That makes a lot more sense and would solve the issues I have with the initial proposed list. It's just natural to assume there's a "before" if an "after" exists. This would also give theme developers a little more flexibility as to where to add the hooks.

The only situation I could see an end-user directly interfacing with these hooks is in a parent-child theme relationship. Is this where you see users using hooks?

Definitely. All my theme users use child themes. It's been a requirement for support at my site for the last four years.

But, probably the most-used of all hooks in my themes would be the equivalent of content_before.

Interesting. What are some examples of the code printed using this hook?

Most often, users are adding an extra sidebar or banners/ads there. But, since we're not really addressing users here, it's not really relevant anymore.

#31 in reply to: ↑ 29 @iandstewart
12 years ago

Replying to mfields:

Perhaps "after" is not the best naming convention. This relative relationship naturally suggests that something is missing. maybe it would be better represented as ()using westi's suggestion about functions:

  • wp_masthead()
  • wp_post()
  • wp_comment()
  • wp_colophon()

There is no, before or after at all. Theme developers can use this function in the most appropriate place in their theme and plugins no not have to choose whether or not their markup should print above or below the element. The decision making is in the hands of the theme author.

This is a great idea.

#32 in reply to: ↑ 29 @kovshenin
12 years ago

Replying to mfields:

I also agree, so do you think the actions should be called wp_masthead, wp_post, wp_comment and wp_colophon respectively? I can rewrite the patches and the demo plugin.

#33 @toscho
12 years ago

Please, no. masthead has no clear meaning, this could be almost anywhere in the document. How can one target the real start of the document then?

Plus, the before and after combinations allow plugin authors to insert start and end tags for additional elements (think: reliable CSS selectors), something the standalone hooks just cannot do.

#34 @SergeyBiryukov
12 years ago

#21953 was marked as a duplicate.

#35 @thomask
12 years ago

Thanks, nice that we have same needs. One idea - what about wrapping whole header in simple filter - this way everyone here could do what he wants - before header, inside every part of header or after header, just by filtering the current output. And as added advantage, we could not only ADD something to the header, but also REMOVE it.

#36 @DrewAPicture
12 years ago

Related: #18561 - Better Way to Insert Things Below Individual Posts

Last edited 12 years ago by DrewAPicture (previous) (diff)

#37 follow-up: @sirzooro
12 years ago

  • Cc sirzooro added

#38 @chipbennett
12 years ago

  • Cc chip@… added

#39 in reply to: ↑ 37 @chipbennett
12 years ago

Replying to sirzooro:

Related: Theme Hook Alliance

I strongly recommend building off of the work already put into the THA, rather than attempting to reinvent the same wheel. I would love to see the entire THA codebase adopted by core, and given standard-core (i.e. un-prefixed) hook names.

#40 @ethitter
12 years ago

  • Cc erick@… added

#41 @rzen
12 years ago

  • Cc brian@… added

#42 @emiluzelac
12 years ago

  • Cc emil@… added

#43 @cais
12 years ago

  • Cc edward.caissie@… added

#44 @mercime
12 years ago

  • Cc mercijavier@… added

#45 @garinungkadol
12 years ago

  • Cc garinungkadol added

#46 @mfields
12 years ago

With 3.6 planning most likely happening soon I would like to request that this ticket be elevated to a blessed task. It would be great to see a standard set of hooks used in 2013 as well as the other bundled themes. While I see the benefit of the smallest possible set (as outlined above), the flexibility of the THA might be the best way to go. I support both solutions with open arms.

#47 @BrazenlyGeek
12 years ago

  • Cc BrazenlyGeek added

While it may be seen as overkill, the added overhead of having abundant theme hooks is minimal. Most of my work with clients who use WordPress revolves around premium themes with dozens of hooks (okay, core WordPress probably doesn't need dozens), adding in all sorts of content into all sorts of contexts.

And the beauty of it is... This really is the simplest way of customizing a site. No messing with child themes, the core theme can be updated without overwriting anything, and all customizations are self-contained as a site plugin.

Still, having access to at least the major containers of the site (body, header, footer, article, sidebar) -- before & after -- opens up a world of customization possibilities that are both easy & mostly futureproof.

#48 @saltcod
12 years ago

  • Cc saltcod@… added

#49 @aaroncampbell
12 years ago

  • Cc aaroncampbell added

#50 @GeertDD
12 years ago

  • Cc geertdd@… added

#51 @MikeHansenMe
12 years ago

  • Cc mdhansen@… added

#52 @rachelbaker
12 years ago

  • Cc rachelbaker added

#53 @zamoose
12 years ago

  • Cc zamoose@… added

Can I weigh in in favor of more, rather than fewer, hooks?

*grin*

#54 follow-up: @chipbennett
12 years ago

If I were to create a THA patch for Twenty Thirteen, what would be preference be: naked do_action() calls in the template (e.g. do_action( 'post_after' ), or template tag wrappers with "standard" names (e.g. wp_post_after()), vis a vis wp_head() and wp_footer()`?

The former would require no core changes, but might be less intuitive. The latter would be more intuitive and would perhaps facilitate adoption as a standard, but would require a corresponding core patch.

#55 @mfields
12 years ago

IMHO the wp_post_after() approach suggested by westi would be best.

#56 in reply to: ↑ 54 ; follow-up: @aaroncampbell
12 years ago

Replying to chipbennett:
How many are you thinking there will be? 5 wrapper functions that just wrap actions seems reasonable. 50 doesn't.

#57 @sabreuse
12 years ago

I'd vote to go for the core patch approach -- better consistency with the way developers expect built-in hooks to work, and they're there for any theme devs who want to start working with them. Patching Twenty Thirteen only makes them a great example, but doesn't do nearly as much toward making them standard.

#58 @kwight
12 years ago

  • Cc kwight@… added

#59 in reply to: ↑ 56 ; follow-up: @chipbennett
12 years ago

Replying to aaroncampbell:

Replying to chipbennett:
How many are you thinking there will be? 5 wrapper functions that just wrap actions seems reasonable. 50 doesn't.

If I'm counting correctly: THA currently has 26 template hooks. (And not all are needed, IMO.)

That's why I would like consensus on the approach before proceeding: because whether 26 new function definitions in core is a good or bad thing, implementing this concept inconsistently would be an undoubtedly worse thing.

Personally, I don't think it is at all unreasonable.

@chipbennett
12 years ago

First pass at core-defined template hooks for use by Themes

#60 @chipbennett
12 years ago

Details of attached patch:

  • I started with the THA hooks, and changed the prefix from tha_ to wp_.
  • I excluded the the_head_top and tha_head_bottom hooks, as these are covered by wp_head
  • I renamed the tha_html_before hook as wp_doctype
  • I renamed the tha_entry_* hooks as wp_post_*
  • I renamed the tha_sidebars_* hooks as wp_sidebar_*
  • Total hooks added (25):
    • Doctype (1)
    • Body (2) - top/bottom
    • Header (4) - before/top/bottom/after
    • Content (4) - before/top/bottom/after
    • Post (4) - before/top/bottom/after
    • Comments (2) - before/after
    • Sidebar (4) - before/top/bottom/after
    • Footer (4) - before/top/bottom/after

I would like to get a yea/nay on this step, before trying to integrate into the default Themes.

#61 follow-up: @rzen
12 years ago

I think we could drop the wp_ prefix and just name the hooks literally (e.g. header_before). Personally, though, I think {$position}_{$location} reads more friendly, particularly when i'm thinking about it in the context of add_action( 'before_header', 'my_stuff_that_comes_before_the_header' );

But, I wouldn't be heartbroken if everyone else disagreed. I could certainly get behind standardizing on "wp_header_before" instead of "before_header" if it meant the difference between gaining standard hooks and forgoing them.

#62 in reply to: ↑ 61 @chipbennett
12 years ago

Replying to rzen:

I think we could drop the wp_ prefix and just name the hooks literally (e.g. header_before). Personally, though, I think {$position}_{$location} reads more friendly, particularly when i'm thinking about it in the context of add_action( 'before_header', 'my_stuff_that_comes_before_the_header' );

But, I wouldn't be heartbroken if everyone else disagreed. I could certainly get behind standardizing on "wp_header_before" instead of "before_header" if it meant the difference between gaining standard hooks and forgoing them.

I'm in the same boat. My concern is the establishment of a standard, not the color of the bikeshed. I went with the wp_ prefix, since wp_head and wp_footer already have them, but have no real preference. I'd be happy to resubmit with the hooks un-prefixed?

#63 follow-up: @greenshady
12 years ago

One way we can cut down on themes implementing these hooks is to add an "after" hook to match these:

  • get_template_part_{$slug}
  • get_header
  • get_footer
  • get_sidebar
  • get_searchform

These hooks already exist in core. We could add these hooks at the end of those functions:

  • get_template_part_{$slug}_after
  • get_header_after
  • get_footer_after
  • get_sidebar_after
  • get_searchform_after

For example, the get_header() function would look like this:

function get_header( $name = null ) {
	do_action( 'get_header', $name );

	$templates = array();
	if ( isset($name) )
		$templates[] = "header-{$name}.php";

	$templates[] = 'header.php';

	// Backward compat code will be removed in a future release
	if ('' == locate_template($templates, true))
		load_template( ABSPATH . WPINC . '/theme-compat/header.php');

	do_action( 'get_header_after', $name );
}

Using these would be good for several reasons.

  • Themes don't need to alter their code.
  • Most of these hooks are used across nearly all themes.
  • We'd be building something off existing core hooks and functions.
  • We can cut way back on additional functions for outputting hooks.
  • The only hook we'd really need to consider adding to themes is the one for post data. See: #18561

#64 @zamoose
12 years ago

When I suggested the THA approach, I thought about trying to organize the hooks in a manner that would be easily-scannable, thus I tried to make it read left-to-right, with [prefix]-[section of template]-[position in relation to section], so you could lump all header_* hooks into one area. before_header definitely reads more like plain English, but then it's easy to mix up with before_footer, before_content, etc.

Like Chip, though, I'd be happy to have the hooks, regardless of their hue.

#65 in reply to: ↑ 63 @chipbennett
12 years ago

Replying to greenshady:

One way we can cut down on themes implementing these hooks is to add an "after" hook to match these:

  • get_template_part_{$slug}
  • get_header
  • get_footer
  • get_sidebar
  • get_searchform

Using these would be good for several reasons.

  • Themes don't need to alter their code.
  • Most of these hooks are used across nearly all themes.
  • We'd be building something off existing core hooks and functions.
  • We can cut way back on additional functions for outputting hooks.
  • The only hook we'd really need to consider adding to themes is the one for post data. See: #18561

I love this idea, but it doesn't address semantic template locations.

For example: get_header and get_header_after would not provide enough resolution to hook into the site header/masthead/whatever-we're-calling-it-now. The get_header hook would fire before the HTML document head, and get_header_after would fire, usually, either right before or right after the opening main-content container.

Same thing with get_footer and get_footer_after. The former would fire either right before or right after the closing main-content container, and the latter would fire after the closing </html> tag.

I agree that the hooks would be helpful, but I don't think they would solve the issue of Themes defining semantic template locations.

#66 @zamoose
12 years ago

@greenshady's approach would also neatly sidestep the necessity of themes declaring add_theme_support (e.g. https://github.com/zamoose/themehookalliance/blob/master/tha-theme-hooks.php).

I like the idea of reusing core template hooks for this effort. There are probably a few that would get dropped on the floor, but we could clean that up later.

One thing to think about would be the before/top and bottom/after utility and if/how to handle those distinctions. (In short: before comes before the opening semantic tag for a section, while top comes just after that opening tag, etc.)

#67 @greenshady
12 years ago

Replying to chipbennett:

I agree that the hooks would be helpful, but I don't think they would solve the issue of Themes defining semantic template locations.

Semantic template locations is not the issue at hand. We're trying to make it easier for plugins to hook into common areas to output data. All these template location hooks seem to be more of an advanced child theme user feature than something plugins need. The focus should be on specific areas that plugins need help with.

The only two hooks that I see as serving a purpose from the initial proposed list are post_after and comment_after (with the better proposed names like wp_post and wp_comment).

As far as template location hooks go, I don't think this is something core really needs to address. Themes have already gotten complicated enough. More PHP is just making the barrier to entry for new theme devs even tougher and complicating matters for users who like to tinker with templates. This is one of the major reasons I've been removing these hooks from my new themes.

I was one of the original theme authors to pioneer the use of template hooks. They were meant to solve one problem: Allow theme users to add stuff into a parent theme because WordPress did not allow child themes to overwrite templates. Now, with the ability to overwrite templates and the get_template_part() function, template hooks are becoming rather useless.

#68 @lancewillett
12 years ago

With @greenshady's latest comment, and chatting with Nacin, it sounds like we're shifting focus on this issue a bit.

I think the best course of action is this:

  1. Create a new ticket for wp_comment to go along with #18561
  2. Update the patch here on this ticket to add in the new _after hooks outlined above
  3. Discuss briefly in a real-time chat tomorrow

To make sure we get this into 3.6 we need to act now. Could everyone here join us in the wordpress-dev IRC channel tomorrow, Tue Feb 26 at 18 UTC to discuss our next steps?

See you there.

#69 @lancewillett
12 years ago

Added #23634 specifically for "after comments" hook.

#70 @goto10
12 years ago

  • Cc dromsey@… added

#71 @barrykooij
12 years ago

+1 for adding the '_after' hooks outlined above.

I've added these hooks in attached patch as suggested by lancewillett as step 2, except for the 'get_search_form' function.

Any feedback is appreciated, thanks.

@barrykooij
12 years ago

Added '_after' hooks.

#72 @eduplessis
11 years ago

  • Cc eduplessis@… added

#73 @mighty_mt
11 years ago

  • Cc bikertom@… added

#74 @cainm
11 years ago

  • Cc cain@… added

#75 @nacin
11 years ago

#12563 was marked as a duplicate.

#76 @Frank Klein
11 years ago

  • Cc contact@… added

#77 @alex-ye
11 years ago

  • Cc nashwan.doaqan@… added

#78 follow-up: @lancewillett
11 years ago

  • Keywords dev-feedback added
  • Milestone changed from Awaiting Review to Future Release

Let's discuss this again when 4.0 kicks off, would be good to get it working in Twenty Fifteen if we can agree on an implementation.

#79 in reply to: ↑ 78 @thewanderingbrit
10 years ago

Replying to lancewillett:

Let's discuss this again when 4.0 kicks off, would be good to get it working in Twenty Fifteen if we can agree on an implementation.

Well, 4.0 came and went, unfortunately. Would love to see this implemented soon to make better sense of items added after the content (and by extension, other areas of the theme). is it still feasible to work this into 4.1 and Twenty Fifteen?

#80 in reply to: ↑ 59 ; follow-up: @ryno267
10 years ago

Jumping in... still need to drop in, say, Google Tag Manager code immediately after the opening <body> tag.
Seems that even in older themes, having a get_header_after wouldn't solve the problem as tons of themes still have header and nav code after the <body> tag in header.php.

The 'wp_body_top' up in chipbennett patch sounds like that would work however.

#81 follow-ups: @MikeHansenMe
10 years ago

I would love to see this discussion revived and considered for Twenty Fifteen.

#83 in reply to: ↑ 80 @GaryJ
10 years ago

Replying to ryno267:

Jumping in... still need to drop in, say, Google Tag Manager code immediately after the opening <body> tag.
Seems that even in older themes, having a get_header_after wouldn't solve the problem as tons of themes still have header and nav code after the <body> tag in header.php.

Another example for a commonly accepted hook right after <body> is to allow a body class of no-js to be toggled immediately to js with a short inline script, allowing styles for JS / no JS to apply instantly without any flash of incorrect content.

#84 in reply to: ↑ 81 @joerhoney
10 years ago

Replying to MikeHansenMe:

I would love to see this discussion revived and considered for Twenty Fifteen.

Me too!

#85 @TomasM
10 years ago

It takes ~7 years for these kinds of tickets to brew, we still have about 5 years to go, will be waiting :)

#86 in reply to: ↑ 81 @Monika
9 years ago

Replying to MikeHansenMe:

I would love to see this discussion revived and considered for Twenty Fifteen.

I love to work with hooks because hooks and Child Themes are best friends :-)

#87 @chipbennett
9 years ago

So, based on discussion in this ticket, that template hooks should first go in a core-bundled Theme, I submitted a patch for TwentySixteen (to be included in 4.4), which was promptly closed, under the justification that it belongs first in core:

https://github.com/WordPress/twentysixteen/pull/162

So, can we please stop going in circles, and get the template hook template tag function definitions blessed as a core addition? I'm happy to write the patch and get this going. We just need a decision that doesn't involve continually swapping Theme-Core cart and horse.

#88 @johnbillion
9 years ago

#36350 was marked as a duplicate.

This ticket was mentioned in Slack in #themereview by karmatosed. View the logs.


8 years ago

#90 @karmatosed
8 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

We discussed this in the latest theme review meeting and the consensus was that this ticket has gone a long time without any input. In part this is due to things taking time and in greater part due to things changing in themes and how we do things. Processes evolve and now the theme + plugin route is far more common. There is a link here to our discussion: https://wordpress.slack.com/archives/themereview/p1464718330005952.

Due to time, input, involvement and the discussion; I am going to close this ticket. As sometimes happens, the way we do things evolves. Thanks everyone for their input and feel free to add your thoughts.

Last edited 8 years ago by karmatosed (previous) (diff)

#91 @lgedeon
8 years ago

@karmatosed I kinda don't think that is the link you intended to share.

#92 @karmatosed
8 years ago

Thanks @lgedeon updated the link.

This ticket was mentioned in Slack in #core by dshanske. View the logs.


8 years ago

#94 @lukecavanagh
8 years ago

@karmatosed

So is this ticket closed or something that should be worked on?

#95 @Hube2
8 years ago

I've been following this for a long time and I think it's dead, even if it is a good idea and it's rather sad to me that this has been set to wontfix.

After years of experience, the idea of getting theme authors to do things in a consistent way is a pipe dream without putting something in core to make it consistent. It's been mentioned that this should be done in plugins, but without consistent hooks where you need them in the theme you can't do anything with a plugin. Child themes become useless if you must copy every file in order to add the needed hooks when the theme does not include them. Like so many other things I've seen suggested for WP it has become nothing more than finger pointing and insisting it the responsibility of theme or plugin authors to deal with something that they either can't or won't deal with on their own without prodding from core changes. I don't think it's a lack of interest in this topic as mentioned above. I think it's simply that people are tired of getting little in the way of response or seeing little action taken.

#96 @ryno267
8 years ago

yeah, sigh. was hopeful. just simple things like adding GTM tags immediately after opening body would be immensely helpful for plugins.

Note: See TracTickets for help on using tickets.