You would run into the problem if you provided slogan as an optional property of the page which passes it to the card from the page. This would not trigger validation errors when slogan is provided but would trigger the validation error when page is not receiving slogan.
I originally planned to build a new widget for making it possible to customize which meta tags were shown on the edit form, but realized it was pointless when you could just add regular fields and then use tokens to output the tags as necessary.
The point is not necessarily to configure which fields are available but to allow user to choose which metatags they want to provide. This is relevant specifically for pages because they contain unstructured data and the different metatags needed might vary page by page.
Other benefit is that metatag is also specific to the actual HTML that get printed vs fields which would be an abstraction away from the HTML tags. This would make it challenging to implement preview for metatags like we have here:
Also, what would happen if user provided a prompt "Make the header sticky so it stays at the top on scroll"? This seems like a common use case which we should think through. Usually you'd probably have some kind of header component which the AI probably should modify in this scenario. Alternatively if the header is an SDC, it could create a new component that wraps the existing component to add the sticky header behavior.
Have we considered refinements to the header and footer here at all? For example, "I'd like to add a 'Start free trial" button in the header that links to #" or "I'd like to add a 'Contact' link that links to '/contact' to the header".
This isn't really all that relevant when using SDC in render array but when using SDCs within Twig. Twig doesn't have the concept of undefined unless you use Twig strict_variables turned on (which Drupal is not doing). So when you are passing in undefined properties, they become null. I don't think there's a practical way to keep the variables as undefined and really as a frontend developer, you shouldn't have to care.
Merged the follow-up! I also opened 📌 Add docs for image code component Active .
Merged! Thank you @heyyo for pushing this forward! 👏 We can still iterate on this so feel free to open follow-up issues with improvements!
Could we please split this to two separate issues? I'm not sure that adapted prop sources is what's needed here. You should be able to map date field to a format: date string. If that's not the case, that's a bug on it's own.
There's a small bug with this. After you delete a page, you are taken to a 404 page:
Yep, admin theme should be a composer dependency and not part of the site template. I think a theme directory for the site template theme makes sense conceptually. It could be either a self-contained theme or a theme depending on another theme via composer dependency depending on the site template and its needs.
I could argue this either way but based on seeing this issue it doesn't seem like people could have a good experience testing Canvas without having this fixed which is why I think it would be better if we could fix this before beta. Would be helpful to understand if this is something that's difficult for us to fix so that we can weigh the delay against the impact of this issue.
Agreed that we should disable this before beta to avoid the BC break 👍
What's the question to me here?
I don't see how this is a data integrity concern? This seems like a UX concern and us trying to babysit the users. I feel very strongly that we should not introduce validation of this type. It should be up to the user to decide what kind of template they want to create. Maybe all of the data is fetched using JSON:API or maybe you just want to preview how a static template would look like? This isn't really changing from what you can do today either because you can create an empty display mode today and that's fine.
That's correct. 👍
I don't really see why this is something we would have to enforce. It's totally fine if users want to test static templates as content templates before they map props to a dynamic prop source.
wim leers → credited lauriii → .
+1 for #44.
@d34dman Isn't the solution to what you're describing using categories / tags instead of specific components? I'm hesitant to add an alter hook for this because the DX of SDCs is intended to be as simple as possible and as the name suggest, everything related to a component should be found in a single directory.
I'd recommend following as the comment because we will be making a broader public announcement later:
Experience Builder has been renamed to Drupal Canvas in preparation for its beta release. You can now track issues on the new project page here → .
+1 for landing the fix as it is but it would be great to plan for doing #24 🐛 After source session timeout, XB page stuck on the error message Active too.
We need to adjust the errors that are displayed to user in this situation. This isn't really an unexpected error.. This is just the users session timing out?
We should not be generating props with camel case. The prop in code is automatically converted to camel case from the prop name. We should either try to fix that here or in a follow-up.
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.