[Resolved] Notification sending code, not name

[Author]

Posts

[lindsayH]

Hi, I just did another test to an aol account (my initial test was to a Hotmail account) and I'm still seeing the same problem. So as you've setup on the same server and you say it's fine... there must be some problem because otherwise I would also be fine.

Also I note, as I'm logging emails, since you updated the email body we seem to have the same email going out twice....

Looking at 111 you do also seem to have received one incorrectly (as I mentioned same went out twice).

PS I can't see the first image you attached, but I can see all emails sent anyway... see images below.

[Minesh]

You are seeing emails two times because I've setup a test notification "Toolset Test email notification" with same content. The last notification.
=> hidden link

Looking at 111 you do also seem to have received one incorrectly (as I mentioned same went out twice).
==> Well - I do not know what I can do here as I already send you screenshot of my setup and email that it works just fine at my end. I see the field rendered correctly at first place in email. But other two shortcodes are not working on your end. But for me it works.

I will give another try tomorrow to see if there is any change and update you accordingly.

[lindsayH]

Bot trying to close, but was waiting for feedback. Did some more testing below.

I removed the below from the original notification.
=== [types field="first-name-listing" item='%%POST_ID%%'][/types]
=== [types field="first-name-listing" id='%%POST_ID%%'][/types]

It now just has:
<p>Dear [wpv-post-field name="wpcf-first-name-listing" item="%%POST_ID%%"] </p>

The notification you added is:
<p>Dear [types field="first-name-listing" item='%%POST_ID%%'][/types]</p>

I seem to be getting Dear Lindsay for both.

If I change the original BACK to
<p>Dear [types field="first-name-listing" id='%%POST_ID%%'][/types]</p>
I get Dear [types field=”first-name-listing” id=’5020′][/types]
Which is EXACTLY the same as I had with same problem at the very start of this (see opening thread).

To back this up
When you amended my original to:
<p>Dear [wpv-post-field name="wpcf-first-name-listing" item="%%POST_ID%%"] </p>
=== [types field="first-name-listing" item='%%POST_ID%%'][/types]
=== [types field="first-name-listing" id='%%POST_ID%%'][/types]

I receive:
Dear Lindsay
=== [types field=”first-name-listing” item=’4994′][/types]
=== [types field=”first-name-listing” id=’4994′][/types]

(So first line worked).

I THEN changed both emails to simply be:
<p>Dear [types field="first-name-listing" id='%%POST_ID%%'][/types]</p>

So this is still the same as I had originally in my opening post and your new notification is updated to be the same.

Now BOTH are identical codes, BUT in the received email my original exports the code, but your newer exports the expected data.

I THEN noticed that you hadn't set up your notification exactly as I had and so I changed the email trigger in your notification FROM 'When submitting the form' TO 'When post status changes to Published' and your notification is having the same issue as my original now (you will have received an email 'Your listing for Another Test for Emails 16 has been published'). I can see from my logs you are now also seeing the codes within the email body. You ALSO got this on your test (see #post-1124448) 'Your listing for Toolset Test 111 has been published' when all variables were actually the same (before my original was amended by you and your email was specified in the post form). Please see images attached.

I have never ending issues with email notifications. The latest resolution to a previous issue is to "So, for example, notifications became stable (but may need to be saved as such "new versions" first)". I'm not sure this would help the case here... but as you can understand it's taken hours of work and I'm still not reassured about the stability of the notifications.

[Nigel]

Hi Lindsay

Minesh is sick.

I quickly read through this and I see in your last reply that Minesh had set up a notification slightly different than you had, using "when the form is submitted" rather than "when the status is changed to published".

If you are using the latter, does that mean the post is originally submitted with a different status, and then in the backend you change the status to publish, or you do so using a post edit form?

If I have the details right, I can try and reproduce the problem.

Our developers recently did quite a lot of work on notifications to rework them as they were a never-ending source of issues previously, but the current versions *should* work reliably, and if you have found a particular circumstance where they do not then we'll certainly need to address that.

[lindsayH]

Hi, thanks for your help.

"If you are using the latter, does that mean the post is originally submitted with a different status, and then in the backend you change the status to publish, or you do so using a post edit form?"

Yes, the form after submitting has the status of Pending Review. Then in the back end I set it as Published (which is when the notification is sent).

Thank you.

[Nigel]

Hi Lindsay

I tried to replicate the issue on a local test site but could not.

I have a form which submits posts that have a pending status.

There is a notification for when the status is changed to published.

Here's what the body of my notification email looks like:

The following Listing was published: %%POST_TITLE%% (%%POST_ID%%)

<p>First Name 1: [types field='first-name'][/types]</p>
<p>First Name 2: [types field='first-name' id='%%POST_ID%%'][/types]</p>
<p>First Name 3*: [types field='first-name' item='%%POST_ID%%'][/types]</p>
<p>First Name 4: [wpv-post-field name="wpcf-first-name" id='%%POST_ID%%']</p>
<p>First Name 5*: [wpv-post-field name="wpcf-first-name" item='%%POST_ID%%']</p>

And in the screenshot you can see from my mail logger what the generated email looks like. Only the first example doesn't output the field, which is expected for deferred notifications where the source post must be explicitly set using the %%POST_ID%% placeholder.

Bear in mind when testing that any changes you make to a form will only apply to *new* content submitted with the form, not to existing pending review posts.

Can I get a duplicate of your site to install and test locally?

hidden link

Be sure to exclude the uploads directory when creating the backup to reduce the file size.

Your next reply is private.

[Nigel]

Hi Lindsay

I'm not sure what's what with those various archives you linked to.

Why don't I try and take a copy myself using All in One WP Migration instead.

Let me get site credentials from you.

[Nigel]

Lindsay, I'm having a bit of a problem working out what I'm supposed to be testing, despite reading through your back and forth with Minesh.

I have the site copy installed locally.

In one browser I'm logged in as an admin.

In another, I'm logged in as ExpEmail.

When I visit the page ../suppliers-profile/add-edit-listing/ there is already a post to edit. So my admin user goes and deletes that "test 16" supplier post.

Now when I refresh the page I get a blank content area. I was expecting the publish content form to be shown, but nothing is.

There were JS errors in the console which I eliminated by disabling most of your non-Toolset plugins, but I'm still looking at a blank page (just the header and navigation).

Ideas?

[lindsayH]

Yes, that's strange. When you go to the add-edit-listing/ you should see the post to add/edit (which you do before deleting the original to start again).

I am not sure why the post isn't showing? Would it be theme related? If you look at the staging site, it will be there?

Many thanks Lins.

[Nigel]

Hi Lindsay

That was quite the rabbit hole of templates within templates within conditions etc., and in the end I stripped back the site to including only the essential plugins and the twentyseventeen theme, and to insert the form directly onto a test page.

I can confirm the issue on your site, although I can't reproduce it on a clean test site.

So I've had to escalate this so that my colleagues can take a closer look to see if they can identify what the difference is, and I'll let you know.

[Nigel]

Hi Lindsay

Quick update to say that this will be fixed in Types 3.2 (which is currently in QA testing).

In the meantime a patch is available from this erratum: https://toolset.com/errata/types-shortcodes-are-not-expanding-in-toolset-forms-notifications/

[Nigel]

Hi Lindsay

Quick update to say that plugin updates were finally published today and updating should resolve the problem.