Ce fil est résolu. Voici une description du problème et la solution proposée.
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.
This support ticket is created Il y a 6 années et 4 mois. There's a good chance that you are reading advice that it now obsolete.
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.
Aucun de nos assistants n'est disponible aujourd'hui sur le forum Jeu d'outils. Veuillez créer un ticket, et nous nous le traiterons dès notre prochaine connexion. Merci de votre compréhension.
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
Les langues: Anglais (English )Espagnol (Español )
Fuseau horaire: 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?
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).
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.
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?
Les langues: Anglais (English )Espagnol (Español )
Fuseau horaire: 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.
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:-
Les langues: Anglais (English )Espagnol (Español )
Fuseau horaire: 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
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)?
Les langues: Anglais (English )Espagnol (Español )
Fuseau horaire: 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.
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.
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.