Soma

Have you set a filter or category?

Shame I can't like myself.

As for your wish request. It is already possible to track changes, what -> old -> new value. $user->setTrackChanges(true); wire()->addHookAfter("User::changed", null, function($event){ $what = $event->arguments("what"); $old = $event->arguments("old"); $new = $event->arguments("new"); echo "changed: " . $what . " - " . $old . " -> " . $new; });

Changing core modules is never an option. Not even consider it temporarely. But there's plenty of ways and hooks you can change behaviour of core modules. There a couple ways to do that, in templates consider this // current viewed language $viewLang = $user->language; // clear user page cache $pages->uncache($user); // saved user lang echo wire("user")->language; // set back viewed language $user->language = $viewLang; Or there would be a ways to handle it with a simple autoload module. Since the language is set after the init() you can get the stored user language there. Then Language support sets the language on the ready() method, so you could get the currently viewed language in the ready() of your module and compare.

This error means add() isn't working with the "documents". The output formatting turned on, most likely the problem here. "documents" is single file field?

=* should be *= Any modules installed?

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?

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.

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

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.

Textarea sanitizes length I think. So changing db doesn't have an effect.

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

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.

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

Page "name" is not a field like the others. https://processwire.com/talk/topic/4720-how-to-set-page-name-in-different-languages-through-the-api/ You'd use $page->set(key, value); instead of setFieldValue()

https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=64049

At what value is "Any"? If it's empty then "/contract/" does exist.

Depends what field "image" is really. If it's single image field your code would be fine. If it allows more than 1 image it will be a WireArray, and your code would fail. Then you'd need to treat it as such using if($product->image->count){ ... } Then you'd access images in the array using a foreach loop, or with one of the array functions $product->image->first()->url or $product->image->eq(n)->url If that's the case you might want to set "image" to allow only 1 image (as the name suggests) ,then your code would work and be consistent with the naming. After all I could have also linked to the other 1'000'000 threads about this very same image field problem everybody has. But maybe it's just enough to link to the documentation which explains this again. https://processwire.com/api/fieldtypes/images/

Do those pages have the language really active?

better count than find if($pages->count("/contract/")){ // exists } with find() it would be slightly less efficient if($pages->find("/contract/")->count){ // exists } Or get() will return a NullPage object if not found if(!pages->get("/contract/") instanceof NullPage){ // exists }

After all there's some quirks and stuff not coded very well. I have forked the shop module some time ago and fixed/changed minor things. I'm not sure what causing your error exactly, but seems as the session sometimes isn't set correct when the form wasn't valid or so. You could try my version of the shop module, it's the dev version that has some changes there. https://github.com/somatonic/Shop-for-ProcessWire/tree/dev Although there's more changes and additions in this version, but should be compatible and not less unstable than the apeisa version.

The payment module is stored in session , so there might be an issue on your side. I use the shop in many projects and never had an issue with that.

This works just fine when used without roles=rolename. There seems to be an issue for the matches when roles selector with names are used, use role ID instead.