Soma

Thanks Horst for bringing this up. I tried some things with using this fieldtype as config field. But it wasn't saving correctly due to it's value type of object. I made some major changes to this fieldtype. In short, the value now is handled as an array value and not as RangeSlider object anymore. See upgrade and changelog here: https://github.com/somatonic/FieldtypeRangeSlider#upgrade-notes (BTW Also renamed the module repo to FieldtypeRangeSlider) These changes now also allow for using the Inputfield as a config field in modules. Previously it wasn't possible, as the value saved wasn't treated as array. Simplest solution seemed to make the Inputfield implement InputfieldHasArrayValue. Regarding the defaultValue. This was only set and used in the Fieldtype and not Inputfield! So the defaultValue will be set to the field value. Inputfield then just deals with the value min and max. Since when using this module as a config field only, there's no fieldtype involved at all. Here just an example how to handle it as a config field. protected static $defaults = array( 'myrange' => array('min' => 10, 'max' => 90), 'myslider' => array('min' => 10) ); public static function getModuleConfigInputfields(array $data){ $data = array_merge(self::$defaults, $data); $fieldset = new InputfieldWrapper(); $modules = wire('modules'); // range with two values $field = $modules->InputfieldRangeSlider; $field->attr('name', 'myrange'); $field->attr('value', array( 'min' => $data['myrange']['min'], 'max' => $data['myrange']['max']) ); $field->isrange = true; $field->width = 90; $field->minValue = 1; // min value config $field->maxValue = 100; // max value config $field->step = 1; $field->label = 'Slider 2 range values'; $fieldset->add($field); // no range, only single value $field = $modules->InputfieldRangeSlider; $field->attr('name', 'myslider'); $field->attr('value', array( 'min' => $data['myslider']['min']) ); $field->isrange = false; $field->width = 90; $field->minValue = 1; $field->maxValue = 100; $field->step = 1; $field->label = 'Slider 1 value'; $fieldset->add($field); return $fieldset; }

Very wise words. ProcessWire have to be careful to not become a module hell. It can easily get out of hand.

Yes in modal. And its superior to other block style as every block is a page and can be published or unpublished etc and all multilang. I don't need visual inpage editing as much as a solid block type. Also you can (I do anyway) make all easy editable when viewing page.

Well those rows when edited have their own template with their own layout.

Page tables field supports multiple templates unlike repeaters. So it's possible now with dev.

I'm not sure why template=admin wouldn't work, just wanted to mention what I observed. I'm also seeing admin template is a system template and not selectable by selector config in PageLister.

Page lister uses has_parent!=2. There could also be pages under admin without admin template.

You're mixing up things. This should be more like include("/home/xyz/public_html/pw/index.php"); wire("user")->language = wire("languages")->get("en"); $referenzen = wire("pages")->get("/referenzen/"); $references = $referenzen->children; foreach($references as $reference) { echo "<li class='references-item'>"; echo "<p>{$reference->title}</p>"; echo "</li>"; }

This get() always returns a page or a null page ( if nothing found)

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()