WordPress.org

Make WordPress Core

Opened 21 months ago

Last modified 3 weeks ago

#21506 new enhancement

Standard Theme Hooks

Reported by: mfields Owned by:
Milestone: Future Release 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 21 months ago.
Theme hooks for Twenty Ten
21506.twentyeleven.diff (11.1 KB) - added by kovshenin 21 months ago.
Theme hooks for Twenty Eleven
theme-hooks-test.php (3.0 KB) - added by kovshenin 21 months ago.
Proof of concept plugin with dummy data
21506.twentytwelve.diff (7.6 KB) - added by mfields 21 months ago.
general-template.php.template-hooks.patch (7.2 KB) - added by chipbennett 14 months ago.
First pass at core-defined template hooks for use by Themes
general-template.php.patch (1.1 KB) - added by barrykooij 13 months ago.
Added '_after' hooks.

Download all attachments as: .zip

Change History (84)

comment:1 iandstewart21 months ago

  • Cc ian@… added

kovshenin21 months ago

Theme hooks for Twenty Ten

kovshenin21 months ago

Theme hooks for Twenty Eleven

kovshenin21 months ago

Proof of concept plugin with dummy data

comment:2 kovshenin21 months ago

  • Cc kovshenin@… added

comment:3 hd-J21 months ago

  • Cc jeremy@… added

comment:4 follow-up: westi21 months 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

comment:5 in reply to: ↑ 4 ; follow-up: mfields21 months 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.

comment:6 philiparthurmoore21 months ago

  • Cc philip@… added

comment:7 toscho21 months ago

  • Cc info@… added

comment:8 Mamaduka21 months ago

  • Cc georgemamadashvili@… added

comment:9 ocean9021 months ago

  • Cc ocean90 added

comment:10 demetris21 months ago

  • Cc dkikizas@… added

comment:11 obenland21 months ago

  • Cc konstantin@… added

comment:12 sabreuse21 months ago

  • Cc sabreuse@… added

comment:13 follow-up: wycks21 months ago

  • Cc bob.ellison@… added

What about some before's as well?

before_header
before_loop
before_comment
before_footer

comment:14 DrewAPicture21 months ago

  • Cc xoodrew@… added

comment:15 in reply to: ↑ 13 kovshenin21 months 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?

comment:16 follow-up: iandstewart21 months 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 21 months ago by iandstewart (previous) (diff)

comment:17 lancewillett21 months ago

  • Cc lancewillett added

comment:18 in reply to: ↑ 5 westi21 months 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.

comment:19 in reply to: ↑ 16 wycks21 months 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.

comment:20 bradthomas12721 months ago

  • Cc bradthomas127@… added

comment:21 follow-up: kovshenin20 months 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.

comment:22 beaulebens20 months ago

  • Cc beau@… added

comment:23 follow-up: greenshady20 months 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.

comment:24 in reply to: ↑ 23 ; follow-up: kovshenin20 months 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?

comment:25 toscho20 months ago

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

comment:26 DrewAPicture20 months 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.

comment:27 in reply to: ↑ 21 wycks20 months 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.

comment:28 in reply to: ↑ 24 ; follow-up: greenshady20 months 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.

comment:29 in reply to: ↑ 28 ; follow-ups: mfields20 months 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?

comment:30 in reply to: ↑ 29 greenshady20 months 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.

comment:31 in reply to: ↑ 29 iandstewart20 months 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.

comment:32 in reply to: ↑ 29 kovshenin20 months 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.

comment:33 toscho20 months 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.

comment:34 SergeyBiryukov19 months ago

#21953 was marked as a duplicate.

comment:35 thomask19 months 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.

comment:36 DrewAPicture19 months ago

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

Last edited 19 months ago by DrewAPicture (previous) (diff)

comment:37 follow-up: sirzooro19 months ago

  • Cc sirzooro added

comment:38 chipbennett19 months ago

  • Cc chip@… added

comment:39 in reply to: ↑ 37 chipbennett19 months 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.

comment:40 ethitter18 months ago

  • Cc erick@… added

comment:41 rzen18 months ago

  • Cc brian@… added

comment:42 emiluzelac18 months ago

  • Cc emil@… added

comment:43 cais18 months ago

  • Cc edward.caissie@… added

comment:44 mercime18 months ago

  • Cc mercijavier@… added

comment:45 garinungkadol18 months ago

  • Cc garinungkadol added

comment:46 mfields16 months 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.

comment:47 BrazenlyGeek16 months 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.

comment:48 saltcod16 months ago

  • Cc saltcod@… added

comment:49 aaroncampbell16 months ago

  • Cc aaroncampbell added

comment:50 GeertDD16 months ago

  • Cc geertdd@… added

comment:51 MikeHansenMe15 months ago

  • Cc mdhansen@… added

comment:52 rachelbaker14 months ago

  • Cc rachelbaker added

comment:53 zamoose14 months ago

  • Cc zamoose@… added

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

*grin*

comment:54 follow-up: chipbennett14 months 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.

comment:55 mfields14 months ago

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

comment:56 in reply to: ↑ 54 ; follow-up: aaroncampbell14 months ago

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

comment:57 sabreuse14 months 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.

comment:58 kwight14 months ago

  • Cc kwight@… added

comment:59 in reply to: ↑ 56 chipbennett14 months 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.

chipbennett14 months ago

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

comment:60 chipbennett14 months 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.

comment:61 follow-up: rzen14 months 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.

comment:62 in reply to: ↑ 61 chipbennett14 months 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?

comment:63 follow-up: greenshady14 months 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

comment:64 zamoose14 months 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.

comment:65 in reply to: ↑ 63 chipbennett14 months 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.

comment:66 zamoose14 months 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.)

comment:67 greenshady14 months 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.

comment:68 lancewillett14 months 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.

comment:69 lancewillett14 months ago

Added #23634 specifically for "after comments" hook.

comment:70 goto1014 months ago

  • Cc dromsey@… added

comment:71 barrykooij13 months 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.

barrykooij13 months ago

Added '_after' hooks.

comment:72 eduplessis9 months ago

  • Cc eduplessis@… added

comment:73 mighty_mt8 months ago

  • Cc bikertom@… added

comment:74 cainm8 months ago

  • Cc cain@… added

comment:75 nacin7 months ago

#12563 was marked as a duplicate.

comment:76 Frank Klein7 months ago

  • Cc contact@… added

comment:77 alex-ye4 months ago

  • Cc nashwan.doaqan@… added

comment:78 lancewillett3 weeks 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.

Note: See TracTickets for help on using tickets.