#stable blocker

Automatically closed - issue fixed for 2 weeks with no activity.

#8.3: Yes, we should. I discussed that with @lauriii.

1. Question 1: I believe the intention is to allow dynamic components to be placed in categories in the same way that we could group any other component type. This is to allow a user to control where every component goes, including dynamic components. The only thing that wouldn't be able to be grouped with components is the code used for code components.
2. Question 2: There may be another method to add a new folder in the future. However, for now it's only manage by a dialog. I didn't have any formatting as a requirement, so I don't think it's needed here.
3. Question 3: Not sure if we're allowing top level components (not in a folder.). I'll await confirmation before adding designs.
4. Question 4: The folders have a context menu available on hover. From here you can delete or rename folders.
5. Question 5: Adding code for SVG here as d.org doesn't allow uploading svgs...
6. Question 6: I hadn't planned to make it alphabetical. My intention was when a new folder is added, it is added to the end of the list of folders. These can be freely moved up/down (changing the weight) so they can be placed anywhere within the sidebar hierarchy.

<svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
<mask id="mask0_14031_57331" style="mask-type:alpha" maskUnits="userSpaceOnUse" x="0" y="0" width="16" height="16">
<rect x="0.5" y="0.5" width="15" height="15" fill="#D9D9D9"/>
</mask>
<g mask="url(#mask0_14031_57331)">
<path d="M3.19234 12.6875C2.87661 12.6875 2.60937 12.5781 2.39062 12.3594C2.17188 12.1406 2.0625 11.8734 2.0625 11.5577V4.44234C2.0625 4.12661 2.17188 3.85938 2.39062 3.64063C2.60937 3.42188 2.87661 3.3125 3.19234 3.3125H6.15625C6.30687 3.3125 6.45172 3.34177 6.59078 3.40031C6.72974 3.45875 6.85052 3.53927 6.95313 3.64188L7.87375 4.5625H12.8077C13.1234 4.5625 13.3906 4.67188 13.6094 4.89063C13.8281 5.10938 13.9375 5.37661 13.9375 5.69234V11.5577C13.9375 11.8734 13.8281 12.1406 13.6094 12.3594C13.3906 12.5781 13.1234 12.6875 12.8077 12.6875H3.19234ZM3.19234 11.75H12.8077C12.8638 11.75 12.9099 11.732 12.9459 11.6959C12.982 11.6599 13 11.6138 13 11.5577V5.69234C13 5.6362 12.982 5.5901 12.9459 5.55406C12.9099 5.51802 12.8638 5.5 12.8077 5.5H7.49031L6.29453 4.30406C6.27443 4.28406 6.25339 4.27005 6.23141 4.26203C6.20932 4.25401 6.18625 4.25 6.16219 4.25H3.19234C3.1362 4.25 3.0901 4.26802 3.05406 4.30406C3.01802 4.3401 3 4.3862 3 4.44234V11.5577C3 11.6138 3.01802 11.6599 3.05406 11.6959C3.0901 11.732 3.1362 11.75 3.19234 11.75Z" fill="#00051D" fill-opacity="0.454902"/>
</g>
</svg>

Answers to questions in #5:

1. I missed when we added that. 🙂 Those need to be replaced by folders, which will be initially auto-created from those block categories in 📌 Expand Folder entity functionality Active . In other words, folders are superseding the hard-coded block categories.
2. Correct, single text field in a dialog, @/components/Dialog should be sufficient. The only requirement is that folder names need to be unique within a parent (i.e. components, patterns, code).
3. Confirmed. I'll ping @callumharrod for the visual example.
4. I would vote for grouping them together, starting with folders. @callumharrod, can you please confirm? It should be the same in Library and Manage library.
5. See ✨ Renaming, moving, and deleting folders through contextual menu Active .
6. @callumharrod, please.
7. We'll expand on that in ✨ Renaming, moving, and deleting folders through contextual menu Active , alphabetical order and 0 weights are what's in scope of this issue.

I just had a conversation with @lauriii. Internal code components should live under Manage library. I adjusted the issue summary accordingly.

Question 1

Step 1 in the Libraries instructions includes
Merge the listing of Components and Dynamic components under the label Components.

