🇫🇷France @mogtofu33

mogtofu33 → created an issue.

mogtofu33 → created an issue.

mogtofu33 → created an issue.

Message fixed.

I have a problem from a clean install, all caches ON, no dev only verbose error logging:

• Layout builder is NOT enabled
• Go to ui modules list and enable display_builder_entity_view
• Accept other modules including layout builder
• Submit, error appear:

Drupal\Core\Entity\Exception\NoCorrespondingEntityClassException: The Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay class does not correspond to an entity type. in Drupal\Core\Entity\EntityTypeRepository->getEntityTypeFromClass() (line 111 of core/lib/Drupal/Core/Entity/EntityTypeRepository.php).

This makes the display_builder config to not be installed properly (missing config default) and add some failing on the display of entity.

Do we have a way to ensure layout_builder is enabled before? perhaps with a dependencies?

Looking good, thanks!
Added a message when both are enabled, because of layout destruction on deletion it make sense to allow both to avoid loosing the layout.
Had an error on enabled but seems from my env, will double check and merge if ok.

mogtofu33 → created an issue.

Thanks for the hard work, let's go with that!

The demo bootstrap fixture is unstable because of missing dependencies, the icons are loaded from some specific icons packs. That's why you have the block 'icon' without the icon loaded.
To work properly it needs from https://gitlab.com/ui-icons/ui-icons-example: ui_icons_drupal, ui_icons_fontawesome (with lib, see readme), ui_icons_heroicons (with lib).

Fixed on MR28 (alpha bug fixes).
Unless there is an MR, this kind of small bug fixes can be added to 🐛 Alpha bug fixes Active for now.

Still have the issue, as soon as UI Styles island is enabled, I have multiple warning.

Perhaps UI patterns side, this to be done after 📌 [1.0.0-beta1] Remove Island's specific Form classes Active and ✨ [1.0.0-alpha1] Make Island plugins configurable Active , as configurable islands will impact a lot.

DB config, one global permission 'administer display builders' to create / edit Delete
For each DB config, one usage permission (as filter module):
Use the %name Display builder config

An other alternative is to do this on js as we have on the click element the html attributes of title and even index.
As the drawer title is a property set on the load of the component in the display_builder component it would avoir more php.

Playwright initiated, we'll see for more tests and to put them in the ci on a follow up.

Thanks for the fix.

Merged, thanks for the MR.

mogtofu33 → created an issue.

mogtofu33 → created an issue.

g4mbini → credited mogtofu33 → .

All fixtures current files have been moved to display_builder_devel.

mogtofu33 → created an issue.

mogtofu33 → created an issue.

My bad it's working better. The switch between the 2 branches made a false positive.
But I have an other problem that I thought was related but not, when loading a fixture like bootstrap demo it has warning when rendering for each element:

Warning: Uninitialized string offset 0 in Drupal\Core\Render\Element::property() (line 29 of /var/www/html/web/core/lib/Drupal/Core/Render/Element.php)

But this code do not touch the rendering, so I guess there is a change somewhere in the data of the builder saved, will investigate.

Moving for now to alpha2 to have time to finalize.

I could finally reproduce in a case: when the slot in the builder has been replace, for example add token, add a styles, close the drawer, then click fail.

Still have the issue.
In current BlockStylesForm::buildForm, the $data['styles'] contains the selected value as:

[
  "styles" => [
    "selected" => [
      "typography" => "display-1"
    ]
  ]
]

On this branch, the code is now in UiStylesPanel::buildForm as $this->data['styles']. Problem is it's nested in:

  "_third_party_settings" => [
    "ui_styles" => [
      "styles" => [
        "selected" =>  [
          "typography" => "display-1"
        ]
      ]
    ]
  ]
]

So it does not apply.

I like the second option, keep in front.
First option involve reading the variable value in drawer.js (--drupal-displace-offset-left) and add it to the margin left and with set by js. Which seems too much.

I know there is some issues with the drawer but cannot reproduce this one on last 1.0.x.
Could you check console and network activity? An xhr call is made to fill the content as you see in my video db_3531718_open_drawer.mp4.

Currently it seems the form lost it's state, at least for UI Styles and UI Tokens.

From an empty display builder with ui suite bootstrap:

• Add a button
• Add a token inside, fill a text
• Apply a style and a token to the button and the token (font h2, border color and background color for example)
• They are applied properly, but not kept in the instance form
• Refresh the page
• They are applied properly, but not kept in the instance form

Expected is to have the style and token selected in the instance form with a message (current behavior on 1.0.x).

Simply removing makes no sense! we need a solution to keep it and be able to use it. Created 📌 Fixtures Active

mogtofu33 → created an issue.

Reset is a devel (display_builder_devel) feature, so not a priority for now, moved to beta phase.
For now to fix, simply delete and re-create the instance.

Style fixed.

mogtofu33 → made their first commit to this issue’s fork.

Thanks for the work.
I think it should be on GraphQL Compose as we implement core integration only in our sub modules, exception of UI Patterns but it will move too. And looking at GraphQL Compose they already implement directly these plugins for contrib.
@pdureau wdyt?

doesn't render properly in a custom theme.

Could you be more specific? Then the issue could be a conflict on the css with the custom theme?

It's working well when navigation is collapsed but when opened there is a displacement problem, probably to see for the size handling in assets/js/drawer.js

What @yannickoo is pointing is that the menu can not be inspected (right click).
The type="checkbox" is used to make the click event work and propagate as seen in the shoelace menu.
I don't think we can remove this type, and I am not sure of the level of the issue here. Is there an accessibility problem?

Thanks for the work, but the style is not good, would be great to make it pass.

mogtofu33 → created an issue.