@divyansh.gupta please review I have removed .gitlab-ci.yml file. Now all the changes are only related to this issue.
Working on it
Merge conflicts need to be resolved
Automated tests are needed to test the feature.
I tested The MR.
It is working fine and removing error thus moving it to RTBC.
Mentioned issue is present in the theme. After applying the MR issue is getting resolved.
Attaching the screenshot FYR.
Before
After
So Moving it to RTBC.
I'm not able to see any deprecated Trait related warning.
Would you check it once again or please provide screenshots for the same.
Thanks.
Thanks for the patch
Working fine for me so moving it to RTBC.
As patch has been deprecated and MR is easier to review so I raised MR.
Please Review
MR !102 has Merge conflicts and those need to resolved. So moving it back to Needs work for the same reason.
I agree that Nullable types must be explicit.
And changes looks fine so marking it to RTBC
slucero → credited dhruv.mittal → .
Please Review.
Working on this
Thank you for your contribution @undersound3.
But as Patch is deprecated and MR is easy to review and apply, So I have converted your patch into MR.
Thank you
Hey @mkalkbrenner
Thank you for the patch but would you please share the steps to reproduce.
Please review
I have successfully reproduced the issue.
And after applying the MR the issue is gone.
so Moving it to RTBC.
Hey impol!
This issue is fixed in the newer version of the conditional_fields and it no more persists.
Thank you !
Created MR against 2.x branch kindly review
Rebased the MR as it was some commit behind. and will create a new MR that will target 2.x
dhruv.mittal → made their first commit to this issue’s fork.
Created MR as it is easy to review.
please Review
Hi @cgoffin,
Thank you so much for the patch — I’ve tested it, and it’s working perfectly on my end!
I just had a small question, if you don’t mind : ) I was wondering about the decision to leave the default value field empty. Would it perhaps make sense to assign a default value instead?
Appreciate your help and insights !
Thanks
Please review
Hello @rohit rana
I have installed the module in the suggested version, but I could not get any warning messages in Logs.
Can you share ss or proper steps to reproduce so that I can review the issue thank you
Added dependency injection as asked.
Please review
moved to NR as MR is provided
I have resolved all the pipeline errors those were occurred by my changes. please review now
I've tried to reproduce the issue with the given steps to reproduce but couldn't able to do so.
So unassigned myself for more info
Hey @trickfun would you please provide steps to reproduce.
@chhavi.sharma Thanks for the MR. However, it seems the phpunit is failing due to this merge request. Please take a look.
There is merge error please look @lavanyatalwar..
dhruv.mittal → created an issue.
I encountered the mentioned error while trying to enable the module. However, after applying the merge request, the error no longer appears. Therefore, I'm moving it to RTBC.
Thanks
dhruv.mittal → changed the visibility of the branch 3519666- to hidden.
sorry for the delay, Now I've raised the MR with the proposed solution please review.
moving it to the right status.
This issue is persist in 4.5.5 but resolved in 4.5.x as 4.5.5 is not a branch it is a tag so I think I won't be able to create a MR that is targeting 4.5.5 let me know if I'm wrong
As patch is deprecated and it is easier to review MR, for that reason I've raised MR from the given patch.
Thanks!
Thank you for your kind feedback.
In case you are referring to the location where this class is defined, it can be found in the modal-page-modal.html.twig file, specifically at line number 30.
It makes sense. I agree that rejecting caps-in-extensions via AJV could lead to a confusing and inconsistent UX, especially since Drupal Core accepts them and users can upload/select those media items without issue.
Normalizing file extensions to lowercase on the client side before sending the PATCH request seems like a practical middle ground. It avoids breaking the backend while keeping things smooth for the user. Since the casing of file extensions doesn’t affect how they’re served or interpreted, this should be safe and non-invasive.
To make it more robust, we could also log a warning or surface a note during validation when a case normalization occurs—just to help with debugging or future maintenance if needed.
Longer term, if XB aims to strictly align with Drupal’s media handling, it might be worth revisiting how validation is handled here to better reflect the broader system behavior.
Open to feedback if anyone sees a downside to that approach!
Please review
please review
Merge conflicts need to be resolved. so moving back to needs work.
I'm still not able to reproduce this issue so postponing this issue until someone else finds the same error.
Thanks!!
Hey @bnjmnm !!
This is great catch. I think we can handle this by updating regex to be case insensitive. This is the most flexible and safe fix.
Update the regex to allow upper or lower case file extensions using the case-insensitive flag (i).
What is your take on this ??
Thanks !!