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.

I don't know if it has to do with that specific issue, but I think you should leave output-formatting off as long as you save stuff.

I think the sanitizer is the bigger bottleneck as the mysql fieldsize, as mediumtexts can already hold ~16.000.000 bytes of data, while the sanitizer limits to 16.000 chars by default. Could be that this was a consideration of performance to not allow more by default.

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.

It's nice to get the list of translateable files, but you could translate them all without the module by adding them via the path. One is more newbie friendly, but shows lots of files, you may not need, the other way is more for people, who already know what they want to do.

If you need more space, yes. Shouldn't matter, as long as you don't change the database schema of the field afterwards. Look here for the different sizes: http://stackoverflow.com/questions/6766781/maximum-length-for-mysql-type-text Edit: The other way around would be a second fieldtype_textarea, where you could change the database schema in the module itself. I thinks that's the better way of solving this.

The body field is saved to field_body.data which is a mediumtext field in mysql. I don't know how much characters are allowed in these, but these fieldtypes all got their limits.

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.

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.

=== 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

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.

Nobody any idea? Other fields save without problems.

I would use "find("!user_activation=0");" instead of $=, if it's a integer or checkbox field.

I read the selector page quite accuratily a few days ago. http://processwire.com/api/selectors/ under "Negative operators".

Doesn't "template=user, !login_end<=today" work?

The second "$" is to much. $this->$users->find("!user_activation$=0");

Looks fine from here. What field is it, that you called collection? Did you doublecheck for spelling issues, in your post you mention "collections", while in the code it's "collection".

Hi, I just found a problem with the html inputfield number in conjunction with floats. If I use the german language pack it changes the value of the input field to "," seperated instead of ".", so the input field doesn't display the value.

As far as I know most of the language packs are changed with full releases, so there are differences between 2.4. and the dev version. Have you tried deleting the existing InputfieldPage.module translation file and manually add a translation via the admin backend, instead of uploading the json from the language pack?

Which version of ProcessWire do you use? A quick look at 2.4.0 and newest dev version shows translateable strings for everything that's still english in your screenshot.

This should be the way to go. If a page is not visible, it won't pop up in the menu. http://modules.processwire.com/modules/custom-page-roles/ Edit: Just scrolled a bit further in the description, maybe it doesn't work, looking at the ceavats. Never used the module.

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; } }

You only need to remove one of these, the first one if your ProcessWire installation is not installed to a subdirectory (""http://domain.com/processwire/".

I just updated to 1.0.1 and the new modal window shows all my repeater pages, as they are all unpublished.

Removing the "optional" labels could help, as the user only has to know which fields he must fill. But for me the required labels are also a problem. They are so well included in the layout, but so far on other side of the form, that I don't see them. My view goes down the center, over "full name" and "email" label to the more dense area of the "optional" stuff. Maybe additionally move the required label just after the fieldlabel.