Hi Christian,
No, the user page still has not crashed ever since that last message that you are referring to. I'm not sure if the random e-mails are still an issue either. Would you recommend we split the ticket? The other issue is still happening, where it's sending the notification of one form when submitting an unrelated form:
https://toolset.com/forums/topic/forms-notification-causing-edit-user-page-to-crash/#post-911487
It was the same notification that caused the user page to crash before, but the symptom seems to be different now.
- Aaron
For reference:
One more addition to note here: I've noticed e-mails coming erroneously from a third form now. The form "Form-Member-Profile-Edit" has zero notifications assigned to it yet whenever I submit the form I receive an e-mail notification that was setup in the form "Form-Member-Connection-Edit".
A couple of things I see here.
1: This checkbox is set to save "0" when not checked. I want to warn you that this is bound to cause problems. Avoid saving 0 if unchecked if at all possible. Please see this related erratum: https://toolset.com/errata/checkboxes-that-save-0-are-interpreted-as-checked-by-views/
2: Form notifications seem to be triggered incorrectly by submitting other forms. I'm escalating this to my 2nd tier support team because I'm able to replicate it on my own local environment. I'll update you as soon as I have more information about this.
Noted on the saving zero thing. There was only one post type where I did this and I will go in and remove this since it didn't seem to be saving the zero when un-checked anyways.
- Aaron
Okay first of all thanks for your patience, and I have some clarification from my 2nd tier support team on this. When a form notification trigger is set to "when a custom field is changed", then it does not matter which form triggers that change. Any change from another form will trigger this notification. I was under the impression that the change had to be triggered by the same form that holds the notification, but that is not the case. So it seems that this is the expected behavior. If you'd like to request a change, feel free to create a new Feature Request ticket and we can evaluate your request for feasibility.
Hi Christian,
Thanks for clarifying - that's good to know. Even given that though, the two forms are modifying completely different custom post types. How would a change to one trigger a notification related to changing the other?
- Aaron
Custom code triggered in a cred_save_data callback could cause this. If you call add_post_meta or update_post_meta on a Member Connection post in a cred_save_data callback for another form, you could trigger a notification based on the custom field's value. At first glance I see at least one callback for Form 702 in Snippets, but I didn't look through all of them.
Hi Christian,
Sorry, just now getting back to this after being away all week at an event (launching the site!). Just tracing my steps through this:
1) Submitting form 702 from /private-page/my-profile/edit-my-profile/ results in my receiving two e-mails, one saying I have a new friend and the other saying I've been vouched for.
2) The two notifications that trigger those two e-mails are on form 1207. The new friend notification is currently set to e-mail me (hard-coded e-mail) when the wpcf-connection-friend value = 1, but only when the field value has changed.
3) The vouched notification is currently set to e-mail an address set by a field on that form when the wpcf-connection-vouch value = 1, but only when the field value has changed.
4) Searching my snippets for form 702 events finds the following code:
add_action('cred_save_data','be_updateprofileid',10,2);
function be_updateprofileid($post_id,$form_data) {
if ( ($form_data['id']==700) OR ($form_data['id']==702 ) ) {
$userid = get_the_author_meta('ID');
update_user_meta($userid, 'wpcf-user-profileid', $post_id);
be_update_connections($userid);
}
}
6) Looking into the be_update_connections() function shows that it does modify the connection post (modified by form 1207), but nowhere does it modify the wpcf-connection-friend value or the wpcf-connection-vouch value. You can check that code here: admin.php?page=edit-snippet&id=14 (would rather not paste all that code here).
7) Searching for 1207 in snippets yields no results.
8) Disabling the be_update_connections() function stops the notifications from sending, so the issue is likely coming from this code.
From this, it would seem that because be_update_connections() is updating the same post modified by form 1207, that this custom code is likely triggering the notifications to fire. However, what I don't understand is that the notification is set to only fire if specific fields are modified, and those fields are not modified by the custom function.
Any thoughts on this? If there is some limitation in the Toolset functionality on conditional notifications then perhaps I will just delete the notifications and find a way to do it in the cred_save event.
- Aaron
I think your code looks good. Our developers are aware there are some issues with notification triggers based on comparing custom field values. The behavior of these notification triggers is inconsistent, and we have a ticket in place to improve the reliability of this feature. I will attach this ticket to the internal bug tracker so I can update you when these improvements have been implemented.
Hi, Forms 2.0.2.1 has been released, and includes several improvements to the custom field value-based notification system. Please update to the latest plugins and let me know if you continue to experience problems triggering notifications based on custom field values.
Looks like the problem has been resolved. Thanks.
- Aaron