Img prop constraints require extension to be lower case

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

Updated the regex for image-uri and stream-wrapper-image-uri to be case-insensitive using the (?i) flag.
This allows image extensions like .JPG, .PNG, etc., from Media Library to work correctly and fixes the Twig rendering error.
Please review, Let me know if there’s a better approach we should consider.
Thanks @dhruv.mittal for the helpful suggestion!

The case insensitivity should be specific to the file extensions, not the entire uri

Updated the regex to apply case-insensitivity only to the file extension part using (?i:...) instead of applying it globally.

Merge conflicts need to be resolved. so moving back to needs work.

This commit introduced ~12 files of unrelated changes. Since the actual fix is likely a single-file change, it may be worth starting a new MR vs trying to untangle all the unrelated changes.

The failures here (in SdcPropToFieldTypePropTest) are legitimate

It's because JSON Schema uses (?i) at the start of a regex to indicate case-insensitivity. But PHP uses PCRE, which uses /i at the end of a regex to indicate the same 😅

@bnjmnm Actually … I had this:

              // @todo JSON schema does not support case-insensitive matching!!!! https://json-schema.org/understanding-json-schema/reference/regular_expressions

in \Drupal\experience_builder\ShapeMatcher\SdcPropToFieldTypePropMatcher::matchEntityPropsForScalar() 😅

Turns out that this ?i: prefix this MR added is not part of the JSON Schema spec, but of the ajv library that XB's JS uses.

If this is the case, why don't we make our client automatically convert every pattern to a regex, which then would allow to use the /…/i syntax PHP supports?

See

• https://github.com/orgs/json-schema-org/discussions/148
• https://github.com/json-schema/json-schema/issues/188
• https://github.com/ajv-validator/ajv/issues/101

🙏 Whatever we decision we make here, we must explicitly document it because it (AFAICT) deviates from the spec.

If this is the case, why don't we make our client automatically convert every pattern to a regex, which then would allow to use the /…/i syntax PHP supports?

I don't think this would mitigate this particular situation. The issue is that Drupal Core allows adding media that has caps characters in file extensions. Uploading new media items like some-pic.JPG is not performed anywhere that ajv even runs.

We could modify the AJV logic so it sees caps-in-extensions as invalid and thus not making the back-end-breaking PATCH request, but it doesn't seem ideal to not support caps-in-extensions media at all in XB when it works everywhere else in Drupal. I could also see people being frustrated that such media is available to select but they're unaware it's not valid until choosing it and seeing a validation message in the input.

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!

Thoughts about #17, @bnjmnm? 😊

If everything is ultimately based on the target id, then #17 is fine.

If not, then it would run the risk of missing images on case sensitive file systems. I'd need to debug around to say one way or the other, but perhaps someone else already knows whether or not this is the case.

wim leers → closed merge request !886

Thanks to \Drupal\Tests\experience_builder\Kernel\ComponentInputsFormTest + \Drupal\Tests\experience_builder\Kernel\ApiLayoutControllerPostTest it should be quite easy to write a failing test for this.

Once we have failing tests, putting a breakpoint on the place where the exception gets thrown and then looking through the stack trace should reveal whether this truly is best mitigated on the client side as @dhruv.mittal suggested in #17, or if it actually can be handled on the server side.

I ran into this with an image ending in .JPG. When I was stepping through to figure out the issue, it seemed clear to me that this should be fixed server side. Otherwise, if you're writing PHP code that validates the component it will still fail, and it seems odd to force the caller to normalize things ahead of time.

Tests are failing with the new expression. I'll check

Now is ready for a review. I've left some questions.

Test-only CI job fails 👍 → removed .

I'd like to understand why this didn't implement #17's suggestion.

(I'm not opposed, but would like to understand!)

@isholgueras' remarks/implied concerns about the current infrastructure are absolutely valid, which is why I opened 📌 Decouple image (URI) shape matching from specific image file types/extensions Active .

This is a pragmatic solution ahead of bigger changes after beta1 in 📌 Decouple image (URI) shape matching from specific image file types/extensions Active . 👍

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