JSON Webhook Doesn’t Work

So a follow-up with a wonky workaround. I was sort of able to get the basics of what I was after but not using the JSON Webhook, which seems to be broken. I ended up using the regular Webhook, with the JSON flag, and set arguments of pretext,color, and text. I can’t use the JSON Webhook as it just doesn’t seem to work. If there is some special text formatting that should be used it would be helpful to know what that is.

After some more testing it just seems as though the merge tag processing just simply breaks any real potential use of the JSON Webhook. I’m pretty sure that since the merge tags are essentially a form of JSON, from a text representation perspective, that essentially you can’t have merge tags and JSON data.

Yes, the merge tag format seems to be problematic when used within JSON, but we already updated our regex to fix at least some of the issues.

We’ll test your specific scenario to see why it fails and hopefully, that will be an easy fix.

@tnolte are you using the latest version of the Notification plugin and you’re sure the JSON is consumed correctly by Slack (if I guessed correctly what’s processing the webhook)?

Our JSON vs Merge Tag parsing works as expected as you can see here: https://regex101.com/r/Xovlh5/1

Sorry, I should have included my versions in my original post.

WordPress: 5.8.2
Notification: 8.0.3

I did just see that a version 8.0.5 was released. Does that perhaps have a fix? Here is a screenshot of my latest attempt, which doesn’t work either:

https://i.imgur.com/uNLGHm3.png

I don’t get a notification and when I look at the notification log I can see the following JSON was sent:

{
    'attachments':
        }
    ]
}

I’ve also just again tried combinations such as:
"text":"A new plugin was activated at {plugin_activation_date_time}"
or
{"text":"A new plugin was activated at {plugin_activation_date_time}"}
and I get nothing coming through to Slack and I see in the notification log:

Carrier data
json = "text":"A new plugin was activated at November 17, 2021 9:43 pm"

and

Carrier data
json =

respectively. This is now on the latest 8.0.5 version now as well.

• This reply was modified 3 years ago by Tim Nolte.
• This reply was modified 3 years ago by Tim Nolte.

I found the issue! The empty Merge Tag stripping option was misreading JSON and it treated the whole structure like:

{"text":"A new plugin was activated at {plugin_activation_date_time}"}

as an unresolved merge tag.

I’ve patched it immediately so updating to 8.0.6 should help ??

@kubitomakita so this still doesn’t work for the following example:

{
    "attachments":[
        {
            "text":"A new plugin was activated at {plugin_activation_date_time}",
            "color":"warning",
            "fields":[
                {
                    "title":"Plugin Name",
                    "value":"<{plugin_url}|{plugin_name}>",
                    "short":true
                },
                {
                    "title":"Plugin Version",
                    "value":"{plugin_version}",
                    "short":true
                }
            ]
        }
    ]
}

@kubitomakita I tested your code changes with my JSON string, and even tested your original clear() regular expression pattern, and that’s not the problem with the code. You can test it out here here.

• This reply was modified 3 years ago by Tim Nolte.
• This reply was modified 3 years ago by Tim Nolte.
• This reply was modified 3 years ago by Tim Nolte.

That’s weird. I tested with your specific scenario. The cleaning happen when all the rest merge tags are resolved.

See this clearer examples:

Old regex: https://regex101.com/r/dutwpF/1
New regex: https://regex101.com/r/HcQmvs/1

I’ve replaced correct merge tags with Rendered string.

You say updating to v8.0.6 doesn’t give correct results?

Correct I’m using the latest version of WordPress and the latest version of the Notification plugin and I get no notifications to the webhook and I still end up with the following in the Notification logs:

{
    'attachments':
        }
    ]
}

If it test the “simple” single text field version it works now.

I just found out that it works on my local but not on another live host, so this much be something related to how the regex is parsed. I’m investigating it.

Another fix has been released in v8.0.7. It was related to shortcode stripping option as well.