WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 3 years ago

#30783 closed enhancement (wontfix)

Support Microformats 2

Reported by: dshanske Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Themes Keywords: has-patch close
Focuses: Cc:

Description

Microformats 2 is an updated, simplified version of Version 1. It's now stable and recommended for live sites and projects.

http://microformats.org/2014/06/20/microformats-org-turns-9-upgrade-to-microformats2

http://microformats.org/wiki/microformats2

mf2 is designed to make parsing of information more efficient, and could allow for improved behaviors without breaking backward compatibility, by making no changes to the microformats 1 implementation.

Attachments (1)

30783.diff (2.8 KB) - added by dshanske 4 years ago.
Add Microformats2 support.

Download all attachments as: .zip

Change History (28)

#1 follow-up: @peterwilsoncc
5 years ago

µFormats are mainly theme related. Some rough thoughts:

  • enable with add_theme_support( 'microformats2' );
  • enabling µF2 support indicates µF1 should be disabled by default
  • enabling both could be desired as big-search currently only supports µF1

There is a repo showing default HTML classes that need to be targeted on Github.

#2 in reply to: ↑ 1 @dshanske
5 years ago

Replying to peterwilsoncc:

µFormats are mainly theme related. Some rough thoughts:

  • enable with add_theme_support( 'microformats2' );
  • enabling µF2 support indicates µF1 should be disabled by default
  • enabling both could be desired as big-search currently only supports µF1

There is a repo showing default HTML classes that need to be targeted on Github.

You are correct it is mostly theme related, however, this is specifically about those areas generated by WordPress itself, which is a prerequisite for theme support adoption.

#3 @iseulde
4 years ago

  • Version trunk deleted

#4 @SergeyBiryukov
4 years ago

  • Component changed from General to Themes

This ticket was mentioned in Slack in #core by nvartolomei. View the logs.


4 years ago

This ticket was mentioned in Slack in #core by dshanske. View the logs.


4 years ago

#7 @dshanske
4 years ago

Since this is not something that is getting much buy-in, from what I can see, I'm thinking I will just do it myself.

Namely, I want to adopt the suggestion of an add_theme_support('microformats2') option which would add markup to all built-in WordPress functions that currently have mf1 markup, and possibly a few extra locations.

@dshanske
4 years ago

Add Microformats2 support.

#8 @dshanske
4 years ago

  • Keywords has-patch added

#9 @TomasM
4 years ago

+1 for adding microformats2 support.

Last edited 4 years ago by TomasM (previous) (diff)

This ticket was mentioned in Slack in #core by dshanske. View the logs.


4 years ago

#11 follow-ups: @pento
4 years ago

I'm cool with doing this, but I do have some questions, mostly around my lack of familiarity with microformats.

  • How does microformats discovery work? Do we need to put something in the header?
  • Is there a down side to ceasing microformats 1 support?
  • Can we support microformats 1 and 2 simultaneously?

If we can get away without adding yet another theme option, I think that would be the vastly more preferable method.

#12 in reply to: ↑ 11 @TomasM
4 years ago

I guess main reason to keep everything in v2 format (except body) is the simplicity of the code:

<span class="vcard"><a class="fn n url" href="http://waterpigs.co.uk">Barnaby Walters</a></span>

With microformats 2 this all becomes much simpler:

<a class="h-card" href="http://waterpigs.co.uk">Barnaby Walters</a>

#13 follow-up: @TomasM
4 years ago

Microformats creators say this:

Upgrading to microformats2

Upgrade sites

Second, if you publish any kind of semantic information, start upgrading your web pages to microformats2 across the board.

If you’re concerned about what search engines claim to support, there are two approaches to choose from:

Know that search engines are a trailing indicator, and as microformats2 usage grows, they’ll index it as well.
Or: Use one classic microformat (supported by all major search engines) at top of your page, e.g. on the <body>, in addition to your microformats2 markup throughout your pages. Search engines only really care to summarize the primary topic or purpose of a web page in their “rich snippets” or “cards”, and thus that’s sufficient.

Check out the latest validators which now include some microformats2 support as well!

http://microformats.org

Last edited 4 years ago by TomasM (previous) (diff)

#14 in reply to: ↑ 11 @dshanske
4 years ago

Replying to pento:

I'm cool with doing this, but I do have some questions, mostly around my lack of familiarity with microformats.

  • How does microformats discovery work? Do we need to put something in the header?
  • Is there a down side to ceasing microformats 1 support?
  • Can we support microformats 1 and 2 simultaneously?

If we can get away without adding yet another theme option, I think that would be the vastly more preferable method.

Microformats don't require a header. We already have microformats 1 in WordPress, but the implementation has some issues. The proposed patch has both the classic and the newer formatting in it.

I'd prefer to deprecate the older standard, but we go back to the legacy of the original inclusion. Too many things depend on the microformats classes as a styling element, which is what necessitated the theme option flag.

Whether we want to go as far as to remove all of the older microformats in favor of the new ones if the flag is set is certainly a question. But, a lot of plugins and themes style the output of certain fields based on the classic microformats classes, therefore it would cause some chaos.

#15 in reply to: ↑ 13 @dshanske
4 years ago

Replying to TomasM:

Microformats creators say this:

Upgrading to microformats2

Upgrade sites

Second, if you publish any kind of semantic information, start upgrading your web pages to microformats2 across the board.

If you’re concerned about what search engines claim to support, there are two approaches to choose from:

Know that search engines are a trailing indicator, and as microformats2 usage grows, they’ll index it as well.
Or: Use one classic microformat (supported by all major search engines) at top of your page, e.g. on the <body>, in addition to your microformats2 markup throughout your pages. Search engines only really care to summarize the primary topic or purpose of a web page in their “rich snippets” or “cards”, and thus that’s sufficient.

Check out the latest validators which now include some microformats2 support as well!

http://microformats.org

I'd personally love it, but I am only skeptical about it because of the backward compatibility issues that come with deprecating it fully. Maybe, like other deprecations, it should come in stages.

#16 in reply to: ↑ 11 ; follow-up: @peterwilsoncc
4 years ago

Replying to pento:

  • Is there a down side to ceasing microformats 1 support?

Neither Bing or Google list support of microformats 2 (mf2) officially, only microformats 1 (mf1). As mf2 provides a richer data set than mf1, I'd be surprised if they ignored it completely. Perhaps other will have more insight.

I've included both mf1 & 2 on my site for some time without any apparent ill-effect, webmaster tools rich snippets tester still parses everything correctly.

#17 in reply to: ↑ 16 @netweb
4 years ago

Replying to peterwilsoncc:

Replying to pento:

  • Is there a down side to ceasing microformats 1 support?

Neither Bing or Google list support of microformats 2 (mf2) officially, only microformats 1 (mf1). As mf2 provides a richer data set than mf1, I'd be surprised if they ignored it completely. Perhaps other will have more insight.

Bing and Google built there proprietary formats based of the original Microformats, no doubt in no small part because of the integration of these in WordPress, WordPress doesn't need to follow Bing or Google ;)

W3G Related Things: Microdata http://www.w3.org/TR/microdata/ and JSON-LD http://www.w3.org/TR/json-ld/

#18 @dshanske
4 years ago

Speaking as someone who is partial to microformats, I've always found them much simpler than any of the other standards. Usability is a great criteria. WordPress also has a history of Microformat integration that we can continue to iterate on.

#19 @pento
4 years ago

Thanks for the feedback, everyone!

It sounds like there's no real downside to supporting mf1 and 2 simultaneously, which would remove the need for adding a theme option.

@dshanske, could you take a pass at reworking the patch to do it that way?

Also, I'd like to see some unit tests to make sure we don't accidentally break them in the future.

#20 @dshanske
4 years ago

I'll work on the patch changes, and check them against a parser. I usually use http://pin13.net/mf2/ which I believe uses the project https://github.com/indieweb/php-mf2/

I really need to learn how to write unit tests.

#21 @dshanske
4 years ago

The only problem I need to solve is the hentry issue I started out with. If the mf2 and the mf1 are on the same elements, this isn't an issue. The current WordPress code puts hentry on everything, which isn't exactly correct. If hentry stays for compatability and the newer h-entry is not always there, it might be an issue.

Will have to think carefully.

#22 follow-up: @TomasM
4 years ago

@dshanske Do you predict what parts will have to be implemented in the themes? Or this WP patch will take care of everything?

#23 in reply to: ↑ 22 @dshanske
4 years ago

Replying to TomasM:

@dshanske Do you predict what parts will have to be implemented in the themes? Or this WP patch will take care of everything?

Regrettably it can't. It can only fix the markup that WordPress itself generates. The theme handles marking up a lot.

#24 @dshanske
3 years ago

I have been revisiting this. And aside from the hentry/hfeed issue, all the others can be addressed without a theme support tag. But the inability to change the behavior of hentry due backcompat issues is a breaker. It only works if classic and microformats 2 are on the same elements.

Ideas?

This ticket was mentioned in Slack in #core by dshanske. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by dshanske. View the logs.


3 years ago

#27 @peterwilsoncc
3 years ago

  • Keywords close added
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing after chatting with @dshanske. As h-entry isn't a one for one replacement of hentry, I can't see how the change could be made without breaking a majority of WordPress sites.

The only option is a theme option, and at the point it's just as easy to remove the classes with filters on post_class and body_class.

Note: See TracTickets for help on using tickets.