Closed kdonovan closed 6 years ago
There is a reason I built the list as it is now. restaurant
is not a valid open graph object type, but restaurant:menu
is. The same goes for books
, business
. The only weird exception from this is product
, which is a valid object type, as well as product:group
. For the purposes of clarity, I added object types exactly as they listed in the reference.
Ah, I hadn't realized the intent was to document the explicitly valid OG types (I think some of the confusion came from how configured_name_key
checks against a regex rather than for explicit tag name matches).
I can see why you might want to explicitly include only the valid object types, but it turns out that to actually use some of those object types requires additional metatags that must also use 'property' rather than 'name'. e.g. for restaurants, a given restaurant’s OG tags also include things like “restaurant:contact_info:street_address” that must use the property field in order to pass FB’s validations - https://developers.facebook.com/docs/reference/opengraph/object-type/restaurant.restaurant/.
I may be misunderstanding the intent, but may I suggest either switching to a more permissive default list (as in my PR) or, if explicitly documenting the valid types is important, then expanding that explicit list to include any potentially required attribute for any of their object types (though that seems a long list and a moving target, which is why I lean toward the namespacing approach being cleaner)?
Valid point. Didn't realize there are exceptions like restaurant:contact_info
. Thank you!
I'm working with Facebook's OpenGraph, and I started this PR by explicitly adding a few extra "restaurant:xxx" properties which had been missing from
default_property_tags
. Looking deeper, though,default_property_tags
entries are already used as a regex, not an explicit tag match, so I just cleaned up the list to reflect that.