Dynamic components are already organized into collapsible subsections sections based on their block_category:, which would mean two different forms of collection next to each other:

1. Folders (ui configurable)
2. Block categories (hard coded)

Perhaps this is fine and is why there's no additional explanation, but I'd like to confirm that.

Question 2

Is adding a new folder done via a dialog with a single text field for the dialog name, or was a different type of interaction envisioned? Are there any format requirements of the name provided?

Question 3

In the screenshot for Manage Library the root level shows only folders. Item 4 mentions "Keep support for displaying items at the root level." which I believe means un-foldered items can be displayed alongside the folders.

• Could I get confirmation of this and (if capacity allows) a visual example?
• Assuming this is the case, should folders and components be listed interchangeably as alphabetical order dictates, or should they be grouped together and alphabetically sorted within those groups? Is this different depending on if we're in Library or Manage Library?

Question 4

In the screenshot for Manage Library I don't see any controls where one might be able to rename or delete existing folders. Even if this is something to be added later, knowing where the controls might be will inform how this gets implemented.

Question 5

I could not find a folder icon in Radix. Could the svg used in the designs be provided in this issue?

Question 6

Do folder weights have any impact at this time? Based on the current requirements it looks like they're all being set to 0 and sorting is alphabetical - which is fine of course but I wanted to be sure I wasn't overlooking somewhere they get used.

Another thing just occurred to me. Yes, I'm sorry. I don't anticipate more changes, fwiw. 🙂

We need to support organizing pattern entities, too, not just components. So I recommend that we rename the components property to items.

We previously had code in the MR that ensured that folder names are unique within a UI library. Then I asked for removing it because the concept of UI libraries is going away. What I didn't consider was that we still need unique folder names for components in the library vs. internal code components (which will eventually move to a separate menu item). I'm really sorry, but we'll need to bring back some of that code. I think we shouldn't call the property uiLibrary as that concept will still go away. Maybe parent? Any other ideas?

Automatically closed - issue fixed for 2 weeks with no activity.

wim leers → closed merge request !754

I'd have liked to see a more comprehensive end-to-end test, but I see now that the issue summary was quite specific about this: so 👍

It is very nice to see such a nice little expansion of an existing test though, so merging this; more expansive test coverage will be necessary in 📌 [later phase] When the field type for a PropShape changes, the Content Creator must be able to upgrade Postponed anyway :)

FE folk need this in order to start FE part of Folder work, so I've extracted unfinished tasks into #3541364 📌 Expand Folder entity functionality Active and moving this into review.

Automatically closed - issue fixed for 2 weeks with no activity.

For Issue 3 mentioned in #36, created separate issue - https://www.drupal.org/project/experience_builder/issues/3541331 🐛 Link Type "Full URL" is Not Retained After Navigation While Adding Prop Active

That was fast!

Expanded the existing test to assert that the input in the old component version passes validation.
Because our validation is tied to the json schema and that _doesn't_ change I think we're in good shape here

I went looking for any existing tests that enable xb_test_storage_prop_shape_alter which would be the obvious way to test this and found component-transforms.cy.js which looks to do exactly what we were looking for here.

That was added in 🐛 Component transforms need to be per sourceType, not per component prop Active which was early May, but this issue was opened in June - so that leads me to believe it might not be enough on its own.

I will recreate the steps in that test and see if it is already providing the coverage we need and expand it as needed.

Yes, particularly when a blur triggers both the AJAX request AND the model patch - as described in the STR

You're correct, this isn't about concurrent editing, its about one user having a race condition with them self 🙃

larowlan → closed merge request !1362

Especially important now that we've discovered (and fixed) 🐛 Data loss: `ComponentTreeItem::setValue()` and `::onChange()` may inappropriately upgrade `component_version` to the latest version Active (and kinda also 📌 Disallow component trees with `component_version: active` Active ). This would be the finishing touch to boost our confidence 🤓

Found below issues :

Issue 1: Outbound processor not triggered for lk prop (alias not used)

Issue 2: Article gets autocomplete and proper alias, page does not

Issue 3: "Full URL" link type not retained in UI

This is causing significant confusion and delays in 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active , see https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

