Opened 3 years ago
Last modified 9 months ago
#12563 new enhancement
New action on body open
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Themes | Version: | 3.1 |
| Severity: | normal | Keywords: | has-patch 2nd-opinion close |
| Cc: | valendesigns, bandonrandon@…, luke.gedeon@…, deleau@… |
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 (1)
Change History (21)
joostdevalk — 3 years ago
comment:1
joostdevalk — 3 years ago
BTW I called the function wp_body_open(), to be more in line with wp_head and wp_footer :)
comment:2
follow-up:
↓ 3
Denis-de-Bernardy — 3 years ago
GA, placing the code in wp_head works quite fine too.
comment:3
in reply to:
↑ 2
joostdevalk — 3 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.
comment:4
valendesigns — 3 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.
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.
comment:6
joostdevalk — 3 years ago
It's a hook Nacin, not anything else, no addition to core that could cause security issues or whatsoever :)
comment:7
valendesigns — 3 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.
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.
comment:9
follow-up:
↓ 10
valendesigns — 3 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.
comment:10
in reply to:
↑ 9
nacin — 3 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.
comment:11
nacin — 3 years ago
- Keywords 2nd-opinion added; dev-feedback removed
- Milestone changed from 3.1 to Future Release
comment:12
saracup — 2 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.
comment:13
mikeschinkel — 2 years ago
- Cc mikeschinkel@… added
comment:14
bandonrandon — 2 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
comment:15
jorbin — 2 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.
comment:16
mikeschinkel — 2 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
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.
comment:18
lgedeon — 12 months ago
- Cc luke.gedeon@… added
comment:19
cogmios — 10 months ago
- Cc deleau@… added
comment:20
lgedeon — 9 months 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.
Patch