Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
If you create a paid event webform with an email component (e.g., creating an email field in the webform to use as an address to send a confirmation) that email is sent immediately upon adding the event to the cart. Wouldn't it be better to delay that email and wrap it in with until the conditional action that's fired to update the order status to paid? I dug around in webform but can't figure out where those emails are triggered and, even if I could find it, I'm not sure I would know how to delay the process or add it to the action. So, I figured a feature request was my best bet.
Thanks!
Comments
Comment #1
Saoirse1916 CreditAttribution: Saoirse1916 commentedI've got a workaround solution to this which involves hacking webform.module, so if there comes a patch for UC Event Registration, I'm definitely in for that.
If anyone wants this feature in the meantime, here's the workaround:
At line 2202 of webform.module disable the default auto email submission for paidevent forms -- change this:
To this:
Then, in uc_event_registration.ca.inc you'll need to add in the proper actions to the conditional event. Change this (line 48):
To this:
Now you need to modify the hook_ca_action() function to include the new action that you just created. So in the same file change this:
To this:
The last change is at the very end of the file, create the function to actually do the work:
Now, in /admin/store/ca you'll need to apply the new action to the existing predicate. Click edit next to the Mark Event Registrations as paid predicate, click the actions tab, find your new action in the Available actions drop down list, then click Add Action. That should do it.
Again, if there's a less hacky way to do this, I'm certainly game but this was fairly critical for my project as the client was using these email confirmations as temporary tickets which granted customers access to events. Sending them out before payment was processed would be a big problem in this case.
Comment #2
AndyF CreditAttribution: AndyF commentedWhat I did was just to not use the webform mailer if I didn't want an 'early' email, and instead used ca to send the email on checkout completion. Would that pose any problems in your situation? (The only example I can think of is if you needed to use webform component values in your email, or if you've opened up webform to the client but are keeping ca closed.)
Comment #3
Saoirse1916 CreditAttribution: Saoirse1916 commented@AndyF: I initially had it set up that way but my client definitely wanted all the webform fields in the email, so the customer now gets two emails, one from webform and one from ubercart. That's not ideal but not really a big concern as that happens a lot on e-commerce sites.
Comment #4
AndyF CreditAttribution: AndyF commentedI'm with you. So the appropriate 'nice' solution to your problem would be to expose the webform fields as tokens in ca? (But this wouldn't please people who wanted to let their clients create arbitrary email messages via webform and have it send only on payment.)
Comment #5
Saoirse1916 CreditAttribution: Saoirse1916 commentedYeah, exactly -- I spent a bit of time looking down that route but I like how customizable webform's email confirmations are. In my case I'm using this module not just for event registrations but for memberships and education programs as well. To the module the type doesn't matter of course but those are all distinct departments at the client and they want control over what the confirmations say. As a result, I couldn't rely on a single email coming from ca, though adding webform token support would probably work for a lot of people.
Comment #6
AndyF CreditAttribution: AndyF commentedGotcha, it would be a nice feature. I think we could do it by storing the nid and eid of emails that need sending later, and modify #node on the webform load to remove those emails. Then just use a ca action to send the mails on checkout completion or whatever.
Comment #7
Saoirse1916 CreditAttribution: Saoirse1916 commentedMakes sense, though I didn't know you could modify #node to prevent the auto-submission -- would that be through hook_form_alter or something else?
Comment #8
AndyF CreditAttribution: AndyF commentedI've added the feature to -dev: please test. If you edit a paidevent email you should see a new setting for sending either on webform submission or completing checkout. The email sending's done using your action, and by default it's done at the same time as the webform submission's marked as paid.
Note that currently if you have a paidevent configured with 'late' emails, and you then decide to reconfigure them to send on webform submission, then any customers who have already submitted the form for that product but who haven't completed checkout will never get those emails.
@Saoirse1916 Yeah, through
form_alter
as webform does the sending from its submit handler, which in turn pulls the node from$form['#node']
. Thanks for the code!Comment #10
K.MacKenzie CreditAttribution: K.MacKenzie commentedFirst off, thanks for this awesome module and very useful improvement to the dev version, really saved me a lot of time here.
Looking for this feature myself I stumbled upon this thread. After switching from the 1.3 to 1.x-dev version and trying out this new functionality it appeared to not work.
After re-reading this thread I noticed that you said "The email sending's done using your action".
I realized that the function uc_event_registration_send_webform_emails in my case was never being fired, because I had no conditional action to fire it. After digging throught he code I realize I just had to create the CA to fire it in ubercart... no problem.
A very nice and probably easy improvement would be to automatically create the "fire late emails" CA upon installation just like the "mark webform as paid" CA. Or at the very least put a note under the option on the emails form under the "on completed checkout" select to remind the user that the CA also has to be created in order for it to work.
Thanks again!
Comment #11
AndyF CreditAttribution: AndyF commented@Vandrico Sorry for the delay, and yeah it looks like you're absolutely right! I'm very busy at the mo, but will see if I can't slip the fix in over the weekend as it is so small.
Thanks for reporting it.
Comment #12
AndyF CreditAttribution: AndyF commentedSorry, very long delay there! The predicate's now in dev.