🇮🇳India @libbna

Forgot to attached the screenshot of the final output.

I checked using the contrast checker, and --color-gray-500: #919297; meets the expected contrast ratio.

Apologies for the delay! I've added the implementation for versions_id. Leaving the issue in "Needs Work" status so that others can pick up and work on the test cases.

I've updated the border color from #dedfe4 to #949494. The border is now much more visually distinct.

I have reviewed the MR & the extension dialog is looking good to me. I have added before and after screenshots.

NOTE: from the dev tools I have increased the height check the scroll bar.

• Added the array $version_ids = [] parameter to the method signature as requested
• Implemented the filtering structure that loads each config entity when $version_ids is provided
• Maintained backward compatibility (empty array works as before)

What's left:

Need to implement the actual version checking logic inside the filter function (currently has placeholder return true;)
Unsure how component versions are stored in the config entities - need guidance on how to extract/compare versions!

Hi @jessebaker, could you please provide the steps to reproduce this issue?
Once they're available, I'll assign the issue to myself and begin working on it.

I have implemented the suggested changes. If there are any additional updates or modifications required, please let me know.

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

I again tried but couldn't reproduce the issue. In the last comment I forgot to attach the screenshot so I have attached it now!

Hi @bnjmnm,
I'd like to give this a try, but I could use some guidance. Could you please clarify where exactly the styling is expected? Based on my understanding (as shown in the attached screenshot), when we create a new component, do we need to apply styles to the fields (props and slots) that we add?

I have reviewed the MR and can see the field type has been changed. (Added before and after screenshot).

griffynh → credited libbna → .

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

Hi @mglaman,

Could you please share the steps to reproduce this issue?

Below are the steps I followed—please let me know if they are correct or if I’m missing something. The CSS appears to be getting applied, but I’m not sure if I’m approaching it the right way. I’d appreciate your guidance on this.

Thanks!

1. I created a new component in the XB page - Test Component
2. Added a Title prop of type text
3. In the code editor - global css - I declared a variable
   

   :root {
     --brand-color: #0074D9;
   }

4. In css section and used the variable as text color
   

   .test-box {
       color: var(--brand-color);
     }

5. last, I used the .test-box is js code.

Giving it a try on this.

griffynh → credited libbna → .

I have updated the functionality of clear button as suggested in #42.

I’ve reviewed the responsiveness of the link field across all three themes — Claro, Olivero, and Edu X (which is the one reported). The issue appears to be specific to the Edu X theme.
Please find the attached screenshots as evidence for reference.

Steps I followed to reproduce the issue:

1. Added a link field in the Basic Content type.
2. Created / Edited the basic page and checked the responsiveness.

Understood, thanks @danielveza for the clarification. I'm unassigning myself for now—if any further changes are needed, I'm happy to jump back in.

Hi @phenaproxima Thank you for the feedback. I’ve pushed the changes and attached screenshots for both desktop and mobile views.
Please review the complete code and let me know if any further changes are needed.

Hi @rmpereira I have understood the issue but can you please tell me where exactly the code change is required? So that I can looked into it ?

Hey, Before creating an MR, I wanted to discuss the approach I’ve taken to update the layout of the filters.

I’ve made the necessary code changes and attached a screenshot of the updated UI below for reference.

In the Search.svelte

