@dhruv.mittal

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

Reviewing

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 !!

The error you are referring is in different module and you selected wrong module while creating the issue.
So I've changed the project and working on it

dhruv.mittal → created an issue.

As Patch is deprecated so I've raised MR for the given patch. Kindly review

As patch is deprecated and MR is easy to review I've raised a MR against the given patch. please review.

I've tried to reproduce this issue usnig given steps to reproduce but could not able to do it.
I think this issue is fixed in the latest release of trash module. So we should close this ticket.

Please review

PHPunit tests are failing so moving this issue to Needs Work

Refactored form button text logic for comment forms. Replaced form_isSave check with $entity_id[0] == 'comment' to handle comments separately. Removed the _edit_form naming for comment forms, treating them consistently as "save" forms. Verified that custom button text is now applied correctly for comment forms. so moving it to RTBC

For me it's is working fine. and looking backward compatible. so moving it to the RTBC

I don't this issue is related to this module.
Let me know if I'm wrong.

As patch is deprecated so Converted patch into MR.

As MR is given so Moving it to NR.

This issue is already resolved and composer.json already has "drupal/commerce": "^2.29 || ^3".
Thanks.

dhruv.mittal → created an issue.

Sorry @renatog for removing the AJAX URL by mistake.
I have added that back and working fine for me please review.

I've raised the MR for the same please review.

previously I added ' { } ' instead of ' [ ] ' . Kindly review now.

Kindly review

Kindly review

Kindly review

I was getting below error after login/register
Fatal error: Declaration of Drupal\flag_anon\FlagAnonLinkBuilder::build($entity_type_id, $entity_id, $flag_id) must be compatible with Drupal\flag\FlagLinkBuilder::build($entity_type_id, $entity_id, $flag_id, $view_mode = null) in /app/web/modules/contrib/flag_anon/src/FlagAnonLinkBuilder.php on line 73
I have raised MR for the same,and now it works.
Please review

Kindly review.

I have resolved merge conflicts and rebased it please have a look.

kindly review