Ah, I think I understand now — the concern here is about race conditions caused by in-progress AJAX requests/responses/commands.

You're actively working on the related 📌 Replace the postPreview action with atomic equivalents Active , but AFAICT that wouldn't solve this problem. Do I understand that correctly?

Automatically closed - issue fixed for 2 weeks with no activity.

Ah sorry, I replied on 🐛 EntityFormController unable to save made changes when page is previewed Active - I think a different issue might have resolve that

balintbrews → credited wim leers → .

#6++ — which is why this is tagged for 🌱 [META] 7. Content type templates — aka "default layouts" — clarify the tree+props data model Active . 👍

(It's not a stable blocker in and of itself is what Lauri meant — but it is a blocker for #3455629.)

@lauriii We will need this for content templates to show the actual dynamic values. I have put a temporary fix in the spike MR https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

So if templates are a stable we will need this

Ah, #11 I think this is additional confusion regarding machine name JS vs autocomplete

• the logic in machine-name.js, which is why I filed this issue, is likely addressed in #3537872, which was mentioned in #10
• Entity Reference value conversion, which is the symptom mentioned in #6 (and in the case of webform is working with machine name values) should be solved in #3523496.

I think I contributed to this initial mixup, but fortunately all of these problems are nearly or already fixed.

See docs/adr/0006-One-field-row-per-component-instance.md which covers this too in the same way it's mentioned in #8.2

Great, that means @lauriii confirms #8.2 👍

Thanks!

That's better :)

Also, hah, I misread this, too 🙈

Clearly, I was a bit too excited/eager by how simple @larowlan's #2 made things sound 😄

Oops, I hadn't noticed that 📌 Don't allow passing uncollapsed inputs if using default expression Active added another skip 😅

Shoot, it's possible that it doesn't play nice with config schema's type: sequence 😬

So then let's switch to:

constraints:
  Range:
    min: -1
  NotEqualTo:
    - 0
    - 1

Ah, nope, that also doesn't work, because NotEqualTo only accepts a single value. Argh! We also don't support https://symfony.com/doc/8.0/reference/constraints/When.html

I'll investigate at a later time. Thanks for trying to get this done! 😊

Automatically closed - issue fixed for 2 weeks with no activity.

This unblocked 📌 Automatically transform the `drupal-11.2.2-with-xb-0.7.2-alpha1.filled` fixture when testing non-SQLite databases Active — MR rolled there, and landed! 🥳

That passed!

Updating title to reflect that the actual work already happened elsewhere.

Executed what @larowlan described in #2. Passes locally 👍

📌 Don't allow passing uncollapsed inputs if using default expression Active is in, this is now actionable :)

Thanks, and turns out my sole "real" question was moot, I misread! 🙈

The webform related problem was diagnosed by the XB team as related to the block form validate/submit handlers not being called, because when the autocomplete shows up, it returns the right value, but on save it does not save the converted internal machine name. That is dealt with in 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active (but is not yet working).

It's possible this works after 📌 Redux-aware form input components should be aware of direct element manipulation Active landed, which adds support for our inputs directly changing value via DOM or jQuery methods and triggering a redux/preview update.

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.

Addressed the minor remarks/questions

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 tracked as part of the Content Templates, which is a priority for stable. However, the individual issues are not tracked as stable blockers.

..

📌 Don't allow passing uncollapsed inputs if using default expression Active fixes this, but leaves behind the skip tests. Just need to uncomment them when that's in.
See step 6 in https://git.drupalcode.org/project/experience_builder/-/blob/585efb4733b... which was required to import the DB on mysql - I suspect that's all we were missing in the original issue.

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.

We will work on this as part of Content Templates which is still a priority for stable, but we're tracking it separately.

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

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.

#6++
#9++

This again touching the update path test DB fixtures increases the importance of 📌 Automatically transform the `drupal-11.2.2-with-xb-0.7.2-alpha1.filled` fixture when testing non-SQLite databases Active .

LGTM — just a few questions and minor remarks! 😊

I think component imports should be handled via \Drupal\experience_builder\Audit\ComponentAudit::getConfigEntityDependenciesUsingComponent in the audit logic.

balintbrews → credited callumharrod → .

balintbrews → credited f.mazeikis → .

balintbrews → credited jessebaker → .

balintbrews → credited lauriii → .

balintbrews → credited jessebaker → .

Crediting Jesse for spotting a gap in the issue description.

Because of the data integrity issues, I wonder if we could prioritize the simplest possible change before we settle on the final solution, including soft-deletion etc.

I think it would be the following:

When users try to delete or make a component internal (i.e. remove from components), we currently do that check to see if the component is being used in the current page's component tree. We can now do that properly thanks to 📌 Calculate field and component dependencies on save and store them in an easy to retrieve format Active . I don't see an HTTP API for the audit info, so unless I'm mistaken, that would need to happen before we update the check on the UI.

Do we already account for first-party code component imports (JavaScriptComponent dependencies) in the audit logic?

Moving to critical due to this causing data integrity issues.

@bnjmnm's comment in #8 is 🤩👏 — thanks so much for that!

→ the server-side changes 🐛 Hero component failed to render after removing text Active made to make this possible are specifically only for the component instance form. But the client-side changes in #3529788 were generic.

#10++ too.

Needs reroll because 📌 Narrow the conditions under which we allow a prop to be an empty string Active landed.

Green! Merging, per #7. Thanks, @larowlan and especially @bnjmnm!

Per the sequence of comments towards the end of 🐛 Hero component failed to render after removing text Active , this was de facto ready to go, but was split off into its own issue + MR — let's land it before it goes completely stale 😅

I suggest you close this as a duplicate of ✨ Add ComponentSourceInterface::getReferencedEntities Active and transfer everything over there. Core's default content exporter is pluggable, precisely so that modules like XB can handle exporting their own data properly.

Don't bother with the contrib Default Content module. It's not extensible anyway.

The importance of this became higher recently, when ✨ Add a command-line utility to export content in YAML format Active landed in core. Change record: https://www.drupal.org/node/3533854 → .

Related: 📌 Disallow component trees with `component_version: active` Active , which landed ~2 weeks ago.

do we want to take the opportunity here to make the validation messages nicer and match the Figma designs?

I'm going to vote no on doing this, although I think it was completely reasonable to suggest. The areas being changed in the MR are happening at an earlier stage than anything that would impact the appearance of those messages. Keeping it in its own issue avoids this being delayed by surprise test failures due to the changes, and gives us an issue where there's the opportunity for community members to discuss concerns about the designs (however unlikely those are to occur - the designs seem pretty good)

I'm not following which part of #6 doesn't make sense and what's the use case in which it wouldn't make sense. I would expect to be able to specify where the title and publishing information is rendered in the XB content template. The only questionable part is if we'd want to always wrap content rendered using a content template with some HTML element.

Also, is this the generic prediction of the bug reported at 🐛 EntityFormController unable to save made changes when page is previewed Active ?

How relevant is this today, after months of further iteration? Is the problem still identical, smaller, or bigger?

#6: that does not make sense to me because node.html.twig contains this:

<article{{ attributes }}>

  {{ title_prefix }}
  {% if label and not page %}
    <h2{{ title_attributes }}>
      <a href="{{ url }}" rel="bookmark">{{ label }}</a>
    </h2>
  {% endif %}
  {{ title_suffix }}

  {% if display_submitted %}
    <footer>
      {{ author_picture }}
      <div{{ author_attributes }}>
        {% trans %}Submitted by {{ author_name }} on {{ date }}{% endtrans %}
      </div>
    </footer>
  {% endif %}

  <div{{ content_attributes }}>
    {{ content }}
  </div>

</article>

IOW, it'll at minimum result in

<article>
  <h2>my article</h2>
  <div>{{ XB COMPONENT TREE HERE }}</div>
</article>

and in most cases in

<article>
  <h2>my article</h2>
  <footer><div>Submitted by Lauri on Aug 12, 2025</div></footer>
  <div>{{ XB COMPONENT TREE HERE }}</div>
</article>

IOW: when using XB to present a node, I think it'd be supremely confusing to then still be partially out of control, instead of in control.

Agreed with @effulgentsia that this closely connects to the Content Template work — this sounds like Content Templates need to have a "render in original template or not" flag? 🤔