#12563 closed enhancement (fixed)
New action on body open
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 5.2 | Priority: | normal |
| Severity: | normal | Version: | 3.1 |
| Component: | Bundled Theme | Keywords: | has-patch has-dev-note |
| Focuses: | template | Cc: |
Description
More and more asynchronous javascripts need a part of their javascript printed right after the opening <body> tag, the Google Analytics asynchronous tracking being my most obvious example. To allow for this themes should come with a new function in the same fashion as wp_head and wp_footer, to be called 'body_open'.
Attachments (7)
Change History (89)
#1
@
10 years ago
BTW I called the function wp_body_open(), to be more in line with wp_head and wp_footer :)
#3
in reply to:
↑ 2
@
10 years ago
Replying to Denis-de-Bernardy:
GA, placing the code in wp_head works quite fine too.
Nope, not in IE6 & 7, even according to google's own docs.
#4
@
10 years ago
- Cc valendesigns added
Please add this to the core. I'm developing a plugin for Todd Garland of Buy Sell Ads and this is something that the plugin absolutely needs to work with the Asynchronous code. Otherwise people will need to add a function to the header.php manually. Let's face it this is not a hard fix and would save people time.
#5
@
10 years ago
I fail to see enough of a use case to adopt a hook here. Us decreeing that a new hook should be added to themes will *not* ensure its adoption. You'll likely see IE7 usage stats drop to the point where you can just go with wp_head before the majority of themes reliably adopt a new hook. People will need to modify header.php either way, and it's not exactly uncommon for plugins to suggest that hooks or template tags are added to specific points in a theme.
#6
@
10 years ago
It's a hook Nacin, not anything else, no addition to core that could cause security issues or whatsoever :)
#7
@
10 years ago
I really don't see any good reasons not to include this in the core. It's a very simple snippet of code that does not cause any harm. I don't think relying on IE stats to drop is a good reason to not move forward with this hook. If we have learned anything, it's that IE has the uncanny ability to stick around regardless of progress. IE6 for example is still being used by some people this very second. To disregard that fact is irresponsible. Obviously plugin developers are going to need people to add the required function to the template in the meantime but it would be nice that it was there in the future if you needed it. That's all I'm saying.
#8
@
10 years ago
My point is that this isn't a hook in core. Quite literally, it would not be in core. It needs to get added to 10,000 themes. That comes down to education.
Thus I have been thinking that it is better we stick to wp_head and wp_footer -- both with clearly defined purposes and a wide variety of uses, and both widely used and over the years widely implemented. Instead, the plugins that need this hook should tell the user to add it. As it is, they will need to tell the user to double-check that it is in their theme, as I guarantee many themes will not bother adding the hook. So instructions either way.
My comment about IE7 was not about stats or how we base decisions, it's that you'd have better luck waiting for people to finally drop browsers that require this hack in the first place than getting WP themes to adopt a hook that maybe 6 plugins want to utilize.
#9
follow-up:
↓ 10
@
10 years ago
I think as asynchronous code become more and more adopted by web services as a means to communicate between two separate web sites more than 6 plugins will need this kind of hook.
I see your point that it isn't critical, but it's not going to hurt the core to add it and everyone doesn't have to use it. Yes you'll need to tell users to add it, but then I wouldn't have to worry that the user didn't check if it existed in their function call, so if they deactivate the plugin the ceiling will not fall on their head. I get you think it's unnecessary but it's not asking you to change any of the core functionality and is not going to degrade WP in any way.
Obviously you made you're mind up about the situation and are not going to change your stance, I just think it's pointless to be so anti-this-hook when it would take very little time to add it in and document.
#10
in reply to:
↑ 9
@
10 years ago
Replying to valendesigns:
Yes you'll need to tell users to add it, but then I wouldn't have to worry that the user didn't check if it existed in their function call, so if they deactivate the plugin the ceiling will not fall on their head.
I would recommend telling users to add do_action( 'body_open' );
Obviously you made you're mind up about the situation and are not going to change your stance, I just think it's pointless to be so anti-this-hook when it would take very little time to add it in and document.
No, see, when I hear a convincing argument, my opinion can switch pretty quickly. It happens all the time. I don't have a personal agenda. I'm not anti-this-hook, I'm against a niche hook in a situation where the niche has not convinced me, especially when it is a hook that I don't have any power to add, and that it can be added without any core intervention. 99.9% of this has nothing to do with core, it has to do with us backing it.
I am of course willing to consider this -- there is a reason I haven't closed it -- but it needs to gain traction. I would like to hear what other developers think. And if theme authors start adding body_open hooks to support a niche use (and, more specifically, supporting old browsers for said niche use), then a more direct effort sounds like something we should consider.
#11
@
10 years ago
- Keywords 2nd-opinion added; dev-feedback removed
- Milestone changed from 3.1 to Future Release
#12
follow-up:
↓ 25
@
9 years ago
- Version set to 3.1
As more and more of us are deploying Wordpress as a CMS (not just a blogging platform), there is greater need for global navigational elements, which usually occur right after the opening of the body tag. To have to develop themes to address this cuts out Wordpress as a viable open source platform without having to rely on a framework like Hybrid which has inserted hooks to enable this kind of thing. You are leaving to the developers something that, if in the core, would enable non-developers to deploy plugins without hiring someone. This is vital for our organization, and means the difference between tying into a premium framework, hiring a development firm, or being able to enhance our themes with global navigation elements ourselves. As a higher education institution with few resources, we would benefit very much from this. It helps chosen themes scale better for an institution that wants a unified look and feel but the flexibility of Wordpress. Please, please consider putting this in the core.
#14
@
9 years ago
- Cc bandonrandon@… added
As a plugin devloper I was looking for a simular hook so I could add a message to the top websites. However, now that I see a hook I don't really see it nessarry. As the function is so simple that any theme or plugin author could easy add it to functions.php or my_plugin.php then the user could either use it as a template tag or a shortcode could be created.
Just my 2 cents
#15
follow-up:
↓ 24
@
9 years ago
- Keywords close added
I agree with Nacin. The only way this becomes useful is if themes start using that and I don't see that as likely. Plenty of people still use themes that lack wp_footer() and wp_head(). You can use JS or have users insert your custom action to fix this.
#16
@
9 years ago
- Cc mikeschinkel@… removed
I agree with @nacin and @jorbin. This can't be added to core but must be added to each and every theme, which is a non-starter.
But there is a workaround, if you need it (though this really is a hack):
add_filter('template_include','yoursite_template_include',1);
function yoursite_template_include($template) {
ob_start();
return $template;
}
add_filter('shutdown','yoursite_shutdown',0);
function yoursite_shutdown() {
$insert = "[YOUR INSERTED HTML GOES HERE]";
$content = ob_get_clean();
$content = preg_replace('#<body([^>]*)>#i',"<body$1>{$insert}",$content);
echo $content;
}
Hope this helps.
-Mike
#17
@
9 years ago
I have the same need to hook into the opening of the HTML/Theme’s body tag. I also agree that this is out of the control of WordPress Core.
Is it possible to lead by example and have the action or a template tag added to WordPress’ default theme? Is there an issue with making use of do actions over template tags from within a theme? Perhaps this is the wrong forum for this discussion?
Regardless, I have added do_action( 'body_open' ); to my custom themes and plugins with success.
#20
@
8 years ago
I like the lead by example method. Let's add this into the themes we can. They are used as a model for many other themes. This should also be recommended practice specifically for themes that are built with child themes in mind. Duplicating header.php or doing the output buffer hack just to add one thing should not be necessary. body_class() is gaining wide acceptance, why not body_open as well?
As a theme developer, I would rather add one line that I know is becoming a standard than insert a custom hook that may never be used by more than one custom plugin.
There are so many times we need to get something to the top of the page. Sure sometimes it is ads, but other times it is an announcement, navigation, a widget area, or any other piece of content that a user might want. Sure we can do things in CSS and/or JS a lot of times, but page rendering would be faster with the hook - might even get to do page caching, and in many cases would just be less breaky.
#23
in reply to:
↑ 21
;
follow-up:
↓ 30
@
7 years ago
Replying to obenland:
Can we close this in favor of #21506?
Hi. I agree with joostdevalk. This hook is very necessary for several people (at least judging by the number of similar requests I found when Googling this). The other ticket has some similarities, but nothing like this where the hook comes right after the BODY tag.
That, too, is what I need. I realize that not all themes will support it (though getting it into the next updates of the TwentyEleven, TwentyTwelve, and TwentyThirteen themes would be a big boost), but it would be a lot easier for users to pick themes that support the hook (or add one line of code to a theme), than for plugin developers to have to resort to really ugly JavaScript kludges that only work if JS is enabled.
In my case, I am writing a plugin that easily (or so I thought) allows people to call a PHP function at the top of the page. I will be using it on my own sites to load a global navigation bar across multiple domains and multiple Web applications (WordPress, phpBB, Piwigo, etc.). I need something that works across multiple themes (at least any theme that has built in support for the new body_open hook), since different sites use different themes.
Sure, I could hack existing themes to insert the PHP function, but I'd rather just use a plugin to do it, and then leave the themes alone so that they can remain updated and my function still works.
The need for body_open is definitely there, so I hope that this will be committed quickly. As far as waiting for theme support--well--nobody is going to support it until it becomes a reality. Even if adoption is slow, that doesn't mean it's useless. If a Webmaster needs the functionality of a plugin like mine (or any of the others I've seen suggested by people looking for this fix), then they will find a theme that works or hack one to make it work.
I have no idea about the politics or proper procedures of getting a commit like this done, but the Codex does imply that if we find places that need new hooks, it will be easy to get them added. I took that with a grain of salt, but this suggestion has been around for 3 years. Can we PLEASE get it in the next release? It doesn't seem like it should be that hard to add a hook in.
And just to be clear, this needs to come BEFORE any other WP stuff (right after the body tag would be best for me and for the others I read). #21506 would come after all the top visual headings. That would be far too late for what most of us need. Not that that isn't a good place for a hook, too. It's just not the same thing. Thanks!
#24
in reply to:
↑ 15
@
7 years ago
Replying to jorbin:
I agree with Nacin. The only way this becomes useful is if themes start using that and I don't see that as likely. Plenty of people still use themes that lack wp_footer() and wp_head(). You can use JS or have users insert your custom action to fix this.
JavaScript is not a solution for this. First, the obvious problem... it's JS dependent! We're talking about PHP that runs on the backend relying upon a browser plugin that a number of people disable for security or performance reasons. Kind of messes up the whole thing.
Also, having users insert anything into a template is more effort than they should be required to do. It might be easier than slicing bread for you, but I think the majority of WP uses prefer plugins that just plain work out of the box. Sure, it's a feature that the theme has to support, but once the hook is in place, more themes will support it, and that increases the likelihood that the plugins using this hook will work without any modifications required.
#25
in reply to:
↑ 12
@
7 years ago
Replying to saracup:
As more and more of us are deploying Wordpress as a CMS (not just a blogging platform), there is greater need for global navigational elements, which usually occur right after the opening of the body tag. ... You are leaving to the developers something that, if in the core, would enable non-developers to deploy plugins without hiring someone.
Those are two very excellent points. The global navigational elements are exactly the issue I'm trying to address with my plugin (contact me, and I'll see if you have any special needs that I can incorporate into my plugin).
The other point is equally valid. By implementing this in the core, you enable EVERYONE with a modicum of experience to be able to hook into that part of the document. Without it, you either have to fork an existing template (and lose the author's automatic updates) and hack it yourself, or you have to craft your own. Most of the time, a simple plugin that can use that hook would be adequate, and then the themes would be much less of an impediment.
#26
follow-up:
↓ 28
@
7 years ago
- Keywords 2nd-opinion removed
- Resolution set to wontfix
- Status changed from new to closed
The only two things themes must absolutely have are wp_head() and wp_footer(). This is theme territory.
#28
in reply to:
↑ 26
@
7 years ago
- Keywords close added
- Resolution wontfix deleted
- Status changed from closed to reopened
Replying to c3mdigital:
The only two things themes must absolutely have are wp_head() and wp_footer().
It seems to me, that this ticket seeks to address precisely that point.. Some kind of wp_body() call would be most welcome in addition, and this ticket suggests that WP support it and lead by example.
This is theme territory.
The ticket's very nature makes it WP territory.
I'm not making much sense of why this never got checked in three years ago. The argument that themes won't adopt it fast enough is laughably specious. They certainly won't adopt it if WP doesn't set the example.
If there's a standardized hook here, every theme that supports the hook will make a user happy at some point or another, by saving him the work needed to manually add some piece of code. It's useful for output buffers, for asynchronous scripts, and of course for the occasional need to output a full on menu when you're unclear on the fact that it can be inserted any other way (not everyone is a web development wizard).
Yeah, there are workarounds using output buffers, and so forth. But honestly, in my experience, they break the minute you've some odd markup lying around. A simple hook that endorses a name that every theme developer can then use would make everyone's life so much simpler: developers (only a hook to worry about) and users (always the same hook to add -- once).
#30
in reply to:
↑ 23
@
7 years ago
Replying to Willscrlt:
In my case, I am writing a plugin that easily (or so I thought) allows people to call a PHP function at the top of the page. I will be using it on my own sites to load a global navigation bar across multiple domains and multiple Web applications (WordPress, phpBB, Piwigo, etc.).
You don't actually need to call a PHP function at the top of the page to achieve that, it's just a matter of styling.
The WordPress toolbar is displayed at the top of the page, but its markup is in the footer.
#32
@
7 years ago
- Milestone Awaiting Review deleted
- Resolution set to duplicate
- Status changed from reopened to closed
I'm marking this ticket as a duplicate of #21506.
This ticket is not for inserting items into the template. #21506 is.
This ticket, rather, is about Google Analytics asynchronous tracking code, which for some time recommended (for IE6/7 support, I guess) that the script be inserted immediately after <body>. All documentation now clearly says this belongs just before </head>. See also https://developers.google.com/analytics/devguides/collection/gajs/.
#33
follow-up:
↓ 34
@
7 years ago
Replying to nacin:
I'm marking this ticket as a duplicate of #21506.
Imho, there isn't that much overlap.
This ticket is about a separate hook, geared towards (admittedly in-optimally written) code that would need to insert stuff immediately after the <body> tag. The ticket references Google Analytics code that has changed since, but there are separate use-cases that keep this other hook a valid issue. Two among them that I can think of off the top of my head:
- The occasional need to start an output buffer that only affects the contents of the <body> tag, without replying to regexp-fu such as outlined by Mike further up.
- A/B testing related code (Google web optimizer comes to mind, or whatever its name is nowadays, but there are other such scripts used in internet marketing spheres). These frequently need code to be inserted after the <body> tag rather than before </head>.
#34
in reply to:
↑ 33
@
4 years ago
- Resolution duplicate deleted
- Status changed from closed to reopened
Replying to Denis-de-Bernardy:
Replying to nacin:
I'm marking this ticket as a duplicate of #21506.
Imho, there isn't that much overlap.
This ticket is about a separate hook, geared towards (admittedly in-optimally written) code that would need to insert stuff immediately after the <body> tag. The ticket references Google Analytics code that has changed since, but there are separate use-cases that keep this other hook a valid issue. Two among them that I can think of off the top of my head:
- The occasional need to start an output buffer that only affects the contents of the <body> tag, without replying to regexp-fu such as outlined by Mike further up.
- A/B testing related code (Google web optimizer comes to mind, or whatever its name is nowadays, but there are other such scripts used in internet marketing spheres). These frequently need code to be inserted after the <body> tag rather than before </head>.
I'd like to add that Google Tag Manager is often used by the company I work for in websites, and that requires being inserted right after the opening <body>. It specifies this in the official documentation (https://support.google.com/tagmanager/answer/6103696?hl=en&ref_topic=3441530#AddingTheContainerSnippet) so this ticket still remains relevant.
#36
@
4 years ago
For a correct implementation of Google Tag Manager its code must be inserted right after the opening <body> tag. Is there another solution for adding code directly after the opening body tag? GTM gets implemented more and more in the future. Any chance this feature gets implemented in a way one can enable tagmanager functionality for Wordpress?
#37
@
3 years ago
Yes, we need a solution for this: https://wordpress.org/support/topic/doesnt-work-1161/#post-8707231
#39
@
3 years ago
- Component changed from Themes to Bundled Theme
- Focuses template added
- Keywords needs-refresh added; close removed
- Milestone changed from Awaiting Review to Future Release
I think this ticket needs some traction.
There is no reason, IMHO anyway, that this shouldn't be added to core and the bundled themes. Once there, any child themes from them would have it and I don't think it would be too much of a stretch to have wp_body_open added to https://make.wordpress.org/themes/handbook/review/required/#templates
The arguments against seem to be rooted in the issue of telling people to use it - that seems rather silly considering core adds new functionality all the time. Just add it to the release notes and if people want to use it they will.
This is a case of users asking for something that has a real-world, potentially revenue impacting ( in the case of Google DFP ) use case and I don't see any downside of adding it in.
#42
in reply to:
↑ 41
@
2 years ago
Moving from #42927,
I suggest to call the new action wp_body and the wrapper function wp_body().
WordPress themes will eventually look like this:
<html>
<head>
..
..
<?php wp_head(); ?>
</head>
<body>
<?php wp_body(); ?>
..
..
<?php wp_footer(); ?>
</body>
</html>
#43
follow-ups:
↓ 45
↓ 49
@
21 months ago
We've gone eight years without it. What's the big deal?
Why isn't get_header hook or even wp_footer sufficient?
#44
@
21 months ago
Because the Google Tag Manager HTML snippet needs to be implemented
right after the opening body tag
in order to work correctly and to be recognised for website verification purposes for
a) Google Search Console
b) Google Merchant Center (the tool you need for Google Shopping campaigns to work)
c) other stuff
and many peope are using Wordpress for small ecommerce shops selling their individual goods.
Not everybody wants to go with Shopify or Amazon. :-(
The snippet needs to be right there.
Not somewhere between <body> and </body>.
Not in the <head>..</head> section.
And surely not between </head> and <body>.
It needs to be implemented right after the opening body tag.
It this was unclear I can also provide a picture.
And GTM may just be one example, but a very serious one. Thousands of users cannot imagine managing a website that wants to do marketing efficiently without it.
#45
in reply to:
↑ 43
;
follow-up:
↓ 51
@
21 months ago
Replying to joyously:
We've gone eight years without it. What's the big deal?
We've gone eight years using problematic solutions, inflated plugins and other workarounds.
Why isn't
get_headerhook or evenwp_footersufficient?
get_header hook runs in the header. wp_footer hook runs before closing the body. We need a hook after opening the body.
This ticket was mentioned in Slack in #core by whitneyyadrich. View the logs.
21 months ago
#47
@
21 months ago
How would we the plethora of existing themes to add this new template tag? Should we should a _doing_it_wrong() if the wp_body_openaction never was triggered in the rendering of a template? So essentially:
<?php add_action( 'wp_footer', function() { if ( ! did_action( 'wp_body_open' ) ) { _doing_it_wrong( 'wp_body_open', __( 'Missing wp_body_open() call after <body>' ), '4.9.9' ); } } );
I suppose that could be done as part of a plugin that relies on wp_body_open() as well.
#48
@
21 months ago
Or better, we could trigger that _doing_it_wrong() only if there is a plugin that adds an action for wp_body_open:
<?php add_action( 'wp_footer', function() { if ( has_action( 'wp_body_open' ) && ! did_action( 'wp_body_open' ) ) { _doing_it_wrong( 'wp_body_open', __( 'Theme template is wp_body_open() call after <body>' ), '4.9.9' ); } } );
(I'm using closures for example expediency.)
#49
in reply to:
↑ 43
;
follow-up:
↓ 50
@
21 months ago
Replying to joyously:
We've gone eight years without it. What's the big deal?
Why isn't
get_headerhook or evenwp_footersufficient?
Good precedent for why wp_body_open() makes sense I think can be found in the introduction of support for title tag in #18548 (via title-tag theme support). Sure themes and plugins could just put <title> in their header.php, but this means lots of duplicated code and it makes it more difficult for themes, plugins, and core to manipulate the title. In the same way, having a standard wp_body_open() would make it easier for everyone to add markup to this (increasingly) standard location.
#50
in reply to:
↑ 49
@
21 months ago
Replying to westonruter:
In the same way, having a standard
wp_body_open()would make it easier for everyone to add markup to this (increasingly) standard location.
+1
#51
in reply to:
↑ 45
@
21 months ago
Replying to ramiy:
Replying to joyously:
We've gone eight years without it. What's the big deal?
We've gone eight years using problematic solutions, inflated plugins and other workarounds.
Why isn't
get_headerhook or evenwp_footersufficient?
get_headerhook runs in the header.wp_footerhook runs before closing the body. We need a hook after opening the body.
This pretty much succinctly sums up the issue. Thank you @ramiy !
#52
follow-up:
↓ 56
@
21 months ago
There is one option that is purely core implementation. Add the new action as the last thing in get_header. Themes already are calling that and the header typically ends with the body tag (and a variable amount of tags after).
#53
@
20 months ago
- Owner changed from joostdevalk to adamsilverstein
- Status changed from reopened to assigned
#56
in reply to:
↑ 52
@
20 months ago
Replying to joyously:
There is one option that is purely core implementation. Add the new action as the last thing in
get_header. Themes already are calling that and the header typically ends with the body tag (and a variable amount of tags after).
The "variable amount of tags after" is a huge problem in many cases. Many plugins need to put something inside <body> but above those other tags. Even many themes need variable content in this position and have to implement their own hook or some custom function call.
This ticket sets an example for future theme builders of a standard way to handle a common problem that will also be compatible with plugins. The examples set in the "twenty" series of plugins are often copied. Also with the wp_body_open() function in core we are establishing a stable name for this hook.
From here the migration path involves:
- Theme makers copy the examples in the "twenty" themes.
- We probably make a plugin to do the filtering suggested by Mike (https://core.trac.wordpress.org/ticket/12563?replyto=52#comment:16). Instead of inserting html here, fire the hook and ob_cache that output. Then insert that. We can probably do it at the end of wp_header rather than waiting until shut_down so that we have less to regex.
- Any plugin that requires this hook can use "doing it wrong" or a notice in wp-admin to request the site owner to add the hook or install the filtering plugin from step 2.
- Documentation across the web should be updated to inform everyone about the new hook.
One thing that might help adoption, is that we can encourage people to add this themselves since the next version of the theme should be adding it anyway.
#57
follow-up:
↓ 58
@
20 months ago
What about trying to make sure it is called (even if late)? This could be at the very end of get_header().
if ( ! did_action( 'wp_body_open' ) ) {
do_action( 'wp_body_open' );
}
#58
in reply to:
↑ 57
@
20 months ago
Replying to joyously:
What about trying to make sure it is called (even if late)? This could be at the very end of
get_header().
Any plugin that is ok with running late can just run late, but most plugins that use this hook would be using it because location matters.
#60
@
17 months ago
- Keywords close added
- Milestone changed from 5.1 to Future Release
With the changes to theming that Gutenberg is likely to trigger, I'm not wild about making significant additions to the theme APIs that are likely to be made redundant by the bigger changes in Gutenberg.
I'm fine with leaving this ticket open for a bit while Gutenberg explores these areas, we can return to it if Gutenberg theming ends up going elsewhere.
#61
@
17 months ago
@pento darn, i was crafting a poem for my commit message :)
seriously though, this still seems relevant for sites now, given the current theme api and the need for a way to output scripts directly after body_open (see tag manager). I guess we'll see how things shape up, I can see how if things will work differently in the future we might not want to commit to this approach.
#62
@
17 months ago
@pento i'm not sure why gutenberg is involved in this ticket.
As you said, Gutenberg will change the theme API. But this new action would be really useful for plugins and mu-plugins, regardless the theme or Gutenberg.
I think this ticket is still relevant for sites right now and in a few months or years.
#63
follow-up:
↓ 66
@
15 months ago
I've just read through this entire thread and am frankly baffled. I'm used to seeing discussion thread around feature requests on different repositories. And quite a few where the project leads refuse those feature requests on ideological and design philosophy grounds. Even if those leads accept that the feature might be useful to a portion of the users.
But this is not the case here. The feature is rejected without any cogent reason. 'WordPress has survived for 8 years without this useful feature' is given as a valid reason. 'GMT hooking into body tag will soon be a thing of the past' - another reply. 'Themes will not adopt this' was one very un-forward-looking argument given (the recent push of Gutenberg being a clear example to the contrary - plugin developers have rushed to implement). And finally - 'Gutenberg is coming and it's gonna change EVERYTHING'. While the last might be true, it is irrelevant to the necessity of this hook. This has nothing to do with Gutenberg or with themes, and all to do with plugins that require hooking into the opening of the BODY tag.
Right now I have a custom <?php namespaced_wp_body() ?> function that calls 3 different do_action hooks (tha_body_top, body_top, body_open) that all do the same thing, just to satisfy different plugins I have installed (and, of course, I cannot play with the priorities properly as the hooks fire consecutively). Not to mention genesis_before and a ton of other non-standardized hooks that all do exactly the same thing that *apparently* so many plugins find useful. But the core development team is somehow not impressed by this abundance of evidence.
When all that is needed is a simple <?php wp_body() ?> tag that any theme can easily implement and a standard do_action('body_open') that any plugin can hook into. @ramiy's post above is illustrative of the simplicity and logic of implementing this functionality in WordPress core.
#64
follow-up:
↓ 65
@
15 months ago
@pento Any thoughts on including this enhancement in 5.2? Seems useful to me :)
#65
in reply to:
↑ 64
@
15 months ago
Replying to adamsilverstein:
@pento Any thoughts on including this enhancement in 5.2? Seems useful to me :)
Same here ;)
#66
in reply to:
↑ 63
@
15 months ago
Replying to apedog:
I've just read through this entire thread and am frankly baffled. I'm used to seeing discussion thread around feature requests on different repositories. And quite a few where the project leads refuse those feature requests on ideological and design philosophy grounds. Even if those leads accept that the feature might be useful to a portion of the users.
But this is not the case here. The feature is rejected without any cogent reason. 'WordPress has survived for 8 years without this useful feature' is given as a valid reason. 'GMT hooking into body tag will soon be a thing of the past' - another reply. 'Themes will not adopt this' was one very un-forward-looking argument given (the recent push of Gutenberg being a clear example to the contrary - plugin developers have rushed to implement). And finally - 'Gutenberg is coming and it's gonna change EVERYTHING'. While the last might be true, it is irrelevant to the necessity of this hook. This has nothing to do with Gutenberg or with themes, and all to do with plugins that require hooking into the opening of the BODY tag.
I absolutely agree, 100%.
We are working with tools like Google Tag Manager for numerous clients and not having this feature has given us headaches for years.
We need to insert specific code *right after* the opening <body> tag.
Without other code - be it from templates, plugins, hooks or whatever - in between.
Also not in the header, not in the footer and not at the end of the header.
And most certainly not called late by get_header or something similar.
Looking forward... Can it be done?
#67
@
14 months ago
- Keywords needs-refresh added; commit close removed
- Milestone changed from Future Release to 5.2
Sadly, it does seem like the Gutenberg theme work is going to be a much longer time coming than I had originally hoped. In the mean time, there's clearly a practical use for this to be added now.
If someone feels like refreshing the patch, let's get this committed in the next couple of hours, before 5.2 beta 1 is released.
This ticket was mentioned in Slack in #core by pento. View the logs.
14 months ago
#69
@
14 months ago
12563.5.diff refresh against trunk
#72
@
14 months ago
- Keywords commit removed
- Resolution fixed deleted
- Status changed from closed to reopened
All default themes will now fatal if they are used with a WordPress version before 5.2. I'm sure we can do better here.
#73
@
14 months ago
- Keywords needs-patch added; has-patch removed
The default themes can add a shim to functions.php, which I imagine most themes will do for back compat purposes.
#74
@
14 months ago
- Keywords has-patch added; needs-patch removed
Should we add this to functions.php in each theme?
<?php if ( ! function_exists( 'wp_body_open' ) ) { function wp_body_open() { do_action( 'wp_body_open' ); } }
#76
@
14 months ago
- Keywords has-patch added; needs-patch removed
- Resolution set to fixed
- Status changed from reopened to closed
That's the idea, @lgedeon!
I've opened #46679 to track this bug.
This ticket was mentioned in Slack in #themereview by dannycooper. View the logs.
14 months ago
#79
@
13 months ago
Now, with this hook it seems possible to arrange the loading cue of enabled plugins & theme, or parts of it - (modular theme) in any order I need to..
Perhaps something like the main menus drag & drop structure, or at least
numbering sorting next to activated plugins will do a more advanced admin-friendly plugin/theme loading management.
It seems to me that this would be something more than amazing development.
i.e.: I would like to load first of all "revolution slider" plugin -before- everything else, even the theme, so I can show an eye-catching presentation before everything loads.
#80
@
13 months ago
Just added this as a reference for people stumbling upon this thread:
New wp_body_open Theme Hook introduced in WP 5.2
https://make.wordpress.org/core/2019/04/24/miscellaneous-developer-updates-in-5-2/
Patch