pameeela → credited lauriii → .
Yep, this seems like an oversight.
What are those major implications? Is it purely code / architectural or is there implications to the end-user?
The goal is to keep the rendering similar between XB and Blocks so that same CSS works with both. I don’t think we want to maximize the compatibility at any cost, which is why it would be good to understand what adverse effects this has.
I'm wondering if we're approaching images and implementing designs the right way. It doesn't look like even with the latest changes the design produced matches closely enough the original image.
I also don't think it makes sense that the image is visible in the chat. It's confusing to see a new image appear there that I didn't upload myself.
I'm also wondering if we should upload multiple images because some issues could happen on a specific breakpoint?
I think a single permission for managing the segments is sufficient. 👍
I'm not sure if that screenshot is because that's not what I'm seeing. This is how it looks for me:
This looks correct except we should reduce the spacing above the text.
We need to test 📌 Machine name JS does not work in Page Data/Component Instance form Postponed after this because per @bnjmnm, this issue should address that too 👏
Great to see some progress on this! Some feedback:
- We should include implementing the designs for this as part of this issue; it looks currently too unpolished. I've attached video of the designs for this.
- We should never show the user "Calling X tool" or "Calling X agent". We need to always convert these to more user friendly messages.
The changes look good and it gives a sense that we thought of both the pros and cons of these decisions 👍
Approved
I guess DummyPropsEditForm will remain dummy 🙈
Parent issue is already tracked as a stable blocker.
Parent issue is already tracked as a stable blocker.
Parent issue is already tracked as a stable blocker.
Parent issue is already tracked as a stable blocker.
Parent issue is already tracked as a stable blocker.
Content Templates is still a priority for stable, but we're tracking it separately.
This has been covered by the issues referenced here.
It would be nice to fix this but this is not a stable blocker. I think slots would have to be considered black boxes until we have this.
There's been some serious improvements in this area, thanks to @jessebaker 👏 I don't think the remaining work needs to block a stable release.
This is an important usability improvement, but not a stable blocker.
This is a nice improvement but not a stable blocker.
This is tracked as part of the Content Templates, which is a priority for stable. However, the individual issues are not tracked as stable blockers.
This is tracked as part of the Content Templates, which is a priority for stable. However, the individual issues are not tracked as stable blockers.
I do think we should mimic the block rendering from \Drupal\block\BlockViewBuilder so that same CSS that works outside of XB works when using blocks in XB. Ideally we should do this before stable but I don't think this needs to block the stable release. Worst case we'd document this in known issues.
Workspaces is not a stable priority so I'm untagging this.
We will work on this as part of Content Templates which is still a priority for stable, but we're tracking it separately.
Based on discussions during Drupal Dev Days with @borisson_, we came to a conclusion that at least initially, this doesn't seem like the way to add support for searching at least. Unfortunately, I don't remember the exact reasoning since this was a while back. However, I don't know if we can come up with a single solution for all of these problems. It seems it would be easier if we had one issue per use case. We can continue exploring generic solutions here based on findings from 📌 Spike: Explore adding configuration options to the tree item formatter to support alternate use-cases Active . Regardless, this is not a current priority so I'm untagging this from the stable release.
Since this only impacts the preview before adding components to a page, it doesn't seem this would have to block a stable release. We may still want to look into this since there might be other ways in which the preview is inaccurate.
@gábor hojtsy I believe you were able to workaround this problem by changing to use a select? Would that be acceptable for Drupal CMS 2.0?
It's also unclear to me how does machine name JS relate to the autocomplete which is shown in the video 🤔 Keeping the stable target tag for now so this doesn't get lost.
If we don't get to this before stable, we will document this in known issues and recommend way to workaround this.
Moving this to stable target because it is possible to start getting adoption especially with smaller sites prior to having this.
I think variants is a broader concept than just SDCs. For example, display modes for a block are conceptually very similar and could be considered a variant of the block. I do think bringing it to top level would make sense because as a top level concept, we would probably want to allow tracking usage of variants in future.
I'm moving this to a stable target since if we don't get to this, we could document that XB doesn't have support for variants (yet).
We actually have a way to workaround this, which is to mark all existing components as 'use client' when we introduce this. Because of that, changing this to stable target instead.
Discussed this with @Wim Leers, @effulgentsia, @balintbrews, and @jessebaker and agreed that this is high priority, but should not block the stable release. We will try to prioritize this if possible.
This is needed by Content Templates which is still a priority for stable, but we're tracking it separately.
We have a MVP solution in place which gets us to stable.
Content Templates is still a priority for stable, but we're tracking it separately.
I believe 📌 Link Publish errors to the page + component instance that's causing the error Active is sufficient for stable. This is a nice UX improvement we can implement later.
Content Templates is still a priority for stable, but we're tracking it separately.
balintbrews → credited lauriii → .
Moving to critical due to this causing data integrity issues.