Posted: May 28, 2020 at 10:35 am
1. What’s the best way to generate an email to an administrator when someone joins an event wait list?
2. Is there any way to set the bcc of (any) email?
The actual problem:
The concept of a “system trigger” could be very useful.
But I can also think of many uses for BCC that would cut down on the number of emails we send and protect certain internal email addresses from being exposed to outside parties.
Similarly, I’m bummed ‘wait list’ triggers have no option for Sending notice to “Event Admin” because that would tremendously useful for situational awareness.
Thanks in advance, Thanks for listening and stay safe.
Currently, you can’t, not easily at least as you’d basically need to hook in an trigger your own message.
There are a number of ways to accomplish this using standard WordPress hooks on the wp_mail() function. This is a well-written tutorial that shows one way:
Can you provide some details?
For many/most of the messages available within EE there is an ‘Event Admin’ context, which is a separate message sent to the event admin and the email address set there is not visible to the registrant so can that not be used for this already?
I agree with this and have created a ticket to investigate adding the additional context, there may a reason it wasn’t included originally.
“But I can also think of many uses for BCC that would cut down on the number of emails we send and protect certain internal email addresses from being exposed to outside parties.”
‘Can you provide some details?’
Sure. Our host traditionally had troubles sending out emails so the bcc allows us to confirm emails are still getting regularly sent out. The context is nice, but it’s also nice to see exactly what our students are receiving. We don’t have tons of students so it wouldn’t be overwhelming and we can review the info being sent out without having to login to the WP dashboard.
In addition, since certain contexts are missing for certain message types, the inclusion of bcc effectively circumvents that by allowing us to receive what our students receive without having to login to the WP dashboard. Like Wait List. If we had a bcc function available, then the presence of the Event Admin as a context would, for us, be irrelevant since we are being notified via email that someone had signed up/demoted/promoted.
So BCC acts like a de facto back door update on all outgoing communications. A teensy bit of a hack maybe, but easier also to grasp than “context” vs “registrant” vs “primary registrant” which are confusing concepts to me. I understand these now, but in between updates I forget and have re-study them. “Global template” is a good name. “Event admin” is a good name. “Contexts”… hmmm. Naaaah. It’s confusing and the dashboard interface doesn’t help much so this spills over into a UX issue as well.
The bcc thing solves all that because it just lets me be an invisible recipient experiencing what the user experiences. Barring that, having the ability to edit contexts, or having a IFTT kind of access to triggers would be amazing because I could then use a simple logic to branch out and offer the user a conditional discount, an upsell, a coupon, an invitation to the next event with tags that closely match, an apology, a quiz, etc.
Understand, I like the product(s) overall and the messaging system works so hopefully this is taken less like complaining and more like wishful thinking. Keep up the good works.
One of the biggest complaints/gripes/dislikes we had from EE3 was the number of emails sent to both the registrant and the admin and not having the ability to each every. single. email EE sends. So we took that on board and designed the messages system to be as flexible as we could with control over the Event Admin, Registrant and Primary registrant (because some users want to separate that email out) both in content and sending the email itself.
Other than a request for a CC option I think you’re actually the first user (at least the first I can remember) to request more emails from Event Espresso.
I think I misunderstood your initial request as I thought you wanted a BCC option enabled on each message type and context (similar to the current CC option) so it can be set independently but it sounds like you just want a BCC of EVERY email and you can do that easily with a custom function outside of Event Espresso.
All emails are password to wp_mail() so a snippet to add a BCC email to every email canbe done using the filter within that.
We don’t have plans to add a BCC option added to every message within EE at currently and that is mainly due to #1 of my reply here.
I agree here, the messages system has a steeper learning curve than most of the system, but it also has the most flexibility. It is difficult to balance that flexibility and provide a simple UI here.
‘Global template’ in what respect though, a single template can be used in multiple ways and not everyone wants a simple copy of what the registrant received.
Event admin, is a context in EE so I don’t follow. How else would you prefer we display these options? We couple split contexts into their own items in the message list but you then go from 20ish templates (with contexts in each) to at least double that but I don’t think it’ll help.
If we remove contexts how do we then handle the users that want separate emails for event admins?
Using BCC vs ‘contexts’ in this case limits the emails to a single admin/group etc. If you disabled contexts and use BCC for all emails you then can’t have individual event admins receiving ‘their’ emails etc. Well, you could, but again with more custom work and specific email BCC’s etc.
Yeah an integration with IFTTT, Zapier would be awesome, I can’t say we’ll have anything soon but we’ve discussed this a little previously.
Any and all feedback is appreciated as we can’t make changes if we don’t know the pain points. I’d love to make changes to the messages system but right now I can’t think of a way to provide the same amount of flexibility it has with a ‘better’ UI.
Thanks for taking my comments seriously. I think I lost the plot a little and mixed metaphors and it all got confusing so I’ll take it back down to simple…
Nothing wrong with ‘global templates’ it was just an example of part of the message system with a name that made sense and doesn’t really have to be explained.
The message system works really well when setup right and so I don’t do much to it or with it for long periods of time, during which I forget the ‘nouns’ and ‘verbs’ of the system (prompting re-study).
One way to address this might be to recognize the challenging stuff like the term ‘contexts’ and the several little intimidating windows that make up a message.
Two UX things that would help a lot are:
2. Adding a header or sidebar with a dynamic “crib” sheet that shows what is going to happen in plain English based on the current settings of the message being edited. Alternatively, maybe a popup helper that gives gentle, fade-away on it’s own and doesn’t get in the way kind of response feedback when you hover over confusing bits.
3. Showing a preview using a live or simulated target. I dig the cute sci fi references in the outgoing test emails, but nothing compares to being able to experience a specific, real case of data.
If I’m the only one squawking, then either I’m weird or just have unique circumstances I guess.
Anyway, this is mostly for the sake of conversation. The core and only real problem we face is having an automated push-type notification indicating new wait list additions. It’s important and timely data for us and any solution that precludes our having to manually monitor that situation would be a positive thing.
Thanks again for listening.
Thank you for the feedback, whilst we can’t take on switching out the message UI right now I’ve noted your feedback for future reference.
However, I just wanted to let you know that I’ve added the Event Admin context to the waitlist message types which is currently under testing and if no issues are found will be released in the next update to the add-on.
The event admin context will likely be disabled for all of the waitlist message types by default but can be easily enabled.