[Resolved] How to send an automatic email when a Custom Field is updated via Dashboard
This support ticket is created 6 years, 4 months ago. 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.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
I have a custom post type "Shipments" for a freight forwarding business.
The default language of the site is English.
The secondary language is Japanese.
The existing workflow is:
a) Create a "Shipment" record in English.
b) Duplicate the custom post to Japanese
c) Edit the 3 or fields of the post that need Japanese e.g. goods descriptions etc.
(most don't require translation e.g. phone number, contact email etc.)
The problem now, I want the customer to receive an email notification whenever the shipment "status" field is updated (In transit, Pending customs, Delivered etc)
We have custom fields for "customer name", "customer email" and a drop down list for "shipment status".
I know that CRED has an option to send an email when a custom field is updated BUT it seems that keeping the two language versions synchronized in CRED is problematic. I think it's easier to do if via the back end and devise a solution for sending an email.
Is there some custom code I can use in my functions.php file to generate the email?
If you create a Form notification which is triggered when a custom field on the post changes value, then that should work irrespective of whether the field value is changed when editing the post in the backend or with a front-end form.
I expect that to trigger the notification the field value would have to change on the post that was originally created with the form, so if you use a form (with notification) to publish an English post, the notification would only be fired when the custom field on the English post is updated.
Does your expected workflow mean that someone may edit the Japanese version of the post and change the shipping status there?
It's like you would need bi-directional syncing of that particular field, so that if the status were changed in either language, then it would be updated in the other. (I think WPML custom field syncing is only one way, but I'll double check.)
I expect that to trigger the notification the field value would have to change on the post that was originally created with the form, so if you use a form (with notification) to publish an English post, the notification would only be fired when the custom field on the English post is updated.
I think we could probably live with that as a workflow rule.
What I'd like to see though, is an email that generates the required fields in both languages
a) So if we create the email notification in CRED and wrap the necessary fields in WPML string tags, that should work?
b) Some of the fields (like description of goods) needs to come directly from the database.
e.g. Its not feasible to create a WPML string translation for every Shipment post - Description field.
e.g.
ENGLISH VERSION: Description of Goods: Lorem ipsum dolor sit amet, aeterno aliquid alienum pro at, eos ea menandri dignissim, vel modus assum mucius ut. Ne mea duis ignota adipisci. Vel ne dicunt iriure, simul neglegentur id ius. Id discere vivendo perpetua cum.
I think a) should work, if you test it and find it doesn't, let me know and I'll establish with the developers what we should and should not expect.
For b) this is tricky.
You can include shortcodes to output fields in the notifications (but for deferred notifications you normally have to add the attribute id="%%POST_ID%%" to make sure the shortcode retrieves the value from the correct post).
So we can output a description field in the language of the post created with the form. If we have the id of one post we can use the wpml_object_id filter to retrieve the id of the same post in another language, so we might be able to register a custom shortcode to provide that id to our Views shortcodes, or failing that output the text from the translated post directly with the shortcode.
I'll need to do some testing, so give me till tomorrow and I'll update you.
I've got things working more or less as I want them.
I have created a custom field "Preferred Customer Language" in the "Shipments" custom post type.
So I think this will allow me to create TWO separate email notifications.
One in English (sent if "Preferred Language == English").
One in Japanese (sent if "Preferred Language == Japanese").
I have made "Shipment Status" as a taxonomy.
It seems like that is the best way to keep the status "synced" between language versions.
So the last big piece of the puzzle is how to pull out the custom post record data for EACH language version.
Currently, when a change is made to the "Shipment" custom post on the backend an email goes out to the customer that looks like this:
Shipment Code: MOXG010718WKB
SHIPMENT STATUS: Arrived at destination
Customer Name: [types field='customer-name'][/types]
Preferred Language: [types field='customer-language'][/types]
Point of Departure: [types field='point-of-departure'][/types]
Point of Arrival: [types field='point-of-arrival'][/types]
Estimated Delivery Date: [types field='delivery-date-estimated-actual' style='text' format='Y-m-d'][/types]
Description of Goods: [types field='description-of-goods'][/types]
So three conclusions:
a) Making updates to the custom post on the back-end DOES trigger a notification email
b) The notification doesn't recognize any of the Types short codes (need to register new short codes??)
c) We need a way to target specific language versions of the "Shipments" post in the notification email template
I mentioned before that with deferred notifications you normally have to add the attribute id="%%POST_ID%%" to make sure the shortcode retrieves the value from the correct post.
However it looks like those types shortcodes are not being parsed at all.
I just set up a test and can confirm that. I added a custom shortcode to the same notification, which was parsed, so there seems to be something broken with the types shortcodes in this context.
I'm escalating this as it needs fixing.
In the meantime, I think if you try outputting the raw field values with the wpv-post-field shortcode it will work (but means the estimated delivery date will be an unformatted UNIX timestamp).
I checked and confirmed that custom shortcodes are parsed okay.
So I think you can register a custom shortcode that uses the id of the post to which the notification belongs to retrieve fields from the translated version using the WPML API's wpml_object_id (see https://wpml.org/wpml-hook/wpml_object_id/).
The queue is extremely busy at the moment so I don't have time to do that for you right now, but if you get stuck I can help after the weekend.
You might need to pass the id of the post the notification belongs to as a shortcode parameter, set with %%POST_ID%%, to have the right context to be able to check what the preferred language is and then retrieve the translation if required.
OK. Thanks.
The second part of your reply was a little over my head but I can wait until early next week.
Hopefully you and and support team will have more time to look at the issues then.
btw "In the meantime, I think if you try outputting the raw field values with the wpv-post-field shortcode it will work (but means the estimated delivery date will be an unformatted UNIX timestamp)."
But there are simple PHP functions to convert UNIX back to human readable, right.
So it just means adding an extra function to convert.
So I think you can register a custom shortcode that uses the id of the post to which the notification belongs to retrieve fields from the translated version using the WPML API's wpml_object_id (see https://wpml.org/wpml-hook/wpml_object_id/).
If you can offer some assistance now, it would be appreciated.
I should point out that there are TWO different email notifications.
One is being sent in English.
One is being sent in Japanese.
There is a filter in the email notifications which only sends the email if the "preferred-language" field matches.
BUT the challenge is still to extract the correct language version for each email, using perhaps a custom short code as you have described.
First, the issue with the types shortcodes not being parsed has been fixed with a minor Types update to 3.0.6 today, if you want to go ahead and upgrade.
Your last comment threw me slightly, "there is a filter in the email notifications which only sends the email if the "preferred-language" field matches".
The notification setting for custom fields is to trigger a notification when the value of a custom field has been changed to match a target value, which is how you are using it for the shipment status, but isn't what's required to determine whether to send an English or Japanese notification.
I have several ideas about how to proceed, and I'm just discussing with the developer who recently updated the notifications code about which one might work best.
I'll update you when I've managed to test a solution.
OK. I updated Types.
It's looking great and works great (up to a point).
Shipment Code: MOXG010718WKB
SHIPMENT STATUS: Inland transport
Customer Name: E-Corp
Preferred Language: English
Point of Departure: Yokohama
Point of Arrival: Sydney
Estimated Delivery Date: 2018-08-24
Description of Goods:
Various food products.
As you can see, the post has a custom field for "Preferred Language".
This notification sends the shipment data as it exists in the WPML "English" version.
See the notification parameters screenshot.
I want to copy the notification but change the parameter from
"customer-language=English" to "customer-language"=Japanese.
So there will be two notifications.
BUT each notification will only fire if the language parameter is TRUE.
Waiting for your advice on the best way to "pull" the correct language version for each notification email.
I should point out that "SHIPMENT STATUS:" is a taxonomy field, not a custom post type field.
This needs to be in the correct language version, of course.
I checked in with one of the developers to see if I might be missing something, a filter I'm not familiar with for example, that would help with the implementation, and after about half an hour he came back and said what you want isn't possible 🙁
I think we can probably craft something to get it working, but I need a little more time.
I'll get back to you before too long with my thoughts.
I've discovered something else of "interest".
Not sure if this should be a new ticket thread?
First I create a new shipment record in the back-end, duplicate it to Japanese, change a couple of fields from English to Japanese and save. So far, so good.
Next, if I go into the back end and change any of the custom fields (or taxonomy), nothing happens - no email notification is sent.
HOWEVER, if I look at the Shipment record in a CRED form, change ANY field and save it - an email is sent.
THEN, from that point, any further changes to the Shipment record via the back end ALSO generate an email!
It is as if the action of saving the record JUST ONCE via CRED somehow "registers" that custom post record for future email notifications.
Is this the way TOOLSET is meant to behave? Seems a bit janky.
Not sure if this is a new behavior introduced by the recent TYPES update.
I would like ALL updates made to the back end to fire an email after the custom post has been created.
That seems like a more logical behavior.
Alternatively, give me a way via CRED to make changes to the Shipment record in one language and have those fields "synced" via WPML into the other language where appropriate.
Regarding your last update, I think the problem is that you are expecting the notifications of a CRED form to be active even for posts that you don't create with that form (i.e. posts that you publish in the back end).
The notifications will be generated (even if they are deferred notifications to be sent at some point in the future) only when a post is created via a form that includes notifications. Or, in your example, it starts working once a post has been edited by a form that includes notifications.
You shouldn't expect CRED notifications to work on content that isn't created by CRED.
I'm about to take another look at the original issue and I'll get back to you about that.
