Startseite › Toolset Professional Support › [Gelöst] Which CRED API hooks execute last?
Problem:
Client is sending a notification and needs to update the post after the notification has been sent, and wants to know which are the last hooks that can be used.
Solution:
In reverse order:
cred_success_redirect
cred_mail_header
cred_notification_recipients
cred_submit_complete
cred_save_data
Relevant Documentation:
https://toolset.com/documentation/programmer-reference/cred-api/
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
- | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | - |
- | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | - |
Supporter timezone: Europe/London (GMT+00:00)
Verwandte Dokumentation:
Dieses Thema enthält 20 Antworten, hat 2 Stimmen.
Zuletzt aktualisiert von julieP vor 6 Jahren, 5 Monaten.
Assistiert von: Nigel.
If I add a cred_submit_complete hook to a post form, are the email notifications executed before or after the hook action is executed? In other words is the order of events:-
1. form submission
2. form data saved to d/b
3. notifications sent
4. cred_submit_complete hook is executed
OR
1. form submission
2. form data saved to d/b
3. cred_submit_complete hook is executed
4. notifications sent
Thanks
Sprachen: Englisch (English ) Spanisch (Español )
Zeitzone: Europe/London (GMT+00:00)
Hi Julie
Logically I think the notifications would not be triggered until the submission is complete, but in any case I ran a test with the following code:
function cred_submit_complete_timestamp( $arg ){ error_log("cred_submit_complete: " . microtime() ); return $arg; } add_filter( 'cred_submit_complete', 'cred_submit_complete_timestamp' ); function cred_notification_recipients_timestamp( $arg ){ error_log("cred_notification_recipients: " . microtime() ); return $arg; } add_filter( 'cred_notification_recipients', 'cred_notification_recipients_timestamp' );
The results of that were
[27-Jul-2018 08:00:27 UTC] cred_submit_complete: 0.96998300 1532678427 [27-Jul-2018 08:00:27 UTC] cred_notification_recipients: 0.97919200 1532678427
That confirms the cred_submit_complete hook triggers before the notifications are prepared.
Hi Nigel
Many thanks for this.
Is there a way of changing the order or including a delay to the cred_submit_complete hook so it triggers AFTER the notifications are sent?
Thanks
Sprachen: Englisch (English ) Spanisch (Español )
Zeitzone: Europe/London (GMT+00:00)
Not without rewriting the plugin.
It is logical that the notification isn't sent until after it is confirmed the post was submitted.
You might have a use-case where you require something different, but I'd say that was exceptional.
Is it just the case that you have some code that you run with cred_submit_complete and you want that same code to run when the notifications have been sent?
Can't you just move the code to the later notifications hook?
Hi again
Just to clarify, there is NO notifications hook, only a cred_submit_complete hook which needs the form notifications to have been sent before it triggers. I tried this out a few months ago and it worked but it's not working now! There's obviously been a code change somewhere.
I do agree with you that logically the notifications have to be sent after the form data has been saved but (to me anyway) logically the cred_submit_complete hook should be the very last thing that fires (because then everything required of the form will have been completed).
I actually want to use this to remove an email address from the database provided on a contact form (for GDPR purposes). If the hook ran last (which it used to), it would work as required (the email address for correspondence purposes would be included in the notification and that is then easily deleted at the appropriate time via my inbox and no further action/housekeeping required on the database).
Can you put forward a change request please?
Sprachen: Englisch (English ) Spanisch (Español )
Zeitzone: Europe/London (GMT+00:00)
You could try the cred_notification_recipients filter.
https://toolset.com/documentation/programmer-reference/cred-api/#cred_notification_recipients
The post id is available as one of the arguments, and we know the post has already been saved, so you could delete the post meta for the email custom field.
Will the email notification still work? I think so, because the $recipients argument has already been constructed with the target email address and I wouldn't expect the notifications code to retrieve the same address a second time.
Give that a go and let me know if it works or not.
Hi Nigel
I'm lost! How do I convert that hook into what I need? My current cred_submit_complete hook looks like this:-
add_action('cred_submit_complete', 'after_save_data_form_37',10,2); function after_save_data_form_37($post_id, $form_data) { if ($form_data['id']==37) { update_post_meta($post_id, 'wpcf-email-address', ''); } }
Sprachen: Englisch (English ) Spanisch (Español )
Zeitzone: Europe/London (GMT+00:00)
Hi Julie
This should do the same, but using the cred_notification_recipients filter:
function tssupp_blank_email_address( $recipients, $notification, $form_id, $post_id ){ if ( 37 == $form_id ) { update_post_meta( $post_id, 'wpcf-email-address', '' ); } return $recipients; } add_filter('cred_notification_recipients', 'tssupp_blank_email_address', 10, 4);
That's awesome Nigel, thank you! I'd never have got there on my own.
I'll give it a go and report back if I have any issues.
I did look into running a CRON job to do the update; the downside is that the update wouldn't happen immediately. That aside, in your opinion, which would you say is the better approach in terms of server load or the hook ceasing to work at any point due to code changes via plugin/core updates?
Sprachen: Englisch (English ) Spanisch (Español )
Zeitzone: Europe/London (GMT+00:00)
Hi Julie
Setting up a CRON job seems like overkill, and any Toolset changes to the CRED API should be backwards compatible, and if you find otherwise you can reasonably expect that to be fixed.
OK thank you.
I have, in the meantime, tested the cred_notification_recipients filter but I'm afraid the database was updated before the cred notifications were sent.
I don't know if it's relevant but out of curiosity, I ran your error log test (second thread in this ticket) but only this was returned:-
[30-Jul-2018 15:14:54 UTC] cred_submit_complete: 0.22215100 1532963694
yet both notifications were sent & received as intended.
Any ideas?
Sprachen: Englisch (English ) Spanisch (Español )
Zeitzone: Europe/London (GMT+00:00)
Hi Julie
Let's go back to what you are actually aiming to do.
You want users to use a contact form where they supply their email, they receive a message at that email address (the form notification), and their email address is discarded, is that right?
In which case I would:
- set up the contact form to include a generic field to gather the email address (so that it is not stored in the database)
- set the notification to send to some email address (e.g. site admin)
- use the cred_notification_recipients to get the user's email address from the $_POST object and change the To: header to use this email address instead of the address set in the notification
So you could that with the following:
function tssupp_custom_form_recipients ( $recipients, $notification, $form_id, $post_id ){ if ( 148 == $form_id ){ if ( isset( $_POST['email-to'] ) ) { $target = $_POST['email-to']; $recipients[0]['address'] = $target; } } return $recipients; } add_filter( 'cred_notification_recipients', 'tssupp_custom_form_recipients', 10, 4);
You'll need to edit the form id, and in this example the slug of the generic field I use to gather the email address is "email-to".
Hi Nigel
You want users to use a contact form where they supply their email, they receive a message at that email address (the form notification), and their email address is discarded, is that right?
Almost! All of that but the body of the emails to me and the user need to contain the email address they provide (I'm currently capturing this via the custom field) but the whole thing needs to apply to 3 other custom (non email) fields too.
The aim at the end of the day is to not save the 4 bits of personal data to the database and for it to only appear in the emails when the form is submitted. That way I only have to delete the email to be GDPR compliant and not have to carry out any retrospective housekeeping on the database.
I like your approach and I'll have a go but before I do; if I have 4 generic fields on the form in place of the Types custom fields, how do I get those field values into the body of the emails (if that's not a daft question)?
Thanks
Sprachen: Englisch (English ) Spanisch (Español )
Zeitzone: Europe/London (GMT+00:00)
Not a daft question. You can't.
So... we might have to go back to the drawing board.
Actually, we were using the cred_notification_recipients filter.
I tested that myself and confirmed that, although the email address field was used to set the To: address, including the email field in the message body didn't work, deleting the post meta seemed to happen before the message body was constructed and the field appeared blank.
However, I tried again with the cred_mail_header filter and it looks like this filter is applied later, late enough to work.
So this was my code:
function tssupp_blank_email_address( $headers, $formid, $postid, $notification_name, $notification_number ){ if ( 6 == $formid ) { update_post_meta( $postid, 'wpcf-client-email', '' ); } return $headers; } add_filter('cred_mail_header', 'tssupp_blank_email_address', 10, 5);
My test posts included the Types email address field in the notification (in the To: field and in the notification body), but when I edited the message post which had been created in the backend I saw that the email field was empty.
Can you please test yourself and confirm?
ooh that's working much better, thank you, and we're almost there!
My form is set up to send an email to the post author using the 'email specified in a form field' (which of course is the email address we're removing from the database). That email isn't being sent (the one to me as a wordpress user IS being sent). Do we need something else in here to cover this bit?
It's not a deal breaker if the email to the post author can't be sent with this set up; I feel it's a good move from a customer service point of view but my world won't fall apart if it can't be achieved.