Setting the user language via api

[LostKobrakai]

Hi,

I'm trying to save the language a user chooses on the frontend to their profile. But somehow it won't save. The language checked in the backend stays the same.

	if($input->get->lang != "" && $user->isLoggedin()){
		foreach($languages as $lang)
			if(strtolower(substr($lang->title, 0, 2)) === $input->get->lang){
				$user->language = $pages->get("id=".$lang->id);
				$user->save();
				break;
			}
	}

[LostKobrakai]

Nobody any idea? Other fields save without problems.

[Soma]

Works fine

$user->language = $languages->get("default");
$user->save();

[LostKobrakai]

Ok, it seems even more strange. I have two languages: default = german and english. If I change my language to english in the backend, I can change it back to german with this code, but it doesn't work the other way around changing german to english.

		foreach($languages as $lang){
			if(strtolower(substr($lang->title, 0, 2)) === $input->get->lang){
				$user->language = $languages->get("id=".$lang->id);
				$user->save();
				break;
			}
		}

Edit: Even just "$user->save()" without setting something changes english back to german for the backend.

Edited June 25, 2014 by LostKobrakai

[Nico Knoll]

why === and not ==?

And do you use "german" or "default" in $input->get->lang? Because it has to be "default".

[LostKobrakai]

=== because I don't sanitize it, so it's "saver", both should be Strings. But that's not the problem, the if statement works. I changed the title for both languages, so no need for calling it default. 

But as mentioned, even a single "$user->save();" without the loop changes my language from english back to default. It seems, no matter what I do, it's getting resetted to default language. 

For some iterations of the code I got this error: 

Notice: Object of class Language could not be converted to int in /Users/Benni/Projekte/A-06-2014_HONourables/www/wire/core/PagesType.php on line 108

But I don't know if that because of an error on my side.

Edit: just realized this could be useful: I'm running version 2.4.0

[Soma]

It's changing language because you look at the front end in a language, if you do a $user->save() the current viewed language will be saved. 

Everything works fine here, nothing wrong. But most likely just your approach and code that has a problem. I'm not sure you really need to save the user language like this, but why not.

[Soma]

why not

$lang = $languages->get($sanitizer->pageName($input->get->lang));
if($lang->id){
    $user->language = $lang;
    $user->save();
}

DOn't see the need for looping

[LostKobrakai]

I don't want the full name to be present in the URL, so the looping is needed. But this said, there's something wrong with saving the language. My problem is, whatever I try to set the language to be, even if I don't set a new language, the line "$user->save();" resets the users language to default.

[LostKobrakai]

I wrote a short testtemplate, which does only test a few variables before and after setting/saving the language, which outputs my problem.

In the backend I set the Language to "English" before running this test.

German => 1299
English => 1301

$user->language: 1299 (Changed because of german url structure, I guess)
$pages->get(user)->language: 1299 (should be 1301, from my point of understanding)
MySQL: 1301

Setting + Saving new $user->language (ID = 1301 (English)) 

$user->language: 1301
$pages->get(user)->language: 1299
MySQL: 1299 (at least this should be 1301 after saving it)

The saving part is stripped down to this.

	$user->of(false);
	$user->language = $languages->get("id=1301");
	$user->save();
	$user->of(true);

Edit: tested the same script under a fresh 2.4.0 install, without multilanguage pagenames. As expected the 3 variables are equal before the saving, as theres no language associated with the url. But after saving, the language still changes to default.

[Soma]

As I said the language is set on runtime via url on front-end, before it gets to your template, as you found out this is the LanguageSupportPageNames module doing this. The language is set to the $user->language at runtime before rendering. 

So 

$user->language
$pages->get($user->id)->language

are the same thing at that time. No matter what is saved to the user.

If you change the user language in your template and save the user, the user has that checked in backend. But then all following output would be changing language, even if the requested URL would indicate english, text and links would be german.

Everything works as expected here. Maybe you can tell a little more what you're trying to achive?

I think you got a lot mixed here adding to the confusion. I guess you get the user in two different ways, and that something is still cached and not loaded again.

[Soma]

Edit: can't reproduce any of what you wrote. Either with or without LanguagePageNames.

[LostKobrakai]

My goal is, if the user changes his language via the languageselector in the frontent (which adds a get variable), that this choise is reflected, by permanently changing the language setting, which shows up in the backend. 

I have no Problem with the language automatically being changed by the url, but if I try to save that language permanently for the user, it doesn't work. When this issue is resolved my second one would be, that I want to check if a logged in user is on a site (via searchengine or something), which is a different to his saved language and display a modal, if he wants to visit the site which is translated to his saved language. This will be difficult if only checking the database actually gives me the saved language.

[Soma]

I don't see any issue, it works fine. Whatever language I save to the user, this language is checked in backend and stays there.

[LostKobrakai]

That's strange, I even tested it online, while my other sites are locally developed under mamp 3. Same behavior with just language support and second language added to fresh install. This code doesn't save the language for me. 

<?php
  echo $user->language->id;
  $user->of(false);
  $user->language = $languages->get("id=1009");
  $user->save();
  $user->of(true);
  echo $user->language->id;
?>

If I refresh the page with this template I always get 10071009 for old and new language. The backend shows the same.

Edit: If I change the email together with the language, the email gets correctly saved.

[Soma]

And does it save if you do it in backend? It works fine here 2.4 and 2.4.5 and ever has (not heard of any issue)

$user->of(false);
$user->language = 1016;
$user->save();
$user->of(true);

If I do this, I get first load

1014

1016

Second refresh

1016

1016

Make sure you really setting it with a correct integer value.

"Notice: Object of class Language could not be converted to int in /Users/Benni/Projekte/A-06-2014_HONourables/www/wire/core/PagesType.php on line 108"

This would usually be if you do this

$pages->get($user)

$users->get($languages->get(1016));

You should write $user->id or $languages->get(1016)->id instead.

This $languages->get("id=1009"); - you can simply write $languages->get(1009);

There one important difference here, as get(ID) will always get the page regardless if hidden or unpublished, while get("id=1016, is=selector") will behave like a find and not return pages not accessible or hidden/unpublished, unless you're logged in or superuser.

Also what user are we talking about?

What I'm not sure is how you would save a visitors language on a language change? As they would be always the same guest user? Or are you talking about already logged in users?

[LostKobrakai]

Thanks for the patience, but even directly setting the id as value doesn't work. As for a fresh install ist a superuser named benni, nothing else changed. Edit: Forgot a answer: It does work, if I change the language in the backend.

For the site I want to have this functionallity, it's for a business club, so it's a feature only for logged in members.

[Wanze]

I was having a similair issue, see here: https://github.com/ryancramerdesign/ProcessWire/issues/409

But ryan fixed it and the solution worked for me.

[LostKobrakai]

Yeah, I'll take a look later, but good to know I'm not the only one experiencing this odd behavior.

Edit: Thanks, now it's working as expected.