WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 7 months ago

Last modified 7 months ago

#12563 closed enhancement (duplicate)

New action on body open

Reported by: joostdevalk Owned by: joostdevalk
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Themes Keywords: has-patch close
Focuses: 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 (1)

body_open.diff (1.6 KB) - added by joostdevalk 4 years ago.
Patch

Download all attachments as: .zip

Change History (34)

joostdevalk4 years ago

Patch

comment:1 joostdevalk4 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: Denis-de-Bernardy4 years ago

GA, placing the code in wp_head works quite fine too.

comment:3 in reply to: ↑ 2 joostdevalk4 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 valendesigns4 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.

comment:5 nacin4 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.

comment:6 joostdevalk4 years ago

It's a hook Nacin, not anything else, no addition to core that could cause security issues or whatsoever :)

comment:7 valendesigns4 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.

comment:8 nacin4 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.

comment:9 follow-up: valendesigns4 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 nacin4 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 nacin4 years ago

  • Keywords 2nd-opinion added; dev-feedback removed
  • Milestone changed from 3.1 to Future Release

comment:12 follow-up: saracup3 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 mikeschinkel3 years ago

  • Cc mikeschinkel@… added

comment:14 bandonrandon3 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 follow-up: jorbin3 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 mikeschinkel3 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

Last edited 3 years ago by mikeschinkel (previous) (diff)

comment:17 jonnybojangles3 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.

Last edited 3 years ago by jonnybojangles (previous) (diff)

comment:18 lgedeon2 years ago

  • Cc luke.gedeon@… added

comment:19 cogmios21 months ago

  • Cc deleau@… added

comment:20 lgedeon20 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.

comment:21 follow-ups: obenland9 months ago

Can we close this in favor of #21506?

comment:22 in reply to: ↑ 21 joostdevalk9 months ago

Replying to obenland:

Can we close this in favor of #21506?

While I heartily agree with everything in that patch, body_open actually serves a different purpose, so if you add it to that one, I'd be inclined to agree that we could close this ;)

comment:23 in reply to: ↑ 21 ; follow-up: Willscrlt8 months 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!

comment:24 in reply to: ↑ 15 Willscrlt8 months 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.

comment:25 in reply to: ↑ 12 Willscrlt8 months 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.

comment:26 follow-up: c3mdigital7 months 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.

comment:27 rmccue7 months ago

  • Keywords close removed
  • Milestone Future Release deleted

comment:28 in reply to: ↑ 26 Denis-de-Bernardy7 months 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).

comment:29 markoheijnen7 months ago

The example of three years ago doesn't fit anymore. So why do we need it?

comment:30 in reply to: ↑ 23 SergeyBiryukov7 months 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 it's markup is in the footer.

comment:31 SergeyBiryukov7 months ago

  • Milestone set to Awaiting Review

comment:32 nacin7 months 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/.

comment:33 Denis-de-Bernardy7 months 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:

  1. 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.
  1. 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>.
Note: See TracTickets for help on using tickets.