Meeting of the Experience Builder Initiative 2024-10-24 [#3484039]

0️⃣ Who is here today? Comment in the thread to introduce yourself. We’ll keep the meeting open for 24 hours for all time zones.

griffynh	:wave: Griff, Aus
thejimbirch	Jim. thejimbirch. Returning to talk about structured data to be available beyond experience builder.
kimb0	Kim :wave:
guptahemant	Hemant from india
lauriii	Lauri, currently in DrupalCamp Spain so might be slow to respond :wave:
mattgyver	Bonjour ! Here bc i was curious to know if i could contribute
brianperry	Brian here following along...
eclipsegc	following along

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread, and we’ll open threads for them as appropriate.

thejimbirch	In the following thread, the response from one of the initiative leads was because the idea I presented was not in an unpublished specification document it wasn’t worthy of consideration. https://drupal.slack.com/archives/C072JMEPUS1/p1726839988624379?thread_t... (edited)
thejimbirch	I would like to discuss the idea that data created from within the experience builder should be available above just the presentation of the data on the page.
catch	@thejimbirch have you seen[#3462219] ? meta tags might be another use case for that issue.
thejimbirch	Those two issues are definitely along the same needs. Thanks!
catch	My impression is also that none of this has made it into the requirements spreadsheet but should have, so additional use cases would help.

2️⃣ Subtopic 1: Theme builder

3️⃣ Subtopic 2: Page builder frontend

4️⃣ Subtopic 3: Data model/persistence layer

5️⃣ I’m not sure where to start, but I want to contribute to Experience Builder.

griffynh	Here’s a setup guide for XB: https://www.drupal.org/community-initiatives/starshot-demo-design-system...’s a prioritised list of the critical issues in[#3454094]. There are still some unassigned issues there.There are also plenty of issues in the queue ready to be picked up: https://www.drupal.org/project/issues/search/experience_builder?project_...
griffynh	https://drupal.slack.com/archives/C072JMEPUS1/p1727951759874059?thread_t...

6️⃣ Wins - what wins have you had since the last meeting? Share your successes!

7️⃣ Are any sync meetings required this week?

8️⃣ Weekly updates - What have you been working on? What’s up next? Need assistance with anything? Any blockers?

9️⃣ @larowlan “I’d like to chat about import maps -#3398525: Add an API for importmaps”

larowlan

this unlocks allowing contrib things to provide react things to xb

1️⃣.0️⃣ @thejimbirch “data created from within the experience builder should be available above just the presentation of the data on the page”

griffynh	Related: https://drupal.slack.com/archives/C072JMEPUS1/p1729730274030059?thread_t...
thejimbirch	I said unpublished, but I should have said privately owned, comment only Google sheet.
thejimbirch	The underlying issue is the same with paragraphs and/or blocks in a layout, that the structured data of a particular page builder built page is not available at the node level to use as meta data for that node. (edited)
John Pitcairn	I currently have a layout paragraphs based site that has a "promote" checkbox added to some paragraph components (title, media, date, tags). If that is checked, then when the node is saved we hook_presave() that component's relevant data into an appropriate meta field on the node. You're thinking of some mechanism like that?
larowlan	this is the same question catch has been raising about the data
larowlan	the use case he has been flagging is e.g. search indexes
larowlan	you want to be able to pull out certain fields for indexing without having to drop back to 'rendered entity'
larowlan	although that could be met with a search api processor (search api is looking to be frontrunner for search in drupal cms)
larowlan	https://www.drupal.org/project/experience_builder/issues/3462219
larowlan	and[#3477428]
lauriii	@thejimbirch do you have a specific scenario in mind that you could share? :blush:
lauriii	I saw that you mentioned meta tags in the earlier thread. Can you elaborate on what you are trying to accomplish?
acbramley	This ties into a question from last week about node edit forms. Is the idea that XB will take over the entire authoring experience of an entity? I.e no standard entity form? @lauriii E.g with LB we have Edit and Layout. We use the edit form for more "metadatery" fields (e.g a teaser image for a list view). Surely entity forms stick around?
lauriii	The concept of a form for meta information will stick but the goal is to be able to edit that directly from XB without having to navigate between two different pages.
thejimbirch	Thanks for asking. I am thinking of three scenarios for SEO. A summary of the content of the page that could be used in description meta tags and schema vocabularies. When we just had a body field, the node:summary token was great. Once we componentized, it got a lot harder. Images that are representative of the page. Used in social meta tags and schema.org vocabularies. Schema.org vocabulary markup for individual components. This could be done inline in the component’s markup or bubbles up the the page. Breadcrumbs, Frequently Asked Questions. Search boxes, and other parts of the page can have their own schema markup.
lauriii	@thejimbirch That seems something that definitely needs consideration. Thanks for raising that! Could you file an issue for this in the XB issue queue? :crossed_fingers: I need to do some thinking around this conceptually.
larowlan	some of those could still be fields on the node right? like author/title etc. We have summary/teaser image fields when we use LB. Same here I assume
larowlan	added[#3483301]
	Also added[#3483302]
thejimbirch	Thanks!