[Escalated to WPML Developers team] Language URL directories cause broken redirects for REST API requests using the `rest_route` query p...

Hi Christopher. When posting this issue, I hoped to keep things a bit simple as the central issue was WPML attempting a redirect when it shouldn't be. I'll be more specific.

The TL;DR issue is attempting calls using the rest_route URL query parameter and not the REST API pretty permalink URL causes WPML to do a 302 redirect when following documented setup guides for using language directories (and possibly other configs). This redirect is a bug in WPML which breaks many of these calls, particularly authenticated calls and non-GET method calls (such as PUT, POST, and DELETE) as the 302 redirect causes the request body to be lost, resulting in the loss of all non-URL-parameter data.

Since posting technical details here isn't reliable, I created a Github gist with the key details that a developer can use to better see the issue. hidden link

"1) A URL like this even does not work when WPML is not active:"

Sorry, I got the URL wrong. It should be:

hidden link

The URL doesn't matter so much though. I was only using it as an example that WPML is doing a redirect for a request to the REST API when it should leave the request alone. This is made clear in the gist I linked to above.

"2) On the site neoncat.party there is an immediate 302 redirection."

That immediate 302 redirect is due to following the "Redirecting the Root Domain to the Default Language Directory" instructions detailed here: https://wpml.org/documentation/getting-started-guide/language-setup/directory-default-language/#redirect-the-root-domain-to-the-default-language-directory

I did this because it matches the config of the original customer that reported this issue to us. However, I discovered that this does not affect this report since removing this modification does not change the behavior of the WPML redirect for REST API requests.

"Would you please setup a Root page following the steps mentioned in the documentation below?"

The site already had that change. You can see the settings for the test site in the attached image.

"If the issue persists we still need your help implementing whatever you do on a clean installation to be able to see the result to be able to troubleshoot:"

The issue will persist because it is a bug in the logic of your code. I gave the key configuration details in my original request and included the debug output from the plugin. I don't know what more I can provide, so I created an admin user on the site that you can test. You can find the login details here:

hidden link

I should note that asking us to change the WPML config to fix this issue is not an acceptable solution. I'm contacting you on behalf of a mutual customer who reported an issue to my company. I dug into the issue and found this bug. Fixing this specific bug in WPML resolved the issue our mutual customer reported to us. This customer told us that they are not willing to change any WPML configs to fix the issue.