REST API URL changes when 'Slugs translations(Experimental)' turned on, causing plugin issues

[hesseldj]

When 'Slugs translations(Experimental)' is turned on in qTranslate XT, the REST API URL for Wordpress changes from 'wordpress.org/wp-json/' to 'wordpress.org/en/wp-json/', which causes issues with certain plugins. For example, Burst Statistics has been reported to have problems when this feature is enabled.

Unfortunately, we are unable to consistently reproduce this issue. However, @sviluppomania has reported experiencing this problem.

We believe that this issue could be resolved by disabling qTranslate from changing the REST API URLs. We would appreciate any assistance in implementing this solution or any other suggestions for resolving the issue. Thank you.

[vonsch76]

You can hide the slug for the main language, then the issue is solved. Though your point is right, this seems a bug.

[hesseldj]

Thank you for your suggestion, but it does not fully fix the issue. When a second language is selected, the slug is also changed and the REST API URL breaks.

[vonsch76]

I am also using the REST API with the same settings (hide language code for the main language) and works fine without any tinkering. Just website/wp-json/domain/service. In the meantime tested with all languages set and the main language just redicrects to website/wp-json - as expected, while the second language leaves unchanged website/hu/wp-json Still both generates the expected result.

[hesseldj]

I apologize if I misunderstood your message. From my understanding, it seems that qTranslate should either not change the WP REST URL or it should create REST routes based on the code from all the plugins.

We are utilizing the default Gutenberg api-fetch method in JavaScript. It would be helpful if qTranslate could integrate with these default REST API functions, such as api-fetch and register_rest_route, to avoid any issues with plugin functionality. Is there a way for us to integrate with qTranslate or for qTranslate to integrate with these default REST API functions?

[vonsch76]

I am sorry, but I am lost then. I use a plugin that was written by me and uses wp-json. qtranslate does not affect the REST route. Though as noted earlier I have the skip language code for the main language, so /en/wp-json/xyz redirects /wp-json/xyz. Still my plugin works under website/wp-json/dom/serv the dom and the serv are the ones I have given in the code. Would be good to see the details you are referring to.

[hesseldj]

Thank you for your help in troubleshooting this issue. Enabling the "skip language code for main language" setting resolves the issue with the REST API, and it allows both the main and secondary languages to work correctly.

Without that setting turned on both rest routes don't work. So that might still be a bug? I don't mind if you close this issue for now though. For us, the issue is solved. Sorry for the hassle and the confusion. Thank you for being so reactive.

[vonsch76]

Nobody minds solving bugs, it might be. @herrvigg will decide.

[herrvigg]

There should be no redirection with REST regardless of the options, so if there are some it's a bug. Slugs is not supposed to change the behavior here, so it can be another type of bug to investigate.

[sviluppomania]

Hi @herrvigg , Is there any news about this Bug?

Best regards

[herrvigg]

We need a clearer understanding. Is this a problem specific to slugs or other? Precise the scope better, describe exactly how to reproduce and what differs from the expected result with all the context.

[sviluppomania]

Hi @herrvigg , yes, it's a problem caused when "Translations by Slug (experimental)" is turned on, causing problems with the Burst Statistics plugin. In practice, she obscures the statistics dashboard of Burst Statistics as the REST API does not work with multilingual with Slug active (e.g. / En / wp-json / burst / v1 / fields /) presenting the following errors:

• Impossible upload resource: the server responded with a status of 404 () – Code not detected (in promise) Object code : "invalid_json" message: "The response is not a valid JSON response."

While if deactivated it regularly shows the statistics dashboard but calls the REST API without "/en/"

One solution that seemed to fix the BUG was to turn on "Hide language information for primary language." but still remained for the "secondary" languages, thus not solving the BUG.

I quote @hesseldj post

We are utilizing the default Gutenberg api-fetch method in JavaScript. It would be helpful if qTranslate could integrate with these default REST API functions, such as api-fetch and register_rest_route, to avoid any issues with plugin functionality. Is there a way for us to integrate with qTranslate or for qTranslate to integrate with these default REST API functions?

Best regards

[sviluppomania]

Hi @herrvigg , yes, it's a problem caused when "Translations by Slug (experimental)" is turned on, causing problems with the Burst Statistics plugin. In practice, she obscures the statistics dashboard of Burst Statistics as the REST API does not work with multilingual with Slug active (e.g. / En / wp-json / burst / v1 / fields /) presenting the following errors:

• Impossible upload resource: the server responded with a status of 404 () – Code not detected (in promise) Object code : "invalid_json" message: "The response is not a valid JSON response."

While if deactivated it regularly shows the statistics dashboard but calls the REST API without "/en/"

One solution that seemed to fix the BUG was to turn on "Hide language information for primary language." but still remained for the "secondary" languages, thus not solving the BUG.

I quote @hesseldj post

We are utilizing the default Gutenberg api-fetch method in JavaScript. It would be helpful if qTranslate could integrate with these default REST API functions, such as api-fetch and register_rest_route, to avoid any issues with plugin functionality. Is there a way for us to integrate with qTranslate or for qTranslate to integrate with these default REST API functions?

Best regards

@herrvigg

[sviluppomania]

??

[spleen1981]

Can you test the slug_fixes branch?

[sviluppomania]

Puoi testare il ramo slug_fixes ?

Hi, this solution #1363 resolves the error and now the statistics dashboard is visible without errors. Thank you.

[herrvigg]

Merged a series of fixes with #1363 in master. Sounds like this is solved for some users. @hesseldj can you confirm this closes the original issue?