Updates Dawn to use the new structured_data filter

[lhoffbeck]

PR Summary:

Replace product and article structured data generated in the theme with structured data generated by the structured_data filter.

Why are these changes introduced?

Updating themes to stay on the greenpath of structured data developments is currently pretty painful.

What approach did you take?

Other considerations

Decision log

#	Decision	Alternatives	Rationale	Downsides
1

Visual impact on existing themes

Testing steps/scenarios

• Step 1

Demo links

• Store
• Editor

Checklist

• Added PR summary for release notes
• Requested review from UX (Only for changes that are affecting the experience or perceivable visual details)
• Created a ticket for the help.shopify.com documentation team about updates to theme settings. (Internal-only task)
• Followed theme code principles
• Linted with Theme Check
• Tested on mobile
• Tested on multiple browsers
• Tested for accessibility

[bakura10]

That's a very nice update. A few notes though:

• The schema used in Dawn is incomplete. I've maintained one over the years, that also include some extra things that would be nice to have: https://gist.github.com/bakura10/7704584dc866d7ae3754789a6fdc66b4
• It would be better to have support for blog post ({{ article | structured_data }}), and one for shop ({{ shop | structured_data }}) that would output this: https://gist.github.com/bakura10/7704584dc866d7ae3754789a6fdc66b4#file-microdata-schema-liquid-L234

[willbroderick]

May I suggest this be implemented as a containerless {{ structured_data }} added to layout/theme.liquid?

This would allow Shopify to contextually include Organization, WebSite, Article, BreadcrumbList, FAQPage, anything else that might be useful, and adapt to best practices in future.

[lhoffbeck]

That's a very nice update. A few notes though:

• The schema used in Dawn is incomplete. I've maintained one over the years, that also include some extra things that would be nice to have: https://gist.github.com/bakura10/7704584dc866d7ae3754789a6fdc66b4

Awesome, I'll take a look at the gist 🙌 This approach will let us roll out support for new features like ProductGroup and multipage (hello combined listings) without requiring theme updates

• It would be better to have support for blog post ({{ article | structured_data }}), and one for shop ({{ shop | structured_data }}) that would output this: https://gist.github.com/bakura10/7704584dc866d7ae3754789a6fdc66b4#file-microdata-schema-liquid-L234

Totally, it's on the roadmap

[lhoffbeck]

May I suggest this be implemented as a containerless {{ structured_data }} added to layout/theme.liquid?

This would allow Shopify to contextually include Organization, WebSite, Article, BreadcrumbList, FAQPage, anything else that might be useful, and adapt to best practices in future.

That's great feedback, I'll take this back to the team

[tairli]

What would be the recommended way to integrate product reviews?
It was popular to add the data from metafields into the ld+json element like in @bakura10 gist.

[bakura10]

@lhoffbeck , just an idea here, but what about simplifying this to:

{% structured_data %}

or:

{{ request | structured_data }}

This way Shopify could automatically generate either product or blog post metadata, but also the website metadata that you guys already have ; see my Gist for all the data). That would simplify it a bit and would handle any other metadata that Google might add in the future.

[lhoffbeck]

@bakura10 yeah good idea, I have it in a backlog ticket. It could be a both/and improvement along with this :)

What would be the recommended way to integrate product reviews?
It was popular to add the data from metafields into the ld+json element like in @bakura10 gist.

@tairli great question! Shopify-generated data only includes information that does not require any inference. Since reviews tend to be stored as metafields and don't have a standard definition, they don't fall under this case. However, the Shopify data can be trivially extended by adding another block with the same @id to the page. For example:

<!-- data from {{ product | structured_data }} -->
<script type="application/ld+json">
{
   "@context":"http://schema.org/",
   "@id":"/products/my-product#product",
   "name":"My product",
   ... other fields ...
}
</script>

<!-- @tairli's enhanced data -->
<script type="application/ld+json">
{
   "@context":"http://schema.org/",
   "@id":"/products/my-product#product",
   "aggregateRating": {
        "@type": "AggregateRating",
        "ratingValue": "5",
        "reviewCount": "100"
   }
}
</script>

[bakura10]

@lhoffbeck I don't agree with that. This is what the standard rating metafield is for :).

[lhoffbeck]

@bakura10 Because it's a metafield the type is standardized but not the data, so surfacing it to everyone using the filter could return the wrong values. Something we could potentially explore is adding an option in the metafield definition to surface it in structured_data 🤔 For now I'd recommend extending though.