<div class="boolean-filters-wrapper">
          {#each Object.entries(filterDefinitions) as [name, filter]}
            {#if filter._type === 'boolean'}
              <BooleanFilter
                definition={filter}
                {name}
                changeHandler={onFilterChange}
              />
            {/if}
          {/each}
</div> 

Could you please review and let me know if this approach seems correct, or if you’d suggest any changes or improvements?

Thanks!

I have replaced the revert confirmation text Are you sure you want to revert this to defaults? with This layout will be reverted to the default layout, any custom overrides will be lost. Are you sure you want to continue?. However, in my opinion, this message may be a bit too long. As noted in one of the comments on https://www.drupal.org/project/drupal/issues/3528251 ✨ Improve clarity of Layout Builder "Revert changes" confirmation form Active , and to maintain consistency, could we consider using the existing message Any unsaved changes to the layout will be lost. This action cannot be undone. instead?

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

Hi @sidgrafix Thank you for the clear explanation! That actually clarifies a lot — I'll definitely try uploading a larger file (1–2 GB as you suggested) or test from another device on the local network to see the behavior more clearly. Really appreciate you taking the time to share this insight — very helpful!

Hi @jeeva r, yes, "uploadprogress" is enabled and I also checked in the browser inspector — the code is working. However, I was looking at the UI, and the progress bar does not get completed. Please refer to the video I’ve attached for reference. That's why I thought the code is not working.

I tried patch #5, but I’m still experiencing the issue.

Steps I followed to reproduce the issue:

1. Changed the theme to Claro
2. Added an upload filed to the content type and in manage form display changed the progress indicator to bar
3. added a pdf file of 75mb while creating a content

I've attached a video recording as proof.

Let me know if I have missed any step. Thanks.

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

Would it be appropriate to change the target branch of the existing merge request to 11.x (the default branch), or would you recommend creating a new branch from 11.x and applying the suggested changes there because I don't see any option to change the target branch?

Please advise on the preferred approach to proceed in line with current contribution practices.

I am unassigning @nagatahmed from this issue due to no activity since March/April.

I would like to take this forward, but before starting development, I need to clarify a few things.

This issue seems to involve changing the layout of the filters. However, I am a bit unclear about the types of filters being referenced. Specifically:

1. Text filter – Could you please clarify what this refers to?
2. Multiple choice filter – Are these the checkbox filters?
3. Boolean filters – Are these referring to the "Sort by" filters?

Once these points are clarified, I’ll be able to proceed accordingly.

Thank you!

I have updated the ComponentValidationTest.php and .schema file as per the suggestions. For next steps I have to confirm that we will be creating "ValidStructuredDataPropExpression.php" and "ValidStructuredDataPropExpressionValidator.php" inside the /src/Plugin/Validation/Constraint , right?

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

Hi, I tried to reproduce the issue by following the steps mentioned above (screenshot attached). However, I would appreciate some clarification on the following point:

On the other hand, I also cannot get the chip and hover outline to appear at all for:
– the page title block
– the messages block
So perhaps this should be repurposed to that?

Could you please explain this in more detail?

Additionally, I’d like to understand the plan for resolving the help block issue.
Should I proceed with adding the block title and applying an outline on focus and hover?

Thank you!

Hey @phenaproxima → I'm not sure I fully understand the reason for removing this line. We added the route because there wasn’t an existing route that redirects to the Project Browser help page. I referenced similar implementations in other modules when adding it. Could you please clarify why this line needs to be removed? $output .= '<dd>' . t('Users who have the <em>Administer modules</em> can browse modules from the <em>Browse projects</em> page.') . '</dd>'; Thanks.

Attached the gif file.

I was able to reproduce the issue by following the steps mentioned above, and after applying #3, the issue was resolved. Attached the after video.

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

I resolved the phpstan issue by adding " // @phpstan-ignore argument.type" comment by taking reference from

KeyForEverySdcProp

validator file. Please review and let me know if anymore changes are required.

Unassinging myself so that someone else can work for test cases and keeping the issue to needs work only.

I have updated the code. Please review and let me know if anything is missed.

Just to confirm, should I follow the same approach for the other entity IDs as well?

I followed the Scenario 1 steps to reproduce the issue and #81 is working fine.

Attached before and after screenshots.

Hi @thoward216 thank you so much for clarifications.

Assigning the issue to myself to continue working on it as mentioned.

Hi @wim leers to test my code I followed the below steps:

1. edit the existing component and remove the default text from the required prop
2. saved the component

Let me know if this is correct or have I missed anything?Thanks.

I've implemented a new validation constraint NotNullValueForEveryRequiredSdcProp to ensure that all required props defined in a component's schema have non-null entries in the default_value mapping. This is based on the required array from the component plugin's metadata schema. The logic closely follows the pattern used in KeyForEverySdcProp.

I've tried to achieve the requirement as described—please let me know if anything is missed or needs adjustment.

I will give it a try!

I already can see the changes in the in the branch.

I will create a MR for #3 patch.

Hi @wim leers, could you please clarify what you mean by “update the UI”? Additionally, could you outline the next steps required for this issue so I can proceed accordingly? Thank you!

Is the work still is progress? Because I applied the patch and checked, I am still getting the error.

I attempted to update the target branch of the merge request, but it appears to be causing issues — the changes are not reflecting correctly. I believe the best course of action is to create a new branch based on 11.x and open a fresh merge request.

Hey, I have updated the code in the JavaScriptComponent.php file as per the discussion and created a merge request for the changes. Please review and let me know if anything further is required. Thanks.

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

@jonathan1055 Is it necessary to install the Scheduler module to reproduce this issue? I haven't installed it. Instead, to replicate the issue, I added the dropbutton to the operations column via the browser's inspect tool. Then, I used the following JavaScript code in the console to remove the href attribute from every alternate link:

document.querySelectorAll('.dropbutton a').forEach((link, index) => {
  if (index % 2 === 0) { // Remove href from every other link
    link.removeAttribute('href');
    link.style.cursor = 'default';
    link.textContent = link.textContent + ' (No URL)';
  }
});

The background color for the options without a URL appears to be rendering correctly in my case.

Please let me know if I may have misunderstood the issue or gone in the wrong direction. I have also attached a screenshot for your reference.

Thank you.

@smustgrave should I create a new MR for 11.x.dev or should I update branch of the current MR?

Hi @jonathan1055,
Could you please guide me on how to reproduce this issue? I’ve gone through the comments but wasn’t able to fully understand the steps. So far, I have changed the theme to Claro. Do I have to install the Scheduler module also?

Hi @laurii,
This is an interesting issue to work on, and I’ve been able to successfully reproduce it on my end. However, I would appreciate some additional guidance or clarification on the implementation approach.

Specifically, could you please elaborate on the statement:

“Use internal routing to navigate between pages to avoid a full page reload”?

Are we considering using a modern JavaScript framework approach—such as a component or a similar client-side navigation method? Any additional context or direction you can provide would be greatly appreciated.

Thank you!

I encountered some issues with the original branch, so I decided to close it. I have now created a new branch, updated the base branch to 10.5, and pushed the changes accordingly as suggested.

Changing the status to needs review.

Understood. Thanks @uv516 for all the information. I will raise the MR for this today.

Hi @uv516, before I start working on this, I’d like to confirm the steps to reproduce the issue. Once I make the necessary changes, I want to ensure I can verify whether the issue is resolved. Could you please share the exact steps to reproduce the issue?

I have resolved the PHPCS and PHPStan issues and unassigned myself so that others can pick it up and work on the test issues.

Sure, I will do that. Also, I'm not able to run drush cr because I'm getting the following error:

'Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent' does not implement the methods 'requiresExplicitInputs', 'getDefaultExplicitInputs', 'getExplicitInputs', 'explicitInputsToClientModel'.

I believe I need to define all the required methods in every file where the interface is implemented.

There is one more file,

GeneratedFieldExplicitInputUxComponentSourceBase.php

, under the same interface in which $inputs is used. Should I update the code there as well?

public function getDefaultExplicitInput(): array {
    $inputs = [];
    foreach (array_keys($this->configuration['prop_field_definitions']) as $prop_name) {
      assert(is_string($prop_name));
      $inputs[$prop_name] = $this->getDefaultStaticPropSource($prop_name)->toArray();
    }
    return $inputs;
  }

Thank you for confirming. Assigning the issue to myself.

Hi @wim leers,
I was considering working on this issue and, before proceeding, I wanted to confirm my understanding based on your comments. From what I gather, the goal is to rename "explicit_input" to "explicit_inputs" specifically in the ComponentSourceInterface.

Could you please confirm if this change should be limited to the interface only, or should I also update the related implementations accordingly?

Additionally, should I go ahead and create a merge request for the patch, or would you suggest any prerequisites before that?

I followed the testing steps outlined in the issue summary but did not encounter any errors in the console or elsewhere.

When I clear the text from the input field and attempt to publish the changes, a validation error is displayed: "The property name is required." — which is the expected behaviour.

Additionally, after switching to Page Data and then back to Settings, the field retains its default text value.

"When we create a component with the same name as one that was previously deleted, an error is thrown as described in the summary. However, after reloading the page, the component appears to have been successfully created. I believe there may be an issue with the error handling in this case.

I’ll try to look into it, but as I’m new to Experience Builder, it would be great if someone could help me locate the relevant part of the code.

As suggested in comment #67, I’ve pushed the changes from the patch in comment #64 to the 10.3.x-3207875 branch.
Please let me know if I missed anything or if there’s anything else that needs to be done.

I followed the steps and installed Drupal CMS with a database version lower than the requirements, but I couldn't reproduce the issue. It seems the issue has already been resolved elsewhere.

The error occurred because the source parameter was missing when generating the route URL for project_browser.browse in the project_browser_help() function. I fixed this by explicitly passing 'source' => 'official' to Url::fromRoute(). After this change, the error no longer appears.

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

I have reviewed this issue by following the provided steps and can confirm that the issue is now resolved. I’ve attached a GIF as proof of the working functionality.

I tried resolving it on my end and noticed that if we change the z-index value of the .header class to 0, the chatbot appears above the header. However, since we can't change that, I explored another approach:

What if we reduce the height of the chatbot initially, and then increase it when the page scrolls past a certain point? I'm attaching a video of what I’ve tried—before pushing the code I want to know your inputs please do share.

I created a new branch, rebased it and applied the changes manually.
Adding the screenshot how the buttons are looking.

I have unassigned the issue so that anyone else can work on tests.