#28482 closed defect (bug) (wontfix)
Display hentry only on blog post in the post_class
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.0 |
Component: | Posts, Post Types | Keywords: | |
Focuses: | template | Cc: |
Description (last modified by )
According to the microformats.org wiki
h-entry is often used with content intended to be syndicated, e.g. blog posts.
We are displaying the hentry
for all CPT's. This would only be needed for blogs.
There are two possible solutions.
- One solution would be to only display the class when it is a post.
if ( post == get_post_type() ) { // hentry for hAtom compliance $classes[] = 'hentry'; }
- The second would be to remove it completely as I don't think WordPress should choose what structured data markup formats to use as there are a number of different structured data markup formats. Google recommends microdata at the moment. (I understand it is not so easy to remove something as a number of themes depend on it. I also know that themes can easily remove the class.)
Code in question: https://github.com/WordPress/WordPress/blob/3.9-branch/wp-includes/post-template.php#L428
Similar: #26965
Change History (5)
#2
@
11 years ago
- Component changed from Appearance to Posts, Post Types
- Description modified (diff)
- Focuses template added
#3
@
11 years ago
The .hentry
class has been in core for so long (looks like 2008) that changing this now would most likely break a ton of sites.
The micro formats wiki cited is referring to the new h-entry
, which is actually an update to hAtom's hentry
(as per the wiki). While I am not too familiar with micro formats, I read over the wiki and looked at several of the examples sites the referenced as using h-entry
(some even running WordPress) and noticed that most use h-entry
on single and non-single articles.
#4
@
11 years ago
- Keywords close removed
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
Unfortunately we can't change the current behavior of hentry
in the way described above, without breaking back compat.
It can be managed on a per-site basis though, by unsetting the class name in a post_class
filter.
#5
@
7 years ago
I have outlined a fix at https://core.trac.wordpress.org/ticket/32326#comment:5
It involves adding a add_theme_support()
keyword and only adding hentry
if the theme doesn't support the new way.
Both approaches will break themes.
The verbiage of the wiki sounds more like an observation of how it's implemented, rather than a guideline. Although I'm sure it's correct.