[bakura10]

Makes sense, but I think this will cause us a lot of support :/. Not all review apps actually output this, so merchants will see the missing review and will just come back to us on how to add it. It would definitely be needed for merchants to have control over that.

[joshistoast]

One edge case to look out for is 3rd party review apps, would it be worth exploring an argument expecting a specific reviews structure so we can format and use those?

[lhoffbeck]

Thanks @joshistoast ! This should support 3p reviews apps already, the flow would look something like this:

• Review app sets metafields on the product
• Merchant's theme outputs product structured data using the filter
• App injects structured data for the review into the storefront, with an "@id": "{{ product.url }}#product". Google combines the app block with the structured_data filter block by the @id prop.

App dev guidance to the merchant would be something like: if you use the structured_data filter, review app structured data works automatically. If you customize structured_data, either ensure an "@id": "{{ product.url }}#product" is present or include this review block: {"aggregateRating": ...}

would it be worth exploring an argument expecting a specific reviews structure so we can format and use those

Can you tell me more about what you're thinking here?

[joshistoast]

Can you tell me more about what you're thinking here?

I'm more-so curious to overriding values in case the shape of data is odd or id I's like to change it in some way, in which case I'm sure the traditional structured data approach would be best.

@lhoffbeck

[lhoffbeck]

Can you tell me more about what you're thinking here?

I'm more-so curious to overriding values in case the shape of data is odd or id I's like to change it in some way, in which case I'm sure the traditional structured data approach would be best.

@lhoffbeck

@joshistoast Gotcha. Google doesn't seem to allow for overriding values by linking multiple structured data blocks by @id, only extending the definitions. If you need more customization than that, then continuing with the liquid-generated structured data is probably your best bet.

[lhoffbeck]

I removed the property-based SEO from this file. Google interprets this as a duplicate item when present along with ld+json: https://search.google.com/test/rich-results/result?id=6ClESn2Nb85_l_LNc1XbVA

[PaulNewton]

Another reason we need to be able to override an objects properties , create custom objects*, or some sort of preprocessing in liquid.

Google doesn't seem to allow for overriding values by linking multiple structured data blocks by @id, only extending the definitions. If you need more customization than that, then continuing with the liquid-generated structured data is probably your best bet.

And shopify doesn't let us override object values either , for countless business scenarios situations such as contact-for-pricing ad nausem infinity there's all the surfaces that have to be edited AND merchants then get locked out of future enhancements like the structured_data filter that won't have granular parameters.

Though if there's a non-liquid workaround to that let us override ld+json with just another ld+json block containt only the slice that needs to be customized that would be just as amazing and simplify a lot of customizations by taking advantage of the structured_data for the core of the admin data then simple snippets for the one offs in the theme without the error proneness of editing themes liquid-templated-json, or capture & replace tactics.

*also can't use metaobjects because their access structure doesn't let use create pseudo products we could slap in. i.e. {% assign catalog_products = shop.metaobjects.catalog_product.values | first %} ...metaobject forloop... {{ catalog_product | structured_data }}

[tyleralsbury]

Tested. Loving the net -71 line diff, too. :chefs-kiss:

[haroldao]

An error is returned in the article template...

[lhoffbeck]

@haroldao can you send me which page this is on?

[haroldao]

I imported the updated theme on my demo store

[lhoffbeck]

Can you drop a link so I can take a look?

[haroldao]

Yeah sure,

https://harold-theme-dev.myshopify.com/blogs/news/article-2?_ab=0&_bt=eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaEpJaU5vWVhKdmJHUXRkR2hsYldVdFpHVjJMbTE1YzJodmNHbG1lUzVqYjIwR09nWkZWQT09IiwiZXhwIjoiMjAyNC0wNS0zMFQxNjo1Njo1OC44ODVaIiwicHVyIjoicGVybWFuZW50X3Bhc3N3b3JkX2J5cGFzcyJ9fQ%3D%3D--ba89f82cc7cd0c8345fd8ed22075705877884806&_fd=0&_sc=1&key=65835c145ec874592a1d2daf3e489b6c57f36d8b8b42bc41f07f8cb06a019304&preview_theme_id=137161244838

[haroldao]

It seems like it has been fixed! Ty @lhoffbeck!

[lhoffbeck]

No problem! Thanks for reporting it :)