Account created on 27 September 2024, 7 months ago
#

Merge Requests

More

Recent comments

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

@chhavi.sharma Thanks for the MR. However, it seems the phpunit is failing due to this merge request. Please take a look.

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

sorry for the delay, Now I've raised the MR with the proposed solution please review.

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!

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

As Patch is deprecated so I've raised MR for the given patch. Kindly 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.

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.

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

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

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

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

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

I have created MR that is solving the issue.
Also I noticed that if once a registration form is generated a error then it's status will be in pending status and when I try to delete the event series related to registrant it produces same error.
And the given MR solves this too. Please review and let me know if any assistance requires.
Thank you.

I've also added display config in settings.php still not getting any error. can you please attach any screenshot of error for better understanding.
Thank you

I have raised MR that is solving the error that is occurring while opening the preview page in edit mode kindly review it.
Let me know if further assistance required.
Thanks

Hey @thaoquang,
I have tried to reproduce the error by following the steps that you provided with the same version that you have given.
But I couldn't able to do so.I'm attaching the screenshot for your reference. let me know if I'm missing something.

I've tried to rebase but couldn't able to do. I think the reason of it is ,the issue was created before the branch 3.0.x was released so I think we need to create a new ticket for the same. Let me know if i'm missing something.

I have tried to reproduce the error by following the steps given in the issue summary
but i could not able to reproduce. please let me know if i am missing something.
Thanks

I've also faced the issue and the solution is fixing the error. and created a MR from the given patch as MR is easy to review.
Thanks

Production build 0.71.5 2024