larowlan → credited lauriii → .
We're not providing upgrade paths for XB currently, so it'd be fine to change this without an upgrade path.
It is number 3, the XB canvas' preview. This is different from 🐛 Changes to code components in global regions is not loaded until published Active because with overrides, the block doesn't have to be placed in a page region for this bug to occur.
That's a trivial move: instead of being listed at /admin/structure, add 2 new tabs at /admin/appearance. It'd also allow us to clean up the long obsolete Page Builder Components UI label.
Could we add a new tab called "Components" and then add the two tabs under it?
There is no parent context when using the XB UI and fetching the list of Component and Pattern config entities. The XB UI just fetches them regardless of which thing you're editing, no matter if it's a Page or Node content entity, or a ContentTypeTemplate config entity (once #3455629: [Needs design] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model is implemented).
Let's implement this based on the context-free proposal for now. We can add more complex permissions to the components later.
The permissions listed in #3452581: [META] XB Permissions do not include Administer Components, so I added that in #3452581: [META] XB Permissions
This seems too granular for now. Could we use administer themes permission for this? It might make sense to even move this under "Appearance" but that's off-topic for this issue 🤔
Use a tiny subclass of default \Drupal\Core\Entity\EntityAccessControlHandler for the Component and Pattern config entity types, aka all XB config entity types that provide the basic building blocks for the XB UI. These must respect the admin_permission, except that viewing must always be allowed.
For now, simply require the user to be authenticated (i.e. vary by the user.roles:authenticated) cache context).
Seems fine to allow viewing these to be tied to whatever parent context (e.g., access content).
wim leers → credited lauriii → .
Am I extrapolating correctly that you think permissions should be as simple as possible, and hence we should refactor away the administer xb_page permission in this issue?
Yes, we should keep the permissions as simple as we can at this point. We can keep adding more permissions as we add more functionality. We should avoid adding permissions which we don't have a clear use case for since they are pretty hard to remove later on.
I noticed that the administer xb_page permission isn't used for anything at the moment, and I also couldn't think of anything that we should move behind that permission at the moment. We will have to introduce this permission later, once we have page entity specific configurations in the UI.
Do we indeed want to add View Pages (view xb_page) instead of relying on access content? That permission used to be Node-specific, but has since been kind of generalized:
I agree that we should rely on the generic access content permission. I simply did not know that
#2892821: Core modules check node module's "access content" permission for displaying things that have nothing to do with nodes →
had happened because the permission is still listed under Node. 🤯
Looks good! It would be nice to make this customizable in future but this is a great improvement so I don't think we need to hold this back on that.
balintbrews → credited lauriii → .
griffynh → credited lauriii → .
wim leers → credited lauriii → .
FWIW, this is called "Default value" in the Field UI module today and it behaves the same way as XB.
My experience is that most page builders treat default values exactly the way Experience Builder does now: if there’s text in a field, that’s what will be saved. This matches how forms typically behave: when you see prefilled text, you expect it to be submitted unless you overwrite it.
That said, we need to decide whether to rely on default or examples in JSON Schema for this. Personally, I don’t have a strong preference either way.
Additionally, we may want to consider supporting both a placeholder value which is purely a form display concern and a true fallback value which is a rendering concern (i.e. fallback value determined at render time). I don’t think these should block the stable release.
kristen pol → credited lauriii → .
Nice to see this land! I tested this and it looks like the widget isn't showing when there's an image in the auto-saved state:
Proposed solution makes sense 👍
lauriii → created an issue.
disallow changing the machine name once a corresponding Component exists (which requires modifying the new constraint @larowlan added), and continue to use the machine name to refer to it.
I don't like the impact this limitation introduces to the UX. Similar to this, I already raised concerns around not being able to edit props / slots for components ( 🌱 Plan to allow editing props and slots for exposed code components Active ). I think we should try to find a solution without this limitation.
I don't think we need to allow <br> for inline content to build #10. If the design is supposed to have text on two lines regardless of the width, it should not be managed with a RTE.
Usually the use of <br> results in more problems that it solves so I'd say we should probably avoid getting to those. If we don't allow <br>, explaining inline text and regular rich text remains simple since one allows multiple lines and one doesn't.
I can't reproduce this anymore. Not sure what was causing this 🤷♂️
kristen pol → credited lauriii → .
1-3: Yes, it should work in these contexts. We want the canvas to have a cohesive behavior so these features should be available across the board.
4. I'm not sure I understand the question. I can't think if a way in which the labels could be translated asymmetrically.
5. 👍
#3499931-25: HTTP API for code component config entities → The trade-off as I understand it seems to be about the flexibility we provide within Experience Builder and ease of auditing the code components. It seems that we should prioritize the experience within Experience Builder. While code components must support deployment via config system, that's not the primary use case (especially in cases where you'd have full blown review step). It seems that most users who are going to audit the components, would use the CLI tool to integrate their components so that they can fully control the design system in Git. If this is proven wrong, we could still solve this with tooling in the CLI tool, e.g. a command that prints the component dependency tree in a human readable format.
So this does not happen when the auto-saved code component is in a content entity's XB field, and only if it is in a PageRegion?
Yes, exactly. This is what I tried to describe in the steps to reproduce.
I wonder if we could hide this behind "Administer search" permission so that this wouldn't be visible to people who can't actually make changes to search?
kristen pol → credited lauriii → .
kristen pol → credited lauriii → .
kristen pol → credited lauriii → .
kristen pol → credited lauriii → .
lauriii → created an issue.
@penyaskito You need to enable xb_dev_js_blocks module for overrides to show up in the UI.
lauriii → created an issue.
lauriii → created an issue.
I feel like we are talking past each other with different use cases and scenarios and concerns that are not being impacted by Experience Builder. My understanding is that there are two primary ways of configuring Search API: text based search and faceted search (as well as combination of the two).
When using text based search and the intent is to index the whole page, the "Rendered HTML output" with the default content type template (same as what user would see when navigating to the page) should be used. Search API would allow configuring other view modes to be used for indexing but those wouldn't include the content added to the slots, but only content that is being rendered through those view modes. So long as we keep view modes working, this should all work without specifically having to accommodate them. This is the same experience that you would get when using Layout Builder today.
When using the text based search, the results would often display an excerpt which is generated based on what is in the index. This allows highlighting the text that is being matched. This shouldn't require any special accommodations from XB so long as what is stored in the index is sensible.
When implementing a faceted search, it's common to configure the results to display to using a view mode like cards or search result. In this scenario, text is not being highlighted. Even in this scenario, the index may include the full rendered page, highlighting that the index is a separate concern from the presentation of the results.
pameeela → credited lauriii → .
Rendering Search results in the same way as the content's detail page doe not seem like the most commonly chosen way of configuring it. I did a quick poll at the contribution room at Drupal Mountain Camp, and everyone who answered me always configures some kind of teaser, card or search-result view mode when rendering a search result page.
We should definitely support configuring customizing how content is displayed in the search results page. I'm not sure we need to do that in this issue though because it might make sense to design and implement solution specifically for that, because it's such a common use case.
kristen pol → credited lauriii → .
Sorry for dropping the ball here. What I was thinking in #6 was providing a new property for SDCs to opt-out from XB, e.g., hideFromUi: true. This would allow indicating that a specific component never makes sense to be displayed in XB. Because this is opt-out, this doesn't go against the original principle in my mind.
Do we want to keep this restriction?
I don't see why it would be needed anymore since we have the new way of determining elements.
Do we want to remove this restriction, and allow SDCs to state they're in the Elements "SDC group"?
Not right now. We should start by only allowing XB to provide elements. This way we don't have to manage dependencies to other modules from components built using elements. We may choose to change this later if we discover valid use cases to do this.
I agree, this is not needed anymore. 👍 Using the current heuristic of element being provided by XB is much better.
I think we can close this one since the updated patch does address this. Would be great if we could land the Gin issue so that this would work out of the box with Gin.
I've not seen this in months at this point so I think it would be fine to close this as outdated. We probably need a follow-up to handle this more generically in the backend still.
wim leers → credited lauriii → .
Which parts of 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active is this blocked on? Would be great if we could link specific issues that are blocking this instead of the whole meta issue.
I was recording some demos of XB yesterday and was running into this fairly consistently when placing sections.
Ran into this with another component. Confusingly, I have 3 instances of the same component on the page, but only one of the instances loses the image.
It seems that this happens even when assertions are disabled. The error in this case is:
Symfony\Component\HttpKernel\Exception\BadRequestHttpException: in Symfony\Component\HttpKernel\Exception\HttpException::fromStatusCode() (line 34 of /var/www/html/vendor/symfony/http-kernel/Exception/HttpException.php).
This also happens when publishing page with this component making this even more severe than I had originally thought.
This can be reproduced with the case study component from SDDS.
Where should we fix the bug that the button is rendered with black text? It seems to be caused by Gin.
This has a soft dependency on 📌 Add a local task to edit pages in XB Active
Both of these properties are oddly specific and they make even less sense than they made in 2005 given how websites and uses of Drupal have evolved. I spent a few minutes on a quick PoC to test if we could dynamically delete these from new sites.
griffynh → credited lauriii → .
griffynh → credited lauriii → .
The auto-saved changes are not loaded in the whole-page preview. Added steps to reproduce.
I'm going to close this for now because AFAIK we don't have steps to reproduce this because Drupal CMS is running into 🐛 "Add media" button doesn't always open the media library Active . Once we get the media library to open, if we're unable to upload images, we could consider re-opening this one.
lauriii → created an issue.
lauriii → created an issue.
Yep, confirmed this was because of the @import. Not sure if this should be triggering an error. Retitling and reducing priority.
Maybe the reason this wasn't working was because I was calling @import "tailwindcss";.
Bumping to critical because this happens even when the image isn't required.
Realized this is a duplicate of 📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active .
It seems that this is consistently reproducible with https://github.com/phenaproxima/xb-demo.
volkswagenchick → credited lauriii → .
Interesting. Doesn't this mean there could be some pretty interesting behavior if different components included a different version of the global CSS? If that's the case, we should probably try to solve this in a way where we didn't have to include the global CSS with individual components.
The issue summary includes the steps to reproduce but it may not have been clear because it didn't have the steps to reproduce text before the steps.