Content Published webhook on Multicultural site results in wrong payload or null

[DeadMonkeyX]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

15.2.0

Bug summary

When publishing content in the non-default culture the webhook payload is either the expected payload for the default culture or null

Specifics

No response

Steps to reproduce

1. Do a clean installation of v. 15.2.0
2. Setup a doctype with some content fields:
   

2.1 that has Allow vary by culture

2.2 I have also set this doctype to Allow at root

3. Add another language and make sure it is not the default language (I used Spanish in my testing)

4. Setup webhook using webhook.site for testing

5. Create a new content item using the doctype from step 2 and save and publish this

5.1 Check webhook response and it looks fine

6. Add the same page but in Spanish, save and publish

6.1 Check webhook response and this is the "wrong" response

Expected result / actual result

I expect to get the content publish response from the Spanish page, However, I'm getting the English one (see steps to reproduce)

I have also experienced getting a null in the webhook payload, but I cannot consistently reproduce that behavior

---

This item has been added to our backlog AB#49859

[NguyenThuyLan]

Thanks @DeadMonkeyX , I was able to reproduce it on 15.2.1

[kjac]

Hi everyone.

While I understand the reasoning here, the implications of sending out variant payloads can be quite severe. Not to mention very functionally breaking.

Imagine for example a setup with three languages and two segments (per language). A (re)publish of all languages would trigger six webhook deliveries, instead of the current single delivery.

This is not a bug, as the functionality is working as intended. However, I would really appreciate some inputs on this from the community. Therefore, I'm going to move this one to the Discussions section.

[kjac]

Off the top of my head I can think of three ways to solve this:

1. The solution outlined above; firing the webhooks for each variation.
   • This is functionally breaking, as it (to a point) will constitute duplicate deliveries in comparison to the current functionality.
2. Change the webhook payload to match that of the Delivery API.
   • At this time, the payload is the same as the Delivery API output, except the cultures collection. Including the cultures is an easy fix to provide additional cultural context, but this has no notion of available segments, nor does it contain create/update date of the individual culture.
3. Add a new variants structure to the existing payload.
   • This would list all variants of the content (culture + segment), and could include additional details such as publish state, create/update date, ...

The third option might sound immediately most appealing. The biggest downside as I can tell is that we'll be introducing something that is definitively not part of the Delivery API output, which could potentially cause issues on the consumer side when webhooks and the Delivery API are used in conjunction.

[kjac]

We're currently investigating a fourth option, which is to change the webhook payload format somewhat. Instead of passing the default language variant, we'll pass an array containing all variants. In the interest of keeping the payload size down, it will likely be possible to omit the actual content (the document properties) from the payload by configuration.

Since this will be a behaviourally breaking change, we'll also look into making this an opt-in thing for a while. And likely also an opt-out thing as well, in a grace period towards eventually letting the new format take over completely.