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? 😊