- Issue created by @thejimbirch
- π¬π§United Kingdom longwave UK
Someone can correct me if I'm wrong but I think the idea for handling this in XB is to do it the other way round, at least in some cases. For example for a summary text field or a specific image, you would add a field to the content type, and then map that field into an XB component via the UI, which would then also easily allow you to map the same field into the metatags. This should at least work for points 1 and 2, but not sure about 3.
- π¬π§United Kingdom catch
#3 is more about microdata for everything on the page.
Let's say you have a movie content type, and then you have a reviews component. How would you be able to apply schema tags to the author , rating and publication for the review. That sort of thing?
I think it is fundamentally the same underlying architectural discussion as π± [META] Support alternative renderings of prop data added for the 'full' view mode such as for search indexing or newsletters Active and π Refactor the XB field type to be multi-valued, to de-jsonify the tree, and to reference the field_union type of the prop values Active - e.g. if the components are populated by a field union, then the field union becomes a 'thing' which other code can reference using existing field API concepts, maybe a bit of new integration, to pull out that data into the JSON schema in modules like https://www.drupal.org/project/schema_metatag β . It's not about view modes, but the overall need is similar. But if it's not possible to do it that way, how do you externally access that data outside of XB?
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
#3++
But I think @catch in #4 is getting at "so then how can we consistently target the place in the XB component tree where that structured data is going to be presented" β is that right?
That's how I interpret this:
Let's say you have a movie content type, and then you have a reviews component. How would you be able to apply schema tags to the author , rating and publication for the review. That sort of thing?
If so, the answer to that is IMHO π± [later phase] [META] 7. Content type templates β aka "default layouts" β affects the tree+props data model Active . Which sadly is not being designed yet (which concerns me), and is not slated until after π± Milestone 0.2.0: Experience Builder-rendered nodes Active .
- π¬π§United Kingdom catch
@Wim hmm I didn't think that's what I'm saying or maybe I'm misunderstanding your comment.
I haven't really worked with JSON-LD , but:
RDF - you had to add little snippets of RDF markup inline with the HTML for each thing you wanted to mark up (this is how we ended up with title_attributes and various template variables from Drupal 7 onwards.
JSON-LD - you put all the schema.org data in a big json blob in a single meta tag.
So it's more like:
'given an XB-enabled content type, how I can configure which metadata applies to which component slot and then also extract the props so that I can put them into a JSON-LD array alongside the 'regular' entity fields?' - something like that.