Prioritising hooks for same event.

[netcarver]

Am I right in thinking that multiple hooks that are added for the same event can be prioritised by doing something like this...

$session->addHookAfter( 'login', $this, 'myLoginHook', array('priority'=>xyz) );

Where xyz is the relative priority for the hook and the lower the value, the earlier it will be called as the hooks are executed?

[ryan]

That's correct. At least, that was the intention. It's one of those things I thought would come in more handy than it has… I'm not aware of it ever being used. So I think the only time it has even been tested is when I originally coded it in there (at which time it was working). No recent confirmation of current functionality though. A quick glance in the code seems to indicate that it should work as intended, though please let me know if you find otherwise.

Default priority level is 100 (that's what gets assigned when none assigned).

[netcarver]

Ok, an update. To get two of my modules to work well together I do need this functionality. I basically want the 2-factor login module to get first crack at the hook before the login alarm gets to log/email the users.

I set the priority in the 2-factor module to 10 and in the alarm module to 2000 (just to be sure) however on adding a die(__CLASS__) to both hook handler routines I could see that the alarm module was getting called first. An unexpected result, but I've now found out why.

It turns out that I was hooking the login event in slightly different ways and this does seem to effect the order the routines get called in. In the 2-factor module I was doing this...

$this->addHookAfter( "Session::login", $this, 'my2FactorHook', array('priority'=>10));

Whilst in the alarm module I was adding the hook differently...

$this->session->addHookAfter( "login", $this, 'myAlarmHook', array('priority'=>2000));

Switching the 2-factor init() routine over to using $this->session->addHookAfter('login'...) has everything called in the right order.

[ryan]

Glad you got it working. Static hooks ("Session::login") are treated separately from direct hooks. The direct hooks are more specific so they get executed before the static ones. But I wasn't really thinking much about priority level when building this, so not sure if that's the way it should be or not.

[netcarver]

Ok, that certainly explains the result. But it makes me wonder if a unified approach to hooks might be more logical than having a set of static hooks and local hooks unless there was a specific reason for going for two sets?

[ryan]

Static hooks apply to all instances of a class, whereas direct instance hooks apply to just 1 instance (the one you assign it to). For example, you'd use a static hook if you wanted to hook into or add some new method to all Page instances. Whereas, if you are hooking any API variable ($session, $pages, $modules, etc.), it's better to use a direct/instance hook since there is only ever going to be 1 instance of those variables anyway. While you could use a static hook anywhere, direct hooks are a little more efficient because they are stored with the actual object instance rather than in the larger pool of static hooks. Meaning, direct/instance hooks result in less for ProcessWire to sift through when executing hooks (though it probably doesn't matter much in the larger scheme of things). But this is also the reason why they aren't prioritized together, as they are stored in different places.

[netcarver]

Ah, right. I'll just have to make sure I install the hooks consistently next time then.

[adrian]

Just thought you guys might like to know that the priority setting just got another user

Needed to solve the conflict between RedirectIds and 404Search modules.

Thanks again Ryan for thinking of everything!

[BillH]

I thought it might be worth mentioning - given remarks above - that another three years on this feature is still getting new users

This time, it's to fire off my own page-renaming module before the Custom Upload Names module makes updates when the page name changes.

This has allowed the modules to work together really easily and, I suspect, saved quite a lot of hard work!

[paulkoan]

Is it possible to control Processwire hook priorities, other than what the module devs agree on?

For example, I have installed

• Redirects
• 404Logger
• 404Search

The behaviour  I want is:

1. Redirect if possible, else
2. Log page not found, and
3. Do 404 search

The behaviour I have is

1. Log page not found, and
2. Redirect if possible, else
3. Do 404 search

If I could lower the priority of 404Logger, then I guess this would work as I need it to.  I imagine I can modify the module, but I'd want this to be update survivable.

Cheers,

Paul

 

[DaveP]

This might help -

 

[kongondo]

2 hours ago, DaveP said:

This might help -

 

Er, @DaveP, this IS that topic .

[DaveP]

17 minutes ago, kongondo said:

Er, @DaveP, this IS that topic .

OMG! Senior moment. 

[Ivan Gretsky]

As of now I am a user of this feature too) Thanks to @adrian's link.

I did need it to fix this issue. If you read through the linked thread you'll see that I confused module autoload order with hook order. Actually I thought that the module, that gets loaded first, would add the hook first (or last). So the autoload order would affect hook order. I did play with autoload order of the modules without success. Why is it not it the case?

If it was, there could a chance to add an option to override module autoload order in admin, making it adjustable without code hacks , solving this question.