Questions about the Open Graph meta property="article:author" tag in Jetpack 2.8

According to Facebook, the article:author should in fact link to the Facebook profile of the author:

https://developers.facebook.com/docs/reference/opengraph/object-type/article

However, since OpenGraph is actually a protocol that can be used by other Social Networks and not just Facebook, it makes sense to me that the value of that tag be a link to the local WordPress user’s profile.

Because of this we won’t change our implementation of the tag; if you wanted to change it yourself, you can modify the plugin file here:

https://github.com/Automattic/jetpack/blob/master/functions.opengraph.php#L69

I can’t guarantee that editing the file there won’t affect anything else, though, and your changes will be overwritten the next time there is a Jetpack update. In any case, I hope that helps!

It does, thank you!

LOL Hi Richard,

Seems like this is a hot mess, since Pinterest tells you to just put your full name in the field.

Does Jetpack implement the profile:* properties? It seems that’s what the protocol really expects:

https://ogp.me/#type_profile

I haven’t tried it yet, but maybe if your article:author URL itself had profile:username set to a valid Facebook username then they would honor that while other sites like Pinterest could pull the first_name/last_name down. Probably not though, I have little faith in these companies and their self-selected standards.

Instead of editing the plugin files, you could also use the jetpack_open_graph_tags filter, like so:

function fb_custom_author_tag( $tags ) {

    if ( is_singular() ) {
        // Remove the link to Facebook Profile added by Jetpack
        unset( $tags['article:author'] );

        $tags['article:author'] = 'Your Name here';
    }
    return $tags;
}
add_filter( 'jetpack_open_graph_tags', 'fb_custom_author_tag' );

This way you could change the behaviour of the plugin on your site without having to change the plugin files after every update.

Does Jetpack implement the profile:* properties? It seems that’s what the protocol really expects:

Jetpack does indeed use the profile:* properties (profile:first_name and profile:last_name, queried from your user profile), but only on author archive pages since these are the only pages using the profile object type. If we were to add profile:* properties to pages using another object type (like article in the case of posts or pages), Facebook Debugger would throw errors, and reject Publicized posts.

Hey Herve! Thanks for replying. Of course no one should EVER edit the JetPack plugin of all things, since it’s updated constantly and extremely dependent on external services who’s APIs will change regularly.

About the article:profile property, the thing is that on the actual Open Graph Protocol site’s section about article (unlike on the Facebook Developers page) it states that the “article:author” property should be a “Profile” type object (or an array of them):

https://ogp.me/#type_article

• article:author – profile array –
  Writers of the article.

Where “profile” links to the profile type definition below.

This seems to clearly indicate that the correct method is to have URLs on your site with a set of “profile:*” properties for each author, then use those URLs as the article:author properties on your articles. Thus to implement it according to the protocol JetPack would link to the user page of the post’s author from article:author.

Of course despite this being logical and quite elegant, Facebook directly contradicts it in their Open Graph guidelines by telling you to link to a Facebook profile instead. Presumably their explanation would be that an individual’s FB profile IS an Open Graph “profile”, and that they implement the “profile:*” properties as outlined in the guidelines, but that’s not a good solution at all for an app (i.e. our WP sites) that wants to be a service-independent Open Graph citizen (with users who refuse to join Facebook). In any event clearly Pinterest is not able/willing to use a Facebook profile as a generic source of “profile:*” data, since they ignore facebook URLs completely.

The question is whether Facebook and/or Pinterest would honor a correct implementation of the protocol (by going to a WP user archive and fetching the profile:* data there), or whether it would be ignored or cause errors.

IMHO the official Open Graph way is the correct one and solves the actual problem of making the data service-independent. If it works then that’s what JetPack should implement by default, and if it doesn’t maybe Automattic can throw some influence at the problem and get FB/Pinterest to clean up their implementations ??

the correct method is to have URLs on your site with a set of “profile:*” properties for each author, then use those URLs as the article:author properties on your articles.
[…]
that’s not a good solution at all for an app (i.e. our WP sites) that wants to be a service-independent Open Graph citizen (with users who refuse to join Facebook).

Agreed. Jetpack actually falls back and uses your author archive page as article:author value if you didn’t create a Publicize connection to link your WordPress account to your Facebook account (ref).

Jetpack’s default behaviour consequently matches the Open Graph Protocol documentation.
It only changes if you’ve decided to link your WordPress account to your Facebook Profile. And even then, I would think it still matches the Open Graph Protocol documentation since it links to a page about the author. That seems like a good compromise to me.

The question is whether Facebook and/or Pinterest would honor a correct implementation of the protocol (by going to a WP user archive and fetching the profile:* data there), or whether it would be ignored or cause errors.

Facebook is ok with that, doesn’t throw any errors. The only problem is that your Facebook Updates don’t look as good as if you were using a Facebook Profile URL instead.

I’m not sure about Pinterest, to be honest. Their documentation states:

Article author, all line breaks and HTML tags will be removed.

https://developers.pinterest.com/rich_pins/

But I’m not sure what that means.

But if you decide to apply the code I posted above to respect Pinterest’s standards, Facebook will throw errors, and your Publicized posts will be rejected. Here is what I got in a small test:
https://i.wpne.ws/W0j9

So I’m afraid I can’t think of any solution that would make both Facebook and Pinterest happy, short of generating different tags for each crawler

And even then, I would think it still matches the Open Graph Protocol documentation since it links to a page about the author.

Scratch that; I just checked and Facebook doesn’t seem to include any Open Graph meta tags on Facebook Profile pages. So there are no profile:* properties there…

Agreed. I think the Pinterest version is clearly wrong and makes no sense at all, but in their defence Facebook is setting a terrible example by disregarding THEIR OWN STANDARD and telling you to do something that should make a correct implementation throw an error.

IMHO what FB needs to do is have a special property like profile:facebook_id or something that you put on a profile page and which is used for the sharing preview/promotion whatever else the “article:author” value is currently being used for.

I don’t know what any of us can do about it, other than bow to the whims of Big Blue (I don’t think that’s IBM any more). FWIW using a full name like that makes the debugger throw errors but your posts still look the same when shared as if there was nothing in the field.

I don’t know what any of us can do about it

Maybe post on StackOverflow? That seems like their main avenue of support nowadays.
https://stackoverflow.com/questions/tagged/facebook

FWIW using a full name like that makes the debugger throw errors but your posts still look the same when shared as if there was nothing in the field.

While manual sharing would work, Publicize would fail. As soon as the debugger throws an error, Facebook rejects posts posted from an app.