-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hook into wp_head() and wp_footer() #4
base: master
Are you sure you want to change the base?
Conversation
Hmmm. Convince me here. I was thinking of those two hooks as being distinct from wp_head and wp_footer to offer other options. However, if we're going to hook into the Core hooks, why not simply suggest that folks hook into the Core hooks with a high priority, as your patch does? |
Having both seems redundant to me, while not having This would act like |
I came here to write about this issue and found you guys talking about it! It seems redundant to me too (I would personally just drop them). Admittedly WordPress does do similar things, both with hooks like @obenland says, but also with tons of wrapper functions (like "add_theme_page", etc., so I don't think it's a huge deal. But, since this is [re]starting now and everyone will have to learn it from scratch, maybe it's worth making it in the "ideal" way. (Or, to put it another way, maybe you give precedence to "don't duplicate core" over "be consistent with before/after." That's a type of consistency itself, though not as intuitive.) How many people using that_after_head would be able to handle using that hook but wouldn't know wp_head()? |
@mrwweb I take your meaning. I guess I've been thinking of this as almost an HTML-like approach, where the hooks offer pseudo-wrappers, giving authors consistent behavior across all hooks and semantic areas Now, obviously, Is there a use case where having distinct My thinking is: there's no practical use case, but rather a semantic one. |
I don't know about |
I think I think that the site footer and the document footer are two semantically different things. The core |
Chip: |
What would the use cases be? When does something absolutely have to be injected immediately after the And, in such a use-case, shouldn't the semantic hook name be something like |
I think Obenland's plan of hooking the
I don't think A |
Hmmm. |
I don't think white space before the HTML would hurt anything. If you mean php headers already sent issues, that wouldn't be a problem either. |
Just occurred to me that you could alternatively hook wp_head into tha_head_bottom instead of the other way around. |
@zamoose Turns out there is an IE bug where if whitespace precedes the Doctype, then it enters quirksmode. But themer's would only have to be as careful with this as they've always been, no? Does remind me to bring up that it should probably a filter, not an action, as printing multiple doctypes isn't desirable. |
Anyway, perhaps |
Just to be clear on this, it's okay to have |
Although the guidelines state Although you might keep in mind to add a comment to the submission ticket Cais. On Thu, Nov 1, 2012 at 9:24 PM, Philip Newcomer notifications@github.comwrote:
|
Building on Cais's use-case (wrapping the inner-body with a container for CSS targeting), we can also consider JS targeting the wrapping container. The reason why we place script tags at the end of the body tag, is so that all DOM element that effect rendering (CSS) and elements that will be manipulated with JS are loaded and constructed, prior to that script downloading and executing, i.e. prevent blocking. The WordPress convention for this is for |
Obenland's patch would need a refresh to use the new hook |
and
is my proposed solution on this. I can't seem to write a clean patch, so I'll just leave it here. (rough day). Explanation: Hooks to the appropriate wp hook. Won't run twice if it was manually add to the theme, or if the theme doesn't declare support. Priority 1 used to get it to run earlier then scripts at 10. |
I think it is important to remember that Thus, a template location hook, which is intended to inject HTML content, should fire before Just because Themes and Plugins are |
That's imposing a somewhat stricter interpretation then is warranted. Outputting HTML, such as the admin-bar, in the (Aside: I would argue for admin-bar to be added via jQuery rather then printed to the source, but that's a different thing.) As mentioned above, care should be taken so that scripts intended for inclusion directly before the closing body tag (or more specifically, after elements intended to be manipulated) are handled correctly. This standard should promote such best practices. I've submitted a pull for moving |
It's also worth noting that Core prints admin bar HTML after the scripts (priority 1000). This isn't a violation as the consideration of blocking isn't impacted: Scripts not having to be aware of the admin bar are printed first so the download of those links can begin that much sooner, and the relevant DOM is available. Scripts dealing with the admin-bar are jQuery ready event triggered, and so the DOM will be available on time. As a side effect, writing a wrapper that's intended to also wrap the admin-bar, would require hooking |
Guidelines:
The following template tags and hooks are required to be included where appropriate:
wp_head()
– (immediately before</head>
)wp_footer()
– (immediately before</body>
)Hooking
'tha_head_bottom'
to'wp_head'
and'tha_footer_after'
to'wp_footer'
will respect that.