[Resolved] How to send an automatic email when a Custom Field is updated via Dashboard

[Author]

Posts

[PaulS4783]

OK. Fair enough.

[Nigel]

Hmm. I just submitted a lengthy reply but it seems to have got lost, let me try again.

I have a solution for you.

You need to register the following custom shortcode, editing it for the custom field for the preferred language ("wpcf-customer-language") and the slug of the shipment post type ("shipment"). You also need to register the shortcode for third party shortcode arguments at Toolset > Settings > Front-end Content.

/*
 * Custom shortcode trid to provide translated post id if required
 */
add_shortcode( 'trid', function( $atts ){

	$pid = $atts['pid']; // post id of post that triggers notification

	// Get the preferred language
	$lang = get_post_meta( $pid, 'wpcf-customer-language', true );

	$trid = apply_filters( 'wpml_object_id', $pid, 'shipment', TRUE, $lang );

	return $trid;

});

Your workflow must include publishing the shipment post in English with a CRED Form that has the required notification (to be sent when shipping status is updated). The form needs to include a customer language field as referenced in the custom shortcode, and it is important that the values stored by this field are the two-letter language codes. On my Spanish test site this is a radio button where the stored values are 'en' or 'es'.

In the notification you can use wpml shortcodes and String Translation to make translations of static texts available.

For dynamic texts from Views shortcodes you need to specify the id attribute which will be provided by the custom shortcode, like so:

[wpv-post-excerpt id="[trid pid='%%POST_ID%%']"]

The custom shortcode needs to be passed the id of the post which triggers the notification (using the %%POST_ID%% placeholder) because this is a deferred notification.

I didn't include any kind of error catching (if there is no translated post, for example) and you may want to improve upon that code.

[PaulS4783]

OK. Maybe that will work for me.
Will try it tomorrow.

I have one request though (and maybe the WPML guys know more about this).
When I create a Shipment post in English using CRED, could it automatically "Duplicate" the post to Japanese?
The ToolSet "Classifieds" site I believe has this feature.

[Nigel]

Hi Paul

You can use the cred_save_data hook to trigger some code when you publish an English post, and the WPML wpml_admin_make_post_duplicates hook to generate a duplicate with another language setting.

See
https://toolset.com/documentation/programmer-reference/cred-api/#cred_save_data
and
https://wpml.org/wpml-hook/wpml_admin_make_post_duplicates/

[PaulS4783]

THANK YOU!
That was a virtual "high five" moment ?
Works pretty much as I wanted.
I'll go ahead and hard code the email field labels for each notification language version.

TWO final problems.
1) The taxonomy field in the notification email isn't showing the correct language version.

<p><strong>Shipment Code: [wpv-post-title id="[trid pid='%%POST_ID%%']"]</strong></p>
<p><strong>SHIPMENT STATUS: </strong>[wpv-post-taxonomy id="[trid pid='%%POST_ID%%']" type="shipping-status" format="name"]</p>
<p><strong>Customer Name: </strong>[types id="[trid pid='%%POST_ID%%']" field='customer-name'][/types]<br />
<strong>Preferred Language: </strong>[types id="[trid pid='%%POST_ID%%']" field='customer-language'][/types]<br />
<strong>Point of Departure: </strong>[types id="[trid pid='%%POST_ID%%']" field='point-of-departure'][/types]<br />
<strong>Point of Arrival: </strong>[types id="[trid pid='%%POST_ID%%']" field='point-of-arrival'][/types]<br />
<strong>Estimated Delivery Date: </strong>[types id="[trid pid='%%POST_ID%%']" field='delivery-date-estimated-actual' style='text' format='Y-m-d'][/types]<br />
<strong>Description of Goods: </strong>[types id="[trid pid='%%POST_ID%%']" field='description-of-goods'][/types]<br /></p>

All the fields show the correct language version but the taxonomy type "shipping-status" only shows the English version.
Any reason why this wouldn't follow the POST_ID ?

2) When I update the taxonomy code via the CRED form, the notification email includes the PRIOR taxonomy value, not the new value.
It seems as though the notification email routine is saving the value of the taxonomy field prematurely and incorrectly including it in the email.

[Nigel]

Hi Paul

1.

Can you test this with hardcoding the ids for the taxonomy field (i.e. using an English test post and its Japanese translation) so that we can eliminate the possibility that there is a problem with the custom shortcode in this case?

Also, if you edit the Japanese translation of the post in question in the backend, what do you see for the taxonomy? Does it display in English or Japanese?

2.

To recap. Your form notification is triggered when the shipping status taxonomy is changed. The notification includes that taxonomy in the email body.

The issue is that the taxonomy in the notification is the value *before* the change which triggered the notification, and is not the new value, is that right?

And this has nothing to do with the translations, it happens with the English posts and notifications.

If you confirm that I can test it locally to try and reproduce.

[PaulS4783]

1. Can you test this with hardcoding the ids for the taxonomy field (i.e. using an English test post and its Japanese translation) so that we can eliminate the possibility that there is a problem with the custom shortcode in this case?

Also, if you edit the Japanese translation of the post in question in the backend, what do you see for the taxonomy? Does it display in English or Japanese?

I assume you mean like this (for the Japanese email)

<p><strong>Shipment Code: [wpv-post-title id="[trid pid='%%POST_ID%%']"]</strong></p>
<p><strong>SHIPMENT STATUS: </strong>[wpv-post-taxonomy id="1152" type="shipping-status" format="name"]</p>
<p><strong>Customer Name: </strong>[types id="[trid pid='%%POST_ID%%']" field='customer-name'][/types]<br />
<strong>Preferred Language: </strong>[types id="[trid pid='%%POST_ID%%']" field='customer-language'][/types]<br />
<strong>Point of Departure: </strong>[types id="[trid pid='%%POST_ID%%']" field='point-of-departure'][/types]<br />
<strong>Point of Arrival: </strong>[types id="[trid pid='%%POST_ID%%']" field='point-of-arrival'][/types]<br />
<strong>Estimated Delivery Date: </strong>[types id="[trid pid='%%POST_ID%%']" field='delivery-date-estimated-actual' style='text' format='Y-m-d'][/types]<br />
<strong>Description of Goods: </strong>[types id="[trid pid='%%POST_ID%%']" field='description-of-goods'][/types]<br /></p>

And yes, when I update the taxonomy for Post ID 1152 I get this:

Shipment Code: MOXG789126EYE
SHIPMENT STATUS: Inland transport
Customer Name: Global Fruits
Preferred Language: Japanese
Point of Departure: 神戸
Point of Arrival: ドバイ
Estimated Delivery Date: 2019-01-10
Description of Goods:
リンゴの負荷

That's what I expect except for the taxonomy which should show "内陸輸送" where it currently says "Inland Transport"

2. To recap. Your form notification is triggered when the shipping status taxonomy is changed. The notification includes that taxonomy in the email body. The issue is that the taxonomy in the notification is the value *before* the change which triggered the notification, and is not the new value, is that right? And this has nothing to do with the translations, it happens with the English posts and notifications.

YES. 100% correct.

[PaulS4783]

I am wondering if you have any update on this?

1) If I edit the taxonomy USING THE MATCHING language version CRED form, then the email prints the taxonomy in the correct language. This is still less than ideal. I'd like the taxonomy language to match the Preferred Language Field, regardless of which CRED form is used to update the record. Note that custom fields now do this. Only the taxonomy is the problem.

2) Regardless of whether taxonomy is updated on the back-end or the front end, it prints the PREVIOUS taxonomy, NOT the updated taxonomy. This point in particular is a show-stopper.

Standing by for your advice.

[Nigel]

Hi Paul

I was testing this yesterday and I had problems with the taxonomy in the notifications—the taxonomy field wasn't outputting anything at all—and so I'm setting up a fresh test installation to check again.

I'm about to do that (coffee) and then I'll get back to you.

[Nigel]

Hi Paul

Can you clarify something?

At the start of this thread we were talking about a shipping status custom field which is used to trigger the form notifications.

In your last updates the shipping status seems to have become a taxonomy.

Did I miss something?

You can only use changes in custom fields to trigger the notifications, not taxonomies, but you are clearly outputting a shipment status taxonomy in your notifications described above.

[PaulS4783]

At the start of this thread we were talking about a shipping status custom field which is used to trigger the form notifications.
In your last updates the shipping status seems to have become a taxonomy.
Did I miss something?

That is 100% correct.
The "Shipping Status" needs to be synchronized between the two language versions.
e.g. we can't have a shipping record that says "being prepared" in English and "delivered" in Japanese.
It seems difficult (impossible?) to keep the two language versions in sync when updating via the CRED form.

Therefore, I changed it from a custom field to a taxonomy.
Now, at least the two language versions stay synchronized.

If there is a way to synchronize custom field language versions, I'm all ears,
and that might be another way to solve these problems.

[Nigel]

Thanks for clarifying.

What I don't understand, were we to continue with shipping status as a taxonomy, is how you are triggering the form notifications in that case.

[PaulS4783]

hidden link
Click on one of the Shipment codes then update the Shipping status via the CRED form.
The form contains only one drop down field for the taxonomy.
If you give me an email address, I will input that as the recipient email and you can test for yourself (I'll need to remove access privileges).
When the "customer language" is set to English, the English email is generated.
When "customer language" is set to Japanese, the Japanese email is generated.

[Nigel]

FYI I'm currently stuck, and am waiting on feedback from colleagues in WPML about what to expect when retrieving fields from translated posts in the circumstances we are working in, and I'll keep you posted.

[PaulS4783]

OK. Thanks for the update.

tbh the second problem described in #1044317
seems to me like a purely TYPES issue.

On your test install does the notification send the taxonomy AFTER it has been updated when WPML is disabled?
I would interested to know.