Problem with timing of EventPostSaveFilter delegate
This is an open discussion with 2 replies, filed under Extensions.
Search
Isn’t an entry supposed to be saved or not, depending on the filters (like the Send Email filter)? “Post save” should mean that it has been saved (i.e. it has “passed” the filters).
BTW: I am always confused by the explaining text in the backend: “This event will not be processed if any of these rules return true.” Is this correct at all? Isn’t it “…if any of these rules return false”? Does anybody know this (so I don’t have to check it out…)?
“This event will not be processed if any of these rules return true”
That language is clearly wrong, and seems to be a holdover from a time when Event Filters were conceived as something different than what they are today (Allen, maybe you can confirm that?)
At the moment, Event Filters are a varied bunch, and include not only trigger conditions (admin only) but event options (allow multiple) and trigger actions (send email) as well. The language used only applies to trigger conditions, and even then it’s wrong :P
I’m not sure what we replace it with except for something very general like:
“Add trigger conditions, options, or actions to this event.”
I’ll flag this up for the UX working group to look at.
Create an account or sign in to comment.
Is there a specific reason that the
EventPostSaveFilter
delegate (inevent.section.php
) calls the registered finctions after any possible emails are sent from the Send Email filter?I ran into some problems because the Send Email filter modifies the
$fields
array that is part of the$context
array which gets passed to any functions called by theEventPostSaveFilter
delegate. Putting the corresponding code before the Send Email code fixes the problem but I’m wondering if there are any side-effects.