#21766 closed feature request (wontfix)
modify body_class function to allow non-class items
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Themes | Keywords: | has-patch |
Focuses: | template | Cc: |
Description
Currently, the body_class
only allows for filtering with additional classes. For users that want to add other items, they have to manually edit the theme files. The best example of this is schema.org body elements (itemtype and itemprop).
The diff file shows two things:
- the new
body_items
function that grabs any items added via filter, if they exist.
- the modified
body_class
function, which appends the output with the items if they exist.
The patch, as I've written it, allows for this additional filter to be included without interfering with how themes / plugins interact with the current body_class
filter, and doesn't require theme authors to include an additional tag in their themes.
Below is an example function that could be placed in a theme or plugin to add other items to the body tag element.
function schema_bodyitems($item) { if (is_page() ) : $item[] = 'item-foo="item-bar"'; endif; $item[] = 'itemtype="http://schema.org/Blog"'; $item[] = 'itemscope=""'; return $item; } add_filter('body_items','schema_bodyitems');
Attachments (1)
Change History (18)
#1
follow-up:
↓ 2
@
12 years ago
I see value in having a way to add new attributes to the <body>
tag, this approach still seems kind of scoped to the example use case.
I'm not a fan of having to piggy back on body_class()
, but I see why -- body_class
is widely deployed and integrated into many themes. However, I still think there is a cleaner approach to this problem that allows body_class
to still work while also introducing a new filter to add attributes.
#2
in reply to:
↑ 1
@
12 years ago
Replying to xenlab:
I see value in having a way to add new attributes to the
<body>
tag, this approach still seems kind of scoped to the example use case.
I'm not a fan of having to piggy back on
body_class()
, but I see why --body_class
is widely deployed and integrated into many themes. However, I still think there is a cleaner approach to this problem that allowsbody_class
to still work while also introducing a new filter to add attributes.
based on the method outlined, you could add stand-alone elements as well, not just the item-foo=item-bar setup.
#3
follow-up:
↓ 4
@
12 years ago
- Keywords dev-feedback removed
Similar discussion for admin body classes: #19460
#4
in reply to:
↑ 3
@
12 years ago
Replying to scribu:
Similar discussion for admin body classes: #19460
similar, but JS won't correctly solve the issue on the front-end. adding schema items (which is one example, but the best I can think of currently) via JS won't apply until after the page loads, which won't put it in the source code that search engines will crawl. if it isn't in the actual source, it may as well not exist in the eyes of a search engine.
#5
@
12 years ago
I will deny having written this:
<?php class WP_Body_Class_Injection_Plugin { public function __construct(){ add_filter( 'body_class', array( $this, 'body_class' ) ); } public function body_class( $classes ) { $backtrace = debug_backtrace(); if ( $backtrace[4]['function'] === 'body_class' ) echo " foo='bar' "; return $classes; } } new WP_Body_Class_Injection_Plugin;
#8
@
12 years ago
@ryanve I agree. the hack 'works' but it doesn't address the underlying concern. I'm not sure what else would be relevant to add (body ID, maybe?) but having more flexibility would be great.
#11
@
11 years ago
- Keywords close added; 2nd-opinion removed
The intend of this ticket seems to be similar to #23537.
For the example mentioned, I agree with Otto42 that a theme should be dealing with schema.org and not a plugin. I don't think we should be hijacking body_class()
in that way.
#12
follow-up:
↓ 13
@
11 years ago
@obenland my main issue with leaving it to the theme authors is that it loses the ability to standardize the format. also; the itemprop and itemname (again, using the schema example) could be different for two pieces of content using the same template file, depending on what they may be displaying
#13
in reply to:
↑ 12
@
11 years ago
Replying to norcross:
I understand that, but schema.org is a bit more involved than adding two attributes to the body element.
body_class()
is one of the more "elegant" template tags, in terms of doing what it's expected to do and be named accurately. Let's not make it confusing.
#14
follow-up:
↓ 15
@
11 years ago
- Keywords close removed
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
Double-checked with wonderboymusic during WCNYC contributor day: body_class()
is just not the place for additional attributes, that would be theme territory.
#15
in reply to:
↑ 14
@
11 years ago
Replying to obenland:
Double-checked with wonderboymusic during WCNYC contributor day:
body_class()
is just not the place for additional attributes, that would be theme territory.
not happy, but it is what it is. considering how many years it took to get theme devs to use the body_class()
function, I doubt that anything else will ever get implemented.
#16
follow-up:
↓ 17
@
11 years ago
considering how many years it took to get theme devs to use the body_class() function, I doubt that anything else will ever get implemented.
Yeah, that also came up during that discussion. :/
#17
in reply to:
↑ 16
@
11 years ago
Replying to obenland:
considering how many years it took to get theme devs to use the body_class() function, I doubt that anything else will ever get implemented.
Yeah, that also came up during that discussion. :/
I don't doubt that at all. also, please don't misunderstand me, I completely understand (and on it's face, agree with) the reasoning for punting this. just bummed there isn't a way to handle it that doesn't involve breaking years of theme dev habits.
removing commented out items