Phil Cox asked 4 weeks ago
Hi,
I have a form set to NOT save entries. The form lets the user select one or more options in a checkbox field.
An entry is created for each selected option by custom code based on https://formidableforms.com/knowledgebase/frm_after_create_entry/#kb-create-an-entry-in-another-form. (see below for code).
When I hit "submit", an email is correctly generated showing the selected option.
However, it first sends an email with no selected option.
Please could you help me pin down where this initial incorrect email is being generated?
Thanks,
Phil.
Copy of code:
add_action('frm_after_create_entry', 'create_multiple_entries_in_waitlist_form', 30, 2);
function create_multiple_entries_in_waitlist_form($entry_id, $form_id){
if ( $form_id != 53 ) {//Change 53 to the Waitlist form ID
return;
}
$user = $_POST['frm_user_id']; //from https://formidable-masterminds.com/use-frmentry-create-with-dynamic-fields/
//Read Waitlist form "Multi_Events" field into an array.
$multi_events = $_POST['item_meta'][1186]; //Change [1186] to the ID of the "Multi_Events" checkbox field in the Waitlist form.
foreach($multi_events as $event_name_option) //loop over event_names
{
//Create entry
FrmEntry::create(array(
'form_id' => '53', //Change to the Waitlist form ID
//'frm_user_id' => $user,
'item_meta' => array(
// list below all fields to be copied to multiple entries. destination => source
748 => $_POST['frm_user_id'], // Unsure why it is necessary to write this to a field in addition to passing it as a setting above.
725 => $event_name_option, //event
952 => $user ."-". $event_name_option, //prevent duplicates
),
));
}
}
Phil Cox answered 4 weeks ago
Hi Michael Clark, and thank you for your response. I can no longer see it in this post (possibly removed??). I have checked the actions & notifications and they look good. I have a simple confirmation message (which I note is not being displayed) and a single email triggered when entry is created.
Upon further reflection, I see things are out of order and possibly recursive. In a filter for "after create", you're checking for a form ID and then creating an entry on that same form ID. I changed up the code, so it keys off the action of the main form and then creates entries on the waitlist form as needed. It uses the frm_pre_create_entry filter, which is called, even though the entry is never created. See code here.
Thanks Rob, that is already looking tidier!
I think I should expand on my explanation to resolve the "main form/waitlist form" thinking.
The waitlist form [53] displays a a bunch of options and the user selects one or more options then clicks submit. The waitlist form must then save one waitlist entry for each selected option. This is non-standard behaviour, so I activated "do not save entries" and added the snippet to save multiple waitlist entries. Hope this clarifies.
Re saving the user ID, this IS for the current user. Does this reduce the need to save a value for user ID?
Very many thanks,
Phil.
Oh, tangled web you weave! Here's how I'd handle it (keep in mind, I'm not saying I'm right and it's the best way).
1. Disable the email notification in the form.
2. Uncheck the option "Do not store entries submitted from this form"
3. Create a hidden field in the form and call it "user created" or something similar. Set its default value to Y (for Yes).
4. Let's go back to using the frm_after_create_entry filter. In it, do the following:
4a. Only deal with entries from the waitlist form
4b. Create a new entry for each option, setting the hidden "user created" field to N
4c. Programmatically trigger the disabled email notification
4d. Delete the submitted entry
5. See here - https://paste2.org/m76nJUZX for example code
And yes, you're correct that you don't need to set the user ID if the current user is the one creating the entries
Thanks so much for this, Rob! It looks like my approach based upon the Formidable Forms code was wildly out! I'm travelling and will have a go at building and testing this approach in the next few days.
Can we leave the question open for the time being?
Thanks again.
It just hit me that I overthought the issue, so here's my "final" suggestion and it's a dramatic simplification of the previous suggestion. Don't disable the notification and just use the value of the new hidden field to set conditional logic on the notification.
1. Create a hidden field in the form and call it "user created" or something similar. Set its default value to Y (for Yes).
2. Set conditional logic on the email notification to only send when the "user created" hidden field is N.
3. Uncheck the option "Do not store entries submitted from this form"
4. Go back to using the frm_after_create_entry filter. In it, do the following:
4a. Only deal with entries from the waitlist form
4b. Create a new entry for each option, setting the hidden "user created" field to N
4c. Delete the submitted entry
5. See here - https://paste2.org/OYBEdta6 for example code
Thanks so much, Rob. That cracks it!
Observations:
1. Now that we are triggering the email programmatically, it doesn't seem to matter if it is enabled or not.
2. The user ID field IS essential (748 => $_POST['frm_user_id']) so that we can lookup the user's first name, last name, email address. If we don't save the user ID as a field, and instead only save it as the "created by", I can't see how to lookup that info. Is there a better way?
3. The confirmation message isn't appearing. 😕
4. Under "// trigger the notification email", how to modify this to to multiple actions? I have a number of emails set up to be sent.
5. It's definitely running faster so very many thanks!
6. Updated version of the snippet: https://paste2.org/BdCfIZ2W
I think you missed my reply to my own comment that started with "It just hit me that I overthought the issue". Regarding the original issue, you shouldn't need to programmatically fire the emails. If they're enabled AND you're firiing programmatically, then each one should get sent twice. If you really do want to do it programmatically (which I doubt you do), you can make an array of the action IDs and loop over them, assuming they're on the same form. I think I'm going to have to leave it here, unless you want to hire me to complete it.
Thanks Rob, I had confused your last 2 replies. All working fine now using multiple built-in notifications and NOT firing programmatically. Notifications are going out the correct number of times! Thank you for all your help.
Please login or Register to submit your answer
Staff replied 4 weeks ago
A few questions:
1. Is the email notification associated with the manie form or the waitlist form?
2. Have you put debugging code in to see what the value of $multi_events is?
3. Is there an entry being created with no value for field 725 (i.e., $event_name_option is null)?
Other things of note:
1. I suggest using logic other than "if ($form_id != 53)" because your code will be called and likely error out for every form other than 53. So it's more likely you want "if ($form_id == )"
2. It's possible that if only one event is selected that the value in $_POST['item_meta"[1186] will not be an array, which would cause the subsequent code to fail. I'm not sure, but it's worth checking.
replied 4 weeks ago
Thanks Rob.<br />
1. The email is associated with the Waitlist form.<br />
2. No I hadn't. Thank you for the suggestion. I have added print_r($multi_events); and I get the following output: Array ( [0] => November [1] => December ) Array ( [0] => November [1] => December ) Array ( [0] => November [1] => December ) </p>
<p>I can't work out why it outputs it 3 times as this is outside the foreach loop. But the values are what they should be so that has been useful confirmation. I also tested this when selecting only 1 option and the print_r outputs 2 times: Array ( [0] => November ) Array ( [0] => November ) .</p>
<p>3. No there isn't. Please see attached screenshot of all entries for all forms. The only entries are my test entries on the Waitlist form.</p>
<p>1. Thank you. I've made that change. No change in behaviour.<br />
2. Tried selecting 2 options and there is an additional (unwanted) email generated for each selected option.