Jump to content

Advanced trackChanges


LostKobrakai
 Share

Recommended Posts

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

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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;
});
  • Like 12
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 8 months later...

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

Link to comment
Share on other sites

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 by kongondo
edited link
  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 1 month later...

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;
}
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...