Finland
Account created on 20 December 2010, over 14 years ago
  • Principal Software Engineer in the Drupal Acceleration Team at Acquia 
#

Merge Requests

More

Recent comments

🇫🇮Finland lauriii Finland

FWIW, this is called "Default value" in the Field UI module today and it behaves the same way as XB.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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:

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

I can't reproduce this anymore. Not sure what was causing this 🤷‍♂️

🇫🇮Finland lauriii Finland

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. 👍

🇫🇮Finland lauriii Finland

#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.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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?

🇫🇮Finland lauriii Finland

@penyaskito You need to enable xb_dev_js_blocks module for overrides to show up in the UI.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

I agree, this is not needed anymore. 👍 Using the current heuristic of element being provided by XB is much better.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

I was recording some demos of XB yesterday and was running into this fairly consistently when placing sections.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

Where should we fix the bug that the button is rendered with black text? It seems to be caused by Gin.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

The auto-saved changes are not loaded in the whole-page preview. Added steps to reproduce.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

lauriii created an issue.

🇫🇮Finland lauriii Finland

Yep, confirmed this was because of the @import. Not sure if this should be triggering an error. Retitling and reducing priority.

🇫🇮Finland lauriii Finland

Maybe the reason this wasn't working was because I was calling @import "tailwindcss";.

🇫🇮Finland lauriii Finland

Bumping to critical because this happens even when the image isn't required.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

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.

🇫🇮Finland lauriii Finland

Sorry about the back and forth, but we should not be showing the radio button. There's usually nothing that the user can do to make the radio button active (other than to logout as another user). Therefore, we should apply progressive disclosure and not show the field at all. Also, it's really hard to see there being an expectation to block yourself outside of just deleting or canceling your account, so it definitely seems just extra noise there.

🇫🇮Finland lauriii Finland

#27 😱😱😱🎉🎉🎉👏👏👏

Production build 0.71.5 2024