Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does it define which language to return on Ajax calls? #288

Closed
pimteam opened this Issue Oct 16, 2015 · 9 comments

Comments

Projects
None yet
2 participants
@pimteam
Copy link

pimteam commented Oct 16, 2015

I am trying to make integration for the WatuPRO plugin but have this issue:

When admin-ajax.php is called it loads the default language instead of reading the currently selected one. This happens even if I manually hardcode a ?lang=de string to the Ajax URL

@johnclause johnclause added the question label Oct 16, 2015

@johnclause

This comment has been minimized.

Copy link
Member

johnclause commented Oct 16, 2015

It gets it from cookies or referral url. "?lang=de" should also work, but should not be necessary. I am not sure what causes the confusion on that theme, that needs to be investigated.

Reference: https://wordpress.org/support/topic/problems-with-watupro just for booking purpose.

@pimteam

This comment has been minimized.

Copy link
Author

pimteam commented Oct 19, 2015

I found the problem. In qtranslate_core.php around line 300 the following preg_match fails when the $url_info['query'] contains string like "lang=de"

elseif( !empty($url_info['query']) && preg_match('/(&|&|&|?)lang=([a-z]{2})/i',$url_info['query'],$match) ) {

The match expects that the $url_info['query'] will start with "?" or "&" but it doesn't. I don't know why it doesn't but it's probably easiest just to write the match in a way that it will cover the case with "lang=de" without ? or &. When I remove the (&|&|&|?) clause from the preg_match it starts working but the language goes to $match[1] rather than $match[2] so this should also be considered.

@johnclause johnclause added the bug label Oct 19, 2015

@johnclause

This comment has been minimized.

Copy link
Member

johnclause commented Oct 19, 2015

Wow, what a discovery! That rx was originally tuned for the whole URL, and then switched to query string only. I checked in the change at GitHub.

What I do not understand, how did you hit it? admin-ajax.php would not hit this line, because $link would be false. It must be during conversion then, when qtrans_convertURL is called, is that right? But, as I mentioned, admin-ajax.php gets language from cookies or referral, so you do not need to do conversion.

I guess, this is why this bug was not reported for so long. What exactly were you doing to hit it?

@pimteam

This comment has been minimized.

Copy link
Author

pimteam commented Oct 19, 2015

Hm, this is odd because I am not doing anything special - just sending POST request to admin-ajax.php. Do you want to see the plugin code that sends the request? If you only want to see the POST request, the temp URL is here: http://purplesalad.net/blog/deutsch-test/?lang=de (I will remove it after that)

I debugged a bit more and figured out that the function is called twice. $link is false the first time, but true the second time. I've left my test output active if you want to see it.

@johnclause

This comment has been minimized.

Copy link
Member

johnclause commented Oct 19, 2015

Yes, on POST to admin-ajax.php, it is called first on URL itself, then on referrer url, which will have $link as true, but if you send admin-ajax.php?lang=de, then it should detect language from URL itself (with $link=false), not from referrer.

Anyway, somehow you hit this line and it is important that it is now fixed. Does it work for you with the change checked in? Does it work for you if you do not add ?lang=xx to admin-ajax.php?

@pimteam

This comment has been minimized.

Copy link
Author

pimteam commented Oct 19, 2015

Yes, works now without adding anything to admin-ajax.php. Thanks for the fix!

@johnclause

This comment has been minimized.

Copy link
Member

johnclause commented Oct 19, 2015

Are you using "Query Mode" for "URL Modification Mode" on page /wp-admin/options-general.php?page=qtranslate-x#general? Otherwise you should not have had problem before the fix? I am still a bit fuzzy how you hit that line, but maybe it is not important now. Are we ready to close the issue?

@pimteam

This comment has been minimized.

Copy link
Author

pimteam commented Oct 19, 2015

Yes, used Query Mode as I was just testing and found it to be the simplest. The issue can be closed.

@johnclause

This comment has been minimized.

Copy link
Member

johnclause commented Oct 19, 2015

I see. Query Mode is the least popular, since it looks ugly. Anyway, I am glad we fixed a problem. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.