Core support for modern microformats v2

[discobot]

There’s already core support for the older v1 microformats, but it would be nice to modernize to the v2, and in particular for the proper use of h-entry and h-feed. Adding these on top of/in addition to the prior hentry and hfeed shouldn’t cause any conflicts.

See also: Getting Started With microformats2 – Microformats

---

Read-only archive: GitHub · Where software is built

Author: Chris Aldrich

Vote count: 17

Status: open

Tags:

• request-modify-feature

---

Comments

I’m not a big fan on microformats myself and I prefer using schema.org markup. In order to get this to pass google testing I have to create many filters to remove all of the microformat classes that are already added. As long as there are always filters that can be used to remove it I guess it would be okay, but the two ways of adding this information do not work and play well together and google’s prefers schema.org

~ posted by John A. Huebner II

What you are stripping away is old microformats from when Google was pushing them. Now they are pushing something else.

This is why I find microformats2 attractive. We need to stop designing for large corporations that profit from sucking up our user data.

Design for the web not for Google.

Having proper mf2 (and you can have Linked Data as well… See SemPress) allows some really cool functions that will help return the web to the people.

~ posted by Greg McVerry

I can help on this one. And if you create tools to make adding structured data of all types easier, that will also accomplish the goal. WordPress has body and post clas, but not content class. It doesn’t have filters for attributes of posts and body in general.

~ posted by David Shanske

We’ll have to agree to disagree on micoformats vs. shema.org. I find microformats limited in scope. Good for the average things that a business might use a site for, but lacking when it comes to the scope of item types that can be marked up. I agree about google, and I dislike pushing their agenda. But for my clients I have to choose the one that will do the best job.

As I said, as long as there are filters so that I can remove the classes I don’t necessarily care.

~ posted by John A. Huebner II

Then do both, mf2 and schema.org is not exclusive to each other.

Limitations of schema.org exist as well, quite a lot of them, to be fair. Just an example: try marking up a resume with it…

( I set up my own site as “google-valid” schema.org, mf, and mf2: Schema Markup Testing Tool | Google Search Central  |  Google for Developers )

~ posted by Peter Molnar

@David Shanske: There is actually no need for a “content class”, as its entirely depending on your current theme how that data is displayed. So if you use a microformat v2 enabled theme, all is well

Also, most if not everything mentioned here could be accomplished with a plugin as well. Parsing the content if required? Use Simple HTML DOM or one of the many XML-based DOM parsing options in PHP. Et voila! All done.

cu, w0lf.

~ posted by Fabian Wolf

This is probably a large enough change that it should start as a plugin. Our place for that is ClassicPress Research · GitHub.

If you’re interested in getting something going here, DM me on Slack and I’ll get you set up.

Also, during the development of this plugin we can begin adding filters into the core software as needed. This shouldn’t be a problem for v1 and doesn’t require a petition (see “minor modifications” exception at ClassicPress Governance | ClassicPress).

~ posted by James Nylen

James we will start but we have tried for three years to inject classes into themes using a plugin, because of old microformats this is difficult. We created a fork of CP and will see if we can remove mf and get mf2 in by plugin or if it requires stripping away old metadata…If folks are adding JSON-LD we can do both at same time.

~ posted by Greg Mcverry

As I said on Slack, perhaps a good first step for ClassicPress core would be to add actions and filters to make this easier. Happy to discuss further.

~ posted by James Nylen

Perfect just navigating multiple Slack groups. Sorry I missed. @david shanske started… First step seeing if our current theme works with the CP flavor of 4.9.5…

Then we can look to filters. Will move discussion to Slack for dev/code and then if need be talk about issues and possible PRs

~ posted by Greg McVerry

[viktor]

A possible alternative solution to microformats in the core is to remove them, so the theme/plugin can handle it properly. Google prefers JSON-LD anyways. I’ve created a petition for the removal, in case anyone is interested.

Remove microformats from the core

Context There is a petition to upgrade microformats to v2 in the core. Instead of continuing to support microformats, which rely on CSS classes, they should be completely removed from the core as bloat. There are several reasons for this: This is plugin and theme territory and is usually handled by either an SEO plugin, a dedicated schema plugin, and theme developers implement their own markup. Google prefers JSON-LD: The markup is not interleaved with the user-visible text, which makes nes…

[joyously]

I proposed a generic way to handle this several years ago at WP.
This is tied in with my petition to have core handle the front end more because core would have the function for filtering the attributes that every theme would use.
I don’t think core should be doing the microformats or the schema. Let the plugins that know about the site’s data do it, but core can provide the functions.
But definitely, core should be fixed for hentry and hfeed.

[viktor]

This petition will be closed. Preference will be given to removing microformats from the core:

Remove microformats from the core

Context There is a petition to upgrade microformats to v2 in the core. Instead of continuing to support microformats, which rely on CSS classes, they should be completely removed from the core as bloat. There are several reasons for this: This is plugin and theme territory and is usually handled by either an SEO plugin, a dedicated schema plugin, and theme developers implement their own markup. Google prefers JSON-LD: The markup is not interleaved with the user-visible text, which makes nes…