Skip Navigation

[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.

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)

Tagged: 

This topic contains 34 replies, has 3 voices.

Last updated by Nigel 6 years, 3 months ago.

Assisted by: Nigel.

Author
Posts
#1069364

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Form notifications—aside from making me look foolish—can be triggered by changes in custom fields but not by changes in taxonomies.

That's what the documentation describes, and if you add a notification and try to set it to send when the value of a taxonomy changes, well, it won't let you choose a taxonomy in the dropdown, it only offers custom fields.

If you somehow have this working because you have created such a notification based upon a custom field and then, maybe, re-used the same slug for a taxonomy instead, well, I couldn't reproduce that myself, but in any case it is not the supported way of triggering deferred notifications.

So on my new test site I have been working with custom fields for the shipping status.

You require the custom field to by synchronised between the English and Japanese versions.

In the workflow we discussed you said that it was okay to have a workflow where it was always the English language version of the shipping post where the shipping status was updated.

In that case, syncing is straightforward, you just set the WPML settings for this custom field to "copy", in which case whenever you update the custom field on the English post, the Japanese post will automatically be updated with the same value.

Which leaves the issue of displaying the field in Japanese when we want to send a Japanese notification.

This should also be straightforward, but is where it breaks down.

The custom field values are synchronised, but we can use WPML String Translation to translate the display texts for each option.

Then, when we use the id attribute to specify that the fields in the notification should refer to the Japanese post it should output the Japanese display text for the shipping status field. But it doesn't, it displays the English value.

I've been discussing with the WPML team and Types developers about how this should work, and they've asked me to escalate this so that they can take a closer look and determine exactly why it is not behaving as expected – or if it's even possible.

I'm waiting on them.

#1069587

OK.
fyi, here is why maybe my current setup works.

I said previously that the CRED update form only contains the taxonomy field.
Strictly, that was misleading.
The CRED contains ALL FIELDS for the Shipment post type but they are just hidden with CSS.
So even though the user is only changing one field (the taxonomy) TYPES probably recognizes this as an update to all custom fields?

Anyway, I'm not opposed to making "Shipment Status" as custom field instead of a taxonomy,
with WPML translation status set to "copy" IF we can get the correct language version to display in:
a) The notification email
b) Views queries

I'd refer you to a previous support thread where we developed a Views query to show the current shipment status.
hidden link
Try Shipping codes: MOXG478236RIB, MOXG457894TUQ

#1074707

I need an update on this ASAP, please.

The reason for choosing ToolSet in the first place, versus a rival or alternative solution, was my assumption that ToolSet and WPML would have tight integration, given that they are both products of the same company.

fyi I have abandoned the use of Taxonomy (for now).
All fields within the Shipment record are custom fields.

The following is the only workflow that even comes CLOSE to working for me.

1) Create a Shipment Record in English using the Dashboard.

2) Duplicate the post to Japanese.

3) Switch to Japanese and update those fields which are not set as "copy" by WPML
i.e. Descriptions in Japanese text.

4) Go to the CRED form on the front end and "Save" the data again (this step seems superfluous from a user point of view but is necessary in order to "register" the post with CRED, in order to utilize the email notification feature).

5) When the Shipment Status changes, update the custom field in the backend.
This will:
a) Copy the new status to the Japanese version (as the field is set as "copy")
b) Fire an email notification to the customer in English with the correct details.

NOTE1: I would prefer if the Shipment status could be updated via CRED but this seems impossible as it ONLY updates the English version. The Japanese version of the post does not get updated.

NOTE2: Since I can't use taxonomy (apparently) the custom field Shipment Status has to be described in BOTH languages in order for the "copy" to make any sense
e.g. Order Received / ご注文承りました.

That's less than ideal, but it is what it is.

NOTE3: There is a SIGNIFICANT problem though, if I set the customers "preferred language" field to Japanese. Now, I still want the admins to be able to update the shipment status via the (English) dashboard, but I expect the email notification to be in Japanese. This works up to a point (thanks to Nigel's registered short code, to identify the post ID).

The problem is that for the Japanese version there seems to be a timing issue (bug) in the way ToolSet works. It sends the email with the Shipment Status PRIOR to the update.
e.g. If the "Customer Language" field is "Japanese" and I change the shipment status to "Being Prepared / 準備中", it sends the email with the shipment status "Order Received / ご注文承りました". If I change it back to "Order Received / ご注文承りました" it now sends "Being Prepared / 準備中".

I've tested this extensively and there seems to be a timing issue in the way the notification processes the translated versions.

The last point is a real "show stopper" so I need the ToolSet team to offer some support and advice very soon.

#1074959

Hello, Nigel is out on public holiday today so I am checking in on his tickets. I can see he's been following up with the WPML team but I don't have access to the information he has received, so I will ask him to follow up with you tomorrow when he returns.

#1076270

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Hi Paul

I just ran through a new set of tests using the updated Types 3.0.7 which fixed the issue with the translated fields not being retrieved correctly if using the id attribute to set the context to the translated post.

So, my Form notification includes the following in the post body:

<p>Post title: [wpv-post-title id="[trid pid='%%POST_ID%%']"]</p>
<p>Shipping status: [types field='shipping-status' id="[trid pid='%%POST_ID%%']"][/types]</p>

My workflow is

1. create an English shipment record with a front-end Form which includes a shipment status field and a language preference field (both with the WPML copy setting)
2. Use WPML to add a translation of that shipment post and update relevant fields. Shipment status and language preference are kept in-sync with the original.
3. Edit the English post in the backend and update the shipment status field to "Delivered"

This triggers the email notification. Depending on the language preference field this will either output fields in the English original, or the translation (assuming I have translated the select field options for the shipment status field using String Translation).

That worked as intended. I tested with the language preference set to English and the fields output in English. I then tested with the language preference set, in my case, to Spanish, and the fields output in Spanish. The Spanish notification correctly output the current shipping status (i.e. the translation of delivered).

Please try again after updating to Types 3.0.7.

Thanks for your patience while working through this.