Advanced trackChanges

[LostKobrakai]

Hey,

while my problem with saving a users language is now resolved, I'm now trying to compare the saved language of the user to the language of the current page. With LanguageSupportPageNames activated the "$user->language" is overwritten to reflect the language, which is determined by the url, without a backup of the previous value.

Now I could write a module to replace this part of LanguageSupportPageNames, but I don't like to, as I need to update it, if the core changes. Also I could easiely just quickly query the database, which seems also kind of hacky to me, but seems like the way to go for now.

What I would prefere is, if the trackChanges() functionality would not only store the changed fieldname, but also it's original value. So a comparison would be as easy as "$user->language == $user->getChanges()->language".

Greetings,

Benjamin

[Soma]

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.

[Soma]

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

[LostKobrakai]

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.

Thanks for your insight in the topic of the different functions before the template loading. But I don't like the uncaching way, because it would also revert every other change made to the $user until this part, which seems not desireable to me. I think I'll go with you second answer, instead of the mysql query I use right now.

Edit: Is there any documentation or way to find our more about the order in which modules are loaded in ProcessWire? Especially for module developement this would be useful.

[Soma]

Shame I can't like myself.

[LostKobrakai]

Feel being liked, for all the knowledge about pw I'd like to have

[owzim]

A bit off topic, but I am curious Soma:

How does the event know the argument names? I've found in the Wire class that when runHooks is called the HookEvent get's the arguments passed. Digging into the HookEvent class, I see that arguments can either be a numeric or an assoc array.

So, I guess if I make a method in my Wire derived class hookable like so:

public function ___foo($bar, $baz) {}

When I hook into that method, I would NOT be able to get the arguments by name ($event->arguments('bar)), only by index ($event->arguments[0]), right? If not how would I DO make them able to be retrieved by name? If yes, is there some magic happening like stated here?

Thanks

[kongondo]

The argument names are the method arguments/parameters ..So, in your method foo(), there are two arguments...bar and baz....with 0 and 1 indices respectively..So, you can get with either e.g. event->arguments(0) is the same as event->arguments('bar') but the numeric index is faster (although less readable)...

http://processwire.com/api/hooks/#read_arguments

Edited March 12, 2015 by kongondo
edited link

[owzim]

kongondo thanks, great to know that I really can reference the arguments by name, that is awesome. I still fail to understand how that works under the hood, I am always interested in that

[kongondo]

Until last week Hooks were mostly a mystery to me too...until I did this and this and got this

[owzim]

Thanks! Na, hooks are not a mystery to me but there are certain aspects, especially those under the hood (I am repeating myself ) that I still like to fully understand.

[Wanze]

@owzim

Here you go: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/HookEvent.php#L144

PHP's reflection is the secret, like you already guessed

[owzim]

Grand, thanks @Wanze

I always think ProcessWire is so powerful and flexible, but that is also because PHP is so powerful and flexible, despite its fuglyness.

[kixe]

To track changes in module settings I am doing something like this. Is there a better way?

static public function getModuleConfigInputfields(array $data) {

	$modules = wire('modules');
	$fields = new InputfieldWrapper();
	$defaults = self::getDefaultConfig();
	$data = array_merge($defaults, $data);
 
        $f = $modules->get("InputfieldText");
        $f->attr('name', 'mysetting');
	$f->label = __("My Setting Field");
        if(isset($_POST['mysetting']) && $_POST['mysetting'] != $data['mysetting'])
              $f->message(__('Setting Field Value changed to').' '.$_POST['mysetting']);
	$f->value = $data['mysetting'];
 	$fields->add($f);

        // other stuff

	return $fields;
}