I hope everything is fine with everyone here.
I’m facing an issue with a case sensitive URL match. I can think of 2 possible solutions but I don’t know how to implement them on Frontity.
Context: My WordPress has a CPT named “book” (example). All requests to a single book (from Frontity, via REST API) I intercept on WordPress. This interception is to validate if that book exists on the database/CMS. If it doesn’t exist, I make a request to an external REST API (from WordPress) to get the basic data from this book and create it in WordPress. The original WordPress REST API request will return the book data (that was just created) to the Frontity application, so the final user always sees a book data even if it didn’t exist yet on the WordPress site (the only requirement is the book to exist on the external REST API I’m using).
Issue: If my request (Frontity) is /book/ABC, the request is made with success, the REST API gets the data from the external service/source with success, the post entry is created with success, but Frontity shows a 404 / not found page. I understand this happens because the WordPress URL of this entry is actually /book/abc and not /book/ABC, so Frontity is showing a 404 page (debugging the REST API returned to Frontity, WordPress is doing a case insensitive search - /wp-json/wp/v2/book?_embed=true&slug=ABC returns the same content as /wp-json/wp/v2/book?_embed=true&slug=abc - so I do believe the issue is on Frontity side).
Possible solution #1: Make Frontity redirect all URLs to its own version only with lower case letters: /book/ABC would redirect to /book/abc.
Possible solution #2: Make Frontity recognize the /book/abc entry on WordPress also as /book/ABC (like a case insensitive check on the Frontity side).
But I still don’t know how to implement any of these solutions, or even if there is a better one.
If anyone here has any idea how to fix this issue, I will appreciate the support.
Thank you in advance, Fernando