Let's close this one. We can deal with the rest in 📌 Allow saving component compositions as sections Postponed / follow-ups to that.
kristen pol → credited lauriii → .
Merged this based on @tedbow approval. I had to bypass the approvals because there wasn't approval from /src/Entity code owner. We got review from @wim leers and this is adding a new entity type so it seems fine to bypass the approval there.
+1 for expanding this outside of Node in targeted follow-ups.
We still need this but isn't this pretty simple in the 0.2.0 scope because of 🌱 [Research] Landing page integration Active ?
I'm removing the Display Modes example from the issue summary since that is working by design. The remaining use cases are valid and should be addressed one way or another, either in core or by guiding how contrib modules should approach this.
Here's how I understand this issue. It seems that this problem is specific to the class attribute. It seems that the root cause to the problem is that ckeditor5_style defines <$any-html5-element class> as it's elements, which then triggers the validation if anyone tries to add a class attribute to a HTML5 element, because theoretically, they could add that using the style plugin. The plugin documents that the class is dynamically restricted to a subset of class attributes, but this is not taken into account in the validation.
Requiring the use of the style plugin might be problematic because it a) requires someone to know and specify every class that may be used and it b) exposes them through the user interface (which might not be always desired). Because of this, people are specifying class as an attribute in the source editor plugin.
If this is a somewhat correct understanding of the problem, it seems that an ideal solution would be to special case the class attribute on the style plugin somehow. This way we could allow adding class attribute to elements even though it's an attribute that's supported by the style plugin.
It seems that #59 is proposing something pretty close to this. However, it seems to be adding a new syntax for this. I'm not sure that we need a new syntax for this; in my mind we would just special case the class attribute to not trigger this validation.
This is not so much about rendering PHP errors vs not. This was about where and how those errors should be rendered. For example, the error in the issue summary, is not even something that happens as part of the preview request, it happens on the component preview request. We should improve the error handling so that errors that happen during API requests, never end up in the preview.
Explaining Nodes as pages is already a simplification of the reality because they are not just pages. This is why we are already not calling them Pages, but Content in the product. I believe that for a non-technical user the easiest way to explain Nodes is by the purpose that a Content Type has in the specific site; e.g. product, product collection, event, blog, press release, etc. They may generate a page but often they are used for more than that. For example, a product could generate a page, but it could be also used for "micro-content" because you may want to create a list of products or embed a product as part of a blog post.
When you have a page that is not modeled (i.e. Basic Page), it is just a page because it provides only limited re-use. XB plans to separate this from the re-usable modeled content: 🌱 [Research] Landing page integration Active . Based on user interviews we conducted this spring, this maps well with the mental model that users have. Here's an anecdote from one of the interviews:
Interviewer:
You have this content type called page. What is that?
Participant:
That's actually the content type that I use the most. Whenever we have something that's got more like set structure, that's when we use a content type that is more kind of identified and clear. But whenever we have something that needs to be a little bit more flexible, we use the page. Page is much more bare bones than the more specific content types.
Many products like Webflow, Framer, Wix explain Nodes as CMS collections. I think this is a smart way of explaining modeled content to the site builder. It's communicating that unlike pages, modeled content is something that allows you to create lists besides being able to have a page. While their content modeling capabilities are more limited than what Drupal has, I believe that they do a better job at explaining their content modeling capabilities in relation to unmodeled content. I don't think we can adopt this quite as is because in Drupal you can create lists that combine multiple content types.
How does Block Content fit this thought process? Unlike Nodes, Block Content is for content that you would never want to display as a page or list for the end-user. It could be used for example for a hero that you want to display on multiple pages or a cookie banner. It would be rare for someone to create a page for a hero block or a list of hero blocks for other than administrative purposes.
This allows us to explain why for example Location should be a content type, and not a type of Block Content; because it's something that you may want to be able to list for the end-user, it's something that you may want to expose as a page. This helps explain why we need this change; to allow site builders to create modeled content without forcing them to have a canonical page for it.
It seems fine to raise the minimum requirement to the latest minor of Drupal 10 and 11 ^10.4 || ^11 to ^10.4 | ^11.1.
I think we should go with the standard permission approach we've taken for entity types in core which as pointed out by #3 requires author/user for the entity. The permissions seem a bit more complex than what may be needed but we would have to go through some extensive thinking to deviate from the existing pattern.
I don't know what's the best way to store this but based on what we have in the designs, I'm anticipating we'd want to get following information:
- Who last changed a page (and when)
- Who created the page (and when)
- Who published the page (and when)
Would the author/user reference provide us what we need to provide this?
Clicked the merge because it looks like there's plenty of approvals there. 🚀
smustgrave → credited lauriii → .
Discussed this with @longwave and @jessebaker. We believe the extension_type key is too narrow and doesn't account for other needs we have for these. Essentially what we need is information on what is the source of the "component". Potential sources are: Blocks, Theme Components, Module Components, Elements, and JavaScript components. Each of these sources then have categories within itself. Here's a visualization of that:
@ckrina is out until next Wednesday but we could reach out to her then. I have discussed this a while back with @ckrina on a high level.
Here's the latest design I've seen for this:
Essentially in this design there would be an Overview link that would allow user to navigate to the parent link. I don't think this a finalized design so we probably want to wait for input from here before we get too far on the implementation.
If in Core it sounds like maybe we need a mechanism either to opt in or opt out of having a direct access link. If opt in would need to update a lot of a contrib projects but at least that makes it a conscious decision. Perhaps a new attribute in menu link?
We could potentially automate that; the pages we don't want to display in the navigation are always rendered by \Drupal\system\Controller\SystemController. It's a special controller designed to render menus. We would only want to link from the menu when the controller is something else, e.g. \Drupal\block\Controller\BlockListController.
Core needs to provide direction for how to fix the Simple Blocks and Paragraphs examples from the issue summary. This might lead into change in either Core or these modules.
Ideally the fix for the Simple Blocks and Paragraphs would keep the Display mode use case intact because the Display mode example is as it is by design. This is where a contrib module could change the preference for the users that prefer a different behavior.
For context, it was decided earlier that access to the second level menus would be limited in the menu. This is due to the reason that Drupal Core uses those primarily to display the same information as what would be in the navigation but as a page. As a result, users would likely develop a pattern of not accessing those pages. The UX team did research to validate that the pages aren't considered to be useful.
The tricky bit is that there are some edge cases where the second level menu is actually useful. This is not great from UX perspective, because if the user has developed a pattern of not accessing the second level pages, they would have challenges to find these pages. The original plan was to provide an alternative affordance for this use case, to make it easy to differentiate between the two use cases so that users know when to expect something useful.
What is in the MR doesn't fulfill this. I think we need some direction from @ckrina on how we should handle this scenario.
It looks like feedback on MR has been addressed.
@mglaman The feedback has been getting more to the specifics so it's fine if you want to start work on this.
kristen pol → credited lauriii → .
I think XB should be built with node in mind from the start, otherwise we're losing functionality that we currently have with Layout Builder out of the box. Without node support, I think real world adoption will be slower and developers will have less confidence in adding XB to new sites.
We couldn't be early adoptors of this before it supports node, since we would need to run both Layout Builder and XB side-by-side, which doesn't feel worth it.
I understand that this is being built with the idea of rapid iteration and it's been said that supporting nodes out of the box will be done before the 1.0 release, it just feels like we should be fixing the node related issues as we go rather than kicking the can down the road and saying we'll figure it out later.
I personally don't think that the intent of the proposal is to kick the can down the road. We are actively working on making the node specific functionality to work. At the moment it looks like that we will have support for nodes without additional bundle fields before the end of the year.
I totally understand that Experience Builder will be only so useful until it can support structured content like nodes. I my mind, support for structured content is more than just being able to edit the field values within Experience Builder. Support for structured content includes also being able to build view modes using the field values in Experience Builder. Support for structured content is intended to be worked on early in 2025. This is to say that it's not something we're intending to leave last minute before the release.
This proposal allows us to start collecting feedback on a slice of Experience Builder before we get there, which should ultimately lead in a better product at the time of release. That said, this is not being done just for the short term gain. UX has identified that the basic page concept is somewhat distinct from the structured content and that at least in some UIs, that should be prioritized over other types of content. Here's an example of one screen for this:
This seems related to
📌
[later phase] Support matching `{type: array, …}` prop shapes
Postponed
. I wonder if we should add a new requirement for components; i.e. to not have type: array properties?
This is also pointing another problem; we need a way for components to indicate if the component should be available for Experience Builder. I would not expect anyone to ever want to use the "Toolbar button" component in Experience Builder.
Moving to the Experience Builder queue since this seems like a problem most likely related to it.
Note: as can be seen in the component that has been linked in the issue summary, the property triggering the error is not required. In this case, the component props are valid as optional properties are allowed to not provide an example.
This is not an issue to fix the specific error. I opened 🐛 PHP warning on image props without examples Active for that. This issue is to improve the error handling, because I would not expect PHP errors from the small preview iframes to render in the preview canvas. I also would not expect errors to render inside the small preview iframes.
Tested this manually and the behavior seems fine. I agree it would be nice to make the interactions a bit smoother but I wonder if that should be left to a follow-up issue?
Maybe we should add some test coverage for this change?
lauriii → created an issue. See original summary → .
Would it be possible to provide a list of blocks that this impacts and what are the contexts they depend on? This would help me understand the impact of this and would make this more actionable for design.
Is there some existing UX for this in the Block module or Layout Builder?
Now, we can achieve that by having a config setting within XB for which node type is the one that "New page" creates, but the fact that user research led to designs that partition in this way leads me to wonder whether there's a real conceptual difference between un-modeled pages and modeled content, and whether creating a new entity type for un-modeled pages would help us both refine our understanding of that difference, and optimize various Drupal UIs accordingly.
From a content creators perspective, it's different from the rest of the content types because it doesn't come with a predefined template / structure. They are also more tied to the specific page that is being built (i.e., usually less or no additional view modes, not being displayed in lists, etc.). To a large extent, you could accomplish this with a content type, although it's not guaranteed to hold the same meaning across sites.
One related quote from a user interview earlier this year:
Interviewer: "You have this content type called page. What is that?"
Participant: "That's actually the content type that I use the most. Whenever we have something that's got more like set structure, that's when we use a content type that is more kind of identified and clear. But whenever we have something that needs to be a little bit more flexible, we use the page. Page is much more bare bones than the more specific content types."
Currently, Standard Profile provides that via the "Basic Page" content type, but does it actually make sense for "Basic Page" to be one content type among Article, Product, Event, JobPost, etc.? Or is the concept of "Basic Page" somehow special, different from those other content types? And would Drupal be easier to understand if we leaned in more into that specialness?
Whether we display the default page type as a content type impacts also users building the site. I don't have any user research suggesting one way or another on this.
My thinking on what makes sense here was shaped more by what the majority of the players in the market are doing. Having a default page type which could be used for one-off content, and modeled content for creating display templates that display the same content different ways (i.e., multiple pages or lists) is a fairly standard approach that many proprietary CMSs targeting non-enterprise sites have adopted. In Drupal, this becomes even easier to explain once we land ✨ Allow disabling a route for a bundle and adding additional routes for view modes other than 'full' Postponed and ✨ Support adding additional routes for view modes other than 'full' Active because it makes Nodes the central place for modeled content, not only for pages.
A key decision we need to make eventually is if we allow adding fields to the default page type or not. Some more complex sites use custom fields even for their landing pages, not to change the display but as meta information (e.g., tagging to build navigation views or to show related pages). Initially it's fine to not allow custom fields because for a simple site, we can define what are the fields needed to meet most use cases.
We can get at least a sense on what are the required capabilities because shipping with this type of content type is really common. For example, Rocketship comes with a page content type, Ignite comes with a page content type, and Wingsuit Kickstarter comes with a landing page content type. At minimum, we'd need to support meta tags and be able to exclude pages from search.
I discussed with @bostonjillian and @mglaman earlier today to find out if there are open questions we'd like to validate. In regards to displaying pages separately, we agreed that we didn't have open questions to be researched at this point around this. Most of the open questions I have are more around what it is we allow users to do to customize the default page type vs what we don't allow them to customize. We don't have all the answers and we may need to refactor this later but based on my discussion with @mglaman, at least he wasn't too concerned about the refactoring at this point (even if in the worst case we'd need to build a best effort upgrade path). Based on that, I'd be fine for us to proceed on this issue. We need to revisit this anyway, because regardless of the approach, we'd need to test the solution with the rest of the product later.
We also discussed the use case where users need to go from the default pages to modeled content. We discussed how challenging it would be to do this outside of very specific simple use cases since the default page type doesn't come with the fields the target content type would be likely to have. This would make any migration from the default page type to modeled content only so useful. We thought that given how many challenges there are with moving from a landing page to a modeled content, this use case would be better solved by focusing on educating users early on how to think about content modeling and why they should care.
Thank you for opening the issue @drpldrp! If you have a chance, it would be great if you could file a merge request → since our CI doesn't work with patches anymore. 😊
@drpldrp It would be helpful if you could file a new issue, and link it from here 🙏
The component insert should be cancelled at least by pressing Esc-key or by dropping within the admin. UI (i.e. sidebars or the top bar). There might be other interactions but we could start with these.
griffynh → credited lauriii → .
I reverted back to WCAG 2.1 (for now) until there's a decision what are we striving for. Usually when we make changes to the core gates, we announce those changes at least to some extent. AFAIK this was a change that the maintainers weren't aware of so it would be at least good to get a sign-off from them.
Do folks often reference landing pages from regular content like this, as an entity reference? I'm not saying it shouldn't be allowed. I'm just curious. Usually its landing pages which reference specific types of content used in collections (events, articles, etc.) In my experience things like articles usually reference one specific type of thing "Related articles" or "Documentation" or "Suggested products." In this case it could be a direct reference to a landing page.
I've been looking for use cases where sites would reference landing pages. What I've seen many existing users of Layout Builder do is set up simple content model to simplify the entry of meta tags fields for content editors. This would include title, description, and an image.
In a call today where I walked through some customer use cases, I discovered that in some cases, these are being used to create a teaser/card view mode to build multi layered navigation. This could be used to create generic navigation patterns that some sites adopt. For example: https://www.landelijkegilden.be/over-ons and https://www.nokia.com/industries/. The Nokia example is interesting because it's essentially a nested tree of landing pages. It might be better built not using the page content type but especially in the case where the site isn't particularly large, this works fine.
How would it impact our decision if we there was a chance that in future we may decide to allow adding additional view modes to these landing pages? Is this something contrib could enable if we decide to not support this but it's something that is needed in some cases?
This made me realize also that just exposing the meta tags fields is not enough. We'd likely have to build something more custom for it because the meta tags field doesn't provide sufficient controls over meta tags – specifically it doesn't allow adding images. This obviously raises the question; what source should we use for the image, i.e. media (and which bundle) vs image field?
While potentially helpful, this seems like non-standard behavior. Assigning to @bostonjillian to review the idea before we proceed to implement this.
@be-a-helper This seems outside the scope of this issue. Could you file a new issue for that question?
Few interesting edge cases that came up in the design process:
- User should be able to undo adding or “deleting” a section from the library (I.e. CMD+Z)
- User should be able to undo inserting a section (I.e. CMD+Z)
I'm wondering if this has implications on the data model?
I'm still working through the UX implications with @bostonjillian. I'm planning to meet with her tomorrow.
I'm not a specialist in trademarks but it seems that Apple has a product called Freeform. It probably means it's better for us to avoid using that as the name. Also, the human readable name that has been used so far has been just "Page".
lauriii → created an issue. See original summary → .
griffynh → credited lauriii → .
I don't really understand the dev/prod toggle discussion here - sites in dev will either have broken email sending (on local) or they should be configured not to send emails at all (maillog or one of the other approaches). I do, out of paranoia, uncheck this box even if I have maillog or similar installed but that is years of superstition and past bad local development practices (and memories of before email spam checks were stricter and you could successfully deliver emails from postfix running on localhost with phpmail).
There isn't really much into it. 😅 I'm doing the exact same out of paranoia (unchecking email checkboxes on dev regardless of using MailHog), which was why I was thinking that we could consider changing the default value depending on this setting. This isn't a critical part of the issue and I think we can discuss this in a follow-up if we want to.
There is now design for this in: https://www.figma.com/design/1sj0mnVdLFdYihrkAhR43u/Experience-Builder-%...
Based on this, the key separation is the source of the components; module vs theme. The module provided components are listed under "Extensions" and theme provided components are listed in the sidebar "Library".
Inside "Extensions" and "Library", the categories are defined by components and there are no built-in categories there. These can ideally leverage ✨ ComponentPluginManager must implement CategorizingPluginManagerInterface Active .
There's also no built-in components. There are Blocks which are exposed under "Dynamic Components". There is also a special category "Elements" in future which is reserved for Experience Builder. It allows XB to provide SDCs that are more close to web standards / HTML tags or design system atoms.
lauriii → created an issue.
@bostonjillian is out this week but in the meanwhile I'd like to clarify that when sections are added, it gets stored as a copy. This means that deleting a section from the library would not result in those sections being removed from where it has been used (e.g., individual pages). This is their difference from components. That popup would make sense for components.
+1 once Standard uses Navigation.
I'm thinking we could hide the status too when the user is invited to set their password. It doesn't make sense to notify the user that an account was created if the account is blocked.
This is what I had in mind for the UX:
The eventual ideal for me in this scenario would be that setting a password isn’t required on account creation, if you are using this workflow.
This was the intention. Many platforms only ask for email (and sometimes for name) when inviting new users to the platform and expect the user themselves to fill in all required information like password when they use their one time login link. If you are using this email based registration flow, it seems completely unnecessary for the person creating the user to have to enter a password, because it would be changed by the owner of the user on their first login.
I don't necessarily think dev/prod is that relevant, if I'm making someone an account on dev I would want them to get an email too. But that's only on manual creation, not sure if we should distinguish? Meaning, if I'm manually creating an account for someone on dev, why would I NOT want them to be notified? If it's a test account I'd use my own email. If I'm making an account with someone else's email address, how would they access it without getting an email?
This is mainly because the emails may not be all that useful given that the user may not be able to access the site when it's in dev environment (e.g., localhost). I don't think this is that important use case at all to consider, just something that came to my mind.
Release management hat on: Changing the default value on the form would be too disruptive. I would say that's a major-only behavior change.
Would it be possible to document what the expected disruption would be to see if we could find ways to address those?
I think this is potentially something where the Starshot and core framework 80% case differ.
I don't really understand how this would be different between the two? Email based sign-offs are used commonly in both, consumer and enterprise products. For sites using SSO, this would be different, but in this case humans wouldn't be even accessing this form.
If anything (if we want fewer settings in the UI), I would almost make it only a site-wide checkbox, rather than a checkbox on every user creation form. That would more align with core-as-framework IMO. But that also seems like followup material to me.
If we make this a site wide setting, it almost seems something that should be managed by ECA → . However, that's something for future because that would require having ECA in core.
I'm more open to that instead of a site-wide setting to control what the default value should be. That said, if we remove the checkbox, we need to make changes to this page to make it clear that an email will be sent or not depending on what the setting is.
To me, changing the default value seems like the least disruptive way forward. I'd recommend we do that and open a follow-up to move this to a global setting. Based on that, the next steps would be:
- Change the default value to checked (this issue)
- Add an automatic password generation (follow-up)
- Move this to a global setting for configuring the registration flow (follow-up)
@lauriii raised the question of whether this could be tied to the dev/prod toggle. I don't think it should be, because the usecase @pameeela has raised is to notify real new users via email when an account is created, but mine (from my own site-building days) is always to not notify users created by admin.
We could also use the dev/prod toggle to not send any emails from dev ever, but that's its own separate followup issue.
The email based workflow for adding new users is increasingly common nowadays. I do think we should default to that, given that how common it is. I don't even remember when was the last time I was passed a password to a product manually. I understand that some organizations may have a different workflow, but we should set the default based on what we think is the 80% use case. I don't really understand how this default would be different for Drupal CMS vs Drupal Core.
The dev/prod toggle idea I had, was to not check this automatically when working in a dev environment. That way you could still choose to sent an email in dev environment if you want to test this (or some other reason).
This could be a separate issue, but as a UX enhancement, I think we should be also be generating the password automatically.
This might not be how Experience Builder works today, but eventually Experience Builder should be able to open any Drupal URL regardless of how it's defined. Experience Builder would allow users to navigate outside of XB for concepts that are not editable by XB (similar to contextual links).
This is described in the requirement 11. Component hover:
As a builder or creator, I expect to be able to inspect any visual element on the page by hovering/clicking on it. This will either let me edit it (if editable), and/or tell me what rendered it and tell me how to edit it. For example, an instance of component would be editable within the current page, but would also provide builders with guidance to how to edit the structure of the component.
I opened 🐛 Slot with a placeholder is flickering when adding a new component Active but it doesn't explicitly call out the state where the whole canvas is empty. This may also be impacted by 🌱 [Proposal] A different approach to the iFrame preview interactions Active .
What do you think if we merge this with 🐛 Slot with a placeholder is flickering when adding a new component Active ? I believe we could also postpone that until 🌱 [Proposal] A different approach to the iFrame preview interactions Active is done.
How does this scale once we want to enable opening something other than a Node in the Experience Builder? Like let's imagine, XB supports editing a View, and you now want to navigate to XB to edit a specific View. What would the URL be in that case?
wim leers → credited lauriii → .
kristen pol → credited lauriii → .
#15: That looks good 👍 Those are limitations I'm aware of for the current state of XB.
If product requirement 13. Undo and Redo must also apply to bundle/base fields on the host entity (i.e. Field Widgets in the "regular entity form"), that would also impact the UI data model. Product lead @lauriii should clarify that 😄🙏
The undo/redo should apply consistently to any content and design changes in XB. This means that for consistency, the undo and redo should also apply to changes in the values of base fields and bundle fields. 👍
The localStorage idea seems like a smart way to implement this so long as it works between tabs. 😊
This is not in the scope of this issue but it would be great to be eventually able to copy and paste to XB from other apps. This could mean for example inserting text into a text element. I was wondering how would we differentiate between the state and the clipboard. Maybe we could achieve this by clearing the clipboard whenever we store XB clipboard in state. This way we could first check if the clipboard has content, and use it instead when that's the case.
Should we handle CTRL+X here or move that too a follow-up?
This is what I had in mind! It doesn't have to block this but I wonder if we could link the CONTRIBUTING.md from the README.md?
Looked at this with @bostonjillian and @Renee Lund and got through the auto-save section.
🔵 When a given amount of time transpires (How much? Or should it be event-based?)
We want users to not have to think about this action, which means that it needs to be close to immediate (~few seconds). I guess based on that, it should probably be based on when changes are being made?
🟢 Scenario 5.1: Deleting created entities when abandoning progress
There should be a way to delete the draft by using a delete action but once the user has entered the content form and inserted any content there, we should retain the saved draft.
🔵 Scenario 6.1: Deleting created entities when abandoning progress
From UX perspective, there might be different expectation between the two examples given in the user story. Media library is often something that is considered to be separate from the content (i.e. page) that is being created. This is highlighted by the fact that it opens up in a modal dialog and has explicit steps for uploading and saving. This is different from the use case of Taxonomy Term because in that case you're just adding a tag inline using an autocomplete.
🟡 Auto-save only applies to saved entities. It doesn't make sense in any other context, e.g., an un-submitted node/add/* form, since (it is also assumed) Experience Builder can't even be opened except on an existing entity.
I don't think this is the right assumption. Content types that are using Experience Builder should open in XB even when creating content.
🟡 If a user wants to revert back to a specific point in history, that will be handled with revisions.
It should be possible to revert back to previous revisions and auto-save states. It would be okay if auto-save states get truncated into a single revision once content gets published.
🟡 Workspaces can be a dependency of Experience Builder. (Can it be a hard dependency for all behavior, or only a soft dependency for "enhanced" functionality? See Open questions.)
I think we need to work with the assumption that we depend on Workspaces for now. It doesn't seem that the UX of going with content moderation would meet the needs. I don't think we need to implement support for using XB without Workspaces now, but it would be great if we could build this in a way that we could reconsider this decision closer to the release. This way we could add a way to use XB without Workspaces later if needed.
🟡 What happens if the same user has the same node open in Experience Builder at the same time on two different computers? For example, what if a user goes back and forth between home and the office? Does one computer get locked out of editing and become "read only"? How do we avoid the two computers repeatedly overwriting each other's auto-saves?
We could do something similar to: https://www.youtube.com/watch?v=CsRBypaT_hM&t=27s. We could apply this both for the scenarios where the user is the same and where it's different.
🟡 What happens to one user's auto-save states if a node or revision is changed by another user?
Is this relevant if we do above ^?
But it sounds like it's not necessary to support a use case where the site builder sets up a component, and the content creator can unilaterally remap where things come from arbitrarily.
A content creator wouldn't necessarily map properties to fields but a site builder could do this even in the context of a single page. This is also one way in which the site builder could build these pre-defined mappings in the first place.
The goal is for the framework to behave similarly regardless if you're editing a component or a page. This way you get a consistent experience across the system, and can for example start building a component while you are building a page. This is a workflow that tools like Figma have popularized.
I wonder if this is solely because we don't have #3455629: [later phase] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model built yet (where it'd indeed be a Site Builder decision), or whether @lauriii truly intends for Content Creators to (be able to) decide this.
The main goal isn't necessarily to make content creators do the mapping themself because the task of mapping fields to properties would be quite challenging for most content creators to manage (as @catch is arguing in #17). That said, the aim has been to include this capability consistently across the system for site builders to utilize. This would also enable us to build capabilities where site builders could pre-configure mappings to components, which would make it easier for content creators to utilize this capability.
Something to note is that the field mappings are not conceptually supposed to be restricted to Drupal fields. The plan is to eventually allow site builders to connect components to data from external APIs and other pre-configured integrations (e.g., Shopify, Zapier, Airtable, etc).
The conditional display of components is a capability where we allow the components to react to context. For example, the context could be "search_index = true" or "user_roles = [anonymous]" which could be used to determine whether a component should be displayed or not. This is not tied specifically to display modes, this could be done within a display mode. We could also allow the component author to specify this for the component itself. This way a component author could say that for example the labels within the component should not be displayed if the context is search index.
Custom teaser text. that doesn't appear in the main content.
A custom teaser text seems like it would be a field, just like we are using the summary field today. It seems that this is the approach that's used by https://www.moneysavingexpert.com/tips/ for example.
Search indexing - both core search module and search_api. Search API has over 120,000 installs.
We are planning to enable conditional display components. We could add "search index" as a condition. We could also add additional tools, to allow specific components, or parts of components to be excluded from the search index so that they wouldn't have to be specified in the context of placing a component, but could be defined by the component author.
What's worth noting is that customizing the search index too much from the actual full page display isn't necessarily a best practice. The search index starts losing meaning if the content is wildly different from what's actually on the page.
Newsletters via simplenews - simplenews has over 20,000 modern Drupal installs.
This is already not working with Layout Builder today pretty much at all because AFAIK you can't even access the Layout Builder overrides in the simplenews view mode. See: 🌱 simplenews render flow from layout builder Active . It seems that this would be solved by allowing rendering the XB slots as a whole in a different display mode. This could be enhanced with the conditional display of components to disallow displaying specific components in a newsletter.
It seems that what would be best for the https://substack.com/@mehdirhasan/p-147950395 example, is that it would be possible to configure as the subscribe component author that it should not be displayed if the context is a newsletter.
Alex Pott's German content audit module
I tried to understand what the module does. It does seem like it's taking the content, and enhancing the content some additional information to be sent to an API. It seems that this also would be solved by allowing rendering the XB slots as a whole in a different display mode, or potentially by simply allowing a conditional display of components for this specific context. I would need more information to describe with confidence how this would work with Experience Builder.
Optional fields that later need to be incorporated into other view modes.
This is a nice to have capability, but I don't see why we would design the whole system to accommodate this. I'm also questioning if this is actually really solved by the field union approach. It's definitely closer to solving this, but not to an extent where it seems useful.
We should keep the search index, teaser, and newsletter use cases in mind as we continue working on Experience Builder. I believe the use cases mentioned here are covered by some combination of data modeling, conditional display of components, and potentially being able to create additional display modes that use slot contents from the full content display mode.
I can't see how any of these use cases would be better solved by being able to place components in an arbitrary order in a different display mode. Because there would be too much risk that the display isn't what's actually expected, the search index example seems like the only use case where that's even a viable option (given the search index itself is not being accessed humans).
I was thinking that we could provide the setting on different entity types but we should definitely do some curating where content types could default to allowed and others default to not allowed. This would enable use cases such as linking to media, which is a valid use case.
This gave me an idea - what if define this at the bundle level in hook_entity_bundle_info(), defaulting to off.
Then we can try to set sensible defaults in core (i.e. on for all node bundles and media bundles, off for comments and menu links). Sites can use hook_entity_bundle_info_alter() to customise it, and either core or a contrib module could do that via config with a UI later.
I like this suggestion. I'm wondering if we should also provide an API that makes it possible for contrib to provide multiple link suggesters for the use cases where you specifically want to restrict the list for a specific use case.
But also as long as we're happy to restrict the default available suggestions after the initial lands (i.e. a behaviour change for content editors), even that API level support could happen in a follow-up if it helps this get in.
IMO this would be fine for this functionality.
I know that I've reviewed this in the past but I'm having some second thoughts about the UX now that I'm looking at this with fresh eyes, I'm concerned that we may be over complicating the user experience for the site builder. I'm trying to think of the use cases for this. I was able to identify use cases that map under two categories:
- Allow linking to any content that is linkable
- Restrict suggestions to a subset of linkable content to enhance content authoring experience
It seems that we are optimizing for the 2nd use case, whilst making 1st harder. I'm not sure if that's the right trade-off because this is not an actual restriction for the content authors, because they can still link to any content, they just don't get suggestions to all content.
The UX pattern that we require configuration outside of the Field UI is not great. This is not unique to this patch, for example, Pathauto suffers from this too. I'd imagine the ideal UX for this to be that you could configure this in the context of the content type, e.g., checkbox with label "Allow linking to this content type".
I think we should prioritize the use case 1. first, and do that really well. Once we've nailed that, we could have contrib or core implement a solution for the 2nd use case.
wim leers → credited lauriii → .
dan2k3k4 → credited lauriii → .
This prevents non config entity components as well as multiple different instances of the same component
I'm not sure I could think of a good use case for this, at least one that couldn't be achieved by taking another approach. Maybe @larowlan who originally proposed this could elaborate what a good example use case for this would be?