Is there a specific reason that the EventPostSaveFilter delegate (in event.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 the EventPostSaveFilter delegate. Putting the corresponding code before the Send Email code fixes the problem but I’m wondering if there are any side-effects.

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.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details