Revoke "publish" on all parent records?

🆘 Support
1

Hey. We are revalidating NextJS routes on a web hook trigger setup inside DatoCMS. The revalidate API is called when a record get’s republished. The problem we are having is that this does not work when a linked records are updated.

Is there a way to revoke “re-publish” on all parent record? Example - let’s say we have two content types: Product page and FAQ. Product page has a link field to FAQ. Now lets say I do this

  1. Product page A
  2. Product page B
  3. Product page C
  4. FAQ record X

FAQ record X is linked on Product page A and C. So, is there a way to automatically republish Product page A and C if FAQ X is updated? Or somehow setup a web hook that would let us know parent records of linked records?

Ty

1 Like
2

Hello @primoz.rome, the way to do so would be to get all records linking to it through https://www.datocms.com/docs/content-management-api/resources/item/references unpublish them with Unpublish items in bulk - Record - Content Management API and then re-publish tem with Publish items in bulk - Record - Content Management API

3

So no way to do it automatically without API calls?

Will doing it like you described, invoike my web hook triggers setup in the Dashboard?

4

@primoz.rome , the only way to “re-publish” a record would be so, but can you share with us the use-case for the re-publishing of the parent records?

5

We have the same use case!
The reason for wanting to republish the parent record in our case (and I assume in op’s case) is that in next.js you have to revalidate a page. So you need to know the slug/path of the page to update. The way to do that for us it to use a web hook on our page model so we get that info through the web hook.

If something is updated further down in a referenced model, the hook wont be run because we haven’t re-published the page model, but there has still been a change that we want to revalidate in next.js. If we change the hook to run on publish for all possible referenced models, we won’t get the slug in the payload of the hook, since that is only accessible if it’s the top model that is published.

1 Like
6

@m.finamor like @felicia.moller said … landing page can fetch the content from linked records, correct?! So if you have a page revalidate API for Next.js it will revalidate page if you republish landing page record, but it won’t revalidate if you update the linked record… But this is required, in this case. So to make this happen, we would need a republish trigger on all parent records where this link is addded.

7

@felicia.moller @primoz.rome i see!
So would sending an update webhook upon a linked record update solve both of your use-cases?
Or creating a webhook trigger like “Upon linked record update”, similarly

8

I think so! :thinking:
If it would work with several layers of linked records.

Eg the following models:
Page => Card Section => Card

In this example, Card is only linked to Card Section which in turn is linked to Page. So when Card is updated, Page would need to know about it so we can trigger a webhook to update the page.
But I guess that could be accomplished with a webhook like that :blush:

9

Hi @m.finamor

I agree with @felicia.moller’s on this one… At the en the top parent record in the branch should be updated about the change on any of the children.

If I go back to this structure: Page => Card Section => Card. Then if Card or Card Section are updated, the Page should trigger a web-hook, similar to Publish.

10

Hi @primoz.rome and @felicia.moller :slight_smile:

I’m @sistrall , from DatoCMS’s team. We discussed this with the team, and, for the moment, we won’t proceed on this topic. Below you’ll find two possible solutions and the reasons why we think we shouldn’t add a new web-hook nor (mis-)using the updated-item web-hook.

Solutions

Despite how models and records are configured and linked in DatoCMS, the final responsibility of knowing how the records are used to build the pages is on the front-end. Therefore, it is the front-end that has to decide what to rebuild.

That can be done at least in two ways with some GraphQL queries. Let’s take a structure like this: Page → Section → FAQ: a Page links multiple sections, and each section links multiple FAQs. Let’s suppose to update a FAQ. Then, using the data in the FAQ web-hook, I can execute GraphQL queries like these.

Solution A: two queries

First, a query to get section data:

query GetSection {
  section(filter: {faqs: {eq: "137205127"}}) {
    id
    name
  }
}

Then a query to get page data:

query	GetPage {
  page(filter: {sections: {eq: "Section ID from previous query"}}) {
    id
    title
  }
}

Solution B: one query, leveraging inverse relationships

It’s also possible to enable inverse relationships on the models in scope (FAQ and Section) and do the job with a single query:

query GetFaqSectionAndPage {
  faq(filter: {id: {eq: "137205127"}}) {
    question
    answer
    id
    _allReferencingSections {
		id
      name
      _allReferencingPages {
        id
        title
      }
    }
  }
}

These solutions should cover most needs.

Also, they are flexible enough to cover cases where the contents generate linked pages (or else) that cannot be inferred by looking at the relationships between models in DatoCMS.

Some reasons for the “no”.

A new web-hook for updated linking records would generate quite some complexity on DatoCMS and our customer’s sides: e.g. the risk is to trigger too many web-hooks when a record is linked multiple times. We could de-duplicate the call, but it would still be a brittle solution.

Using the updated record web-hook would be weird: the web-hook would refer to an item that should have changed, but the content before and after would be the same 'cause no change has been made. I would be a trick. So, the updated record web-hook is the wrong solution to the problem.

We could include the referencing items in the relationships of the referred item, but that is a limited solution: a query is needed to retrieve all the data of the referencing items. It also would be a limited solution since we would limit to one level, so a query would be required to retrieve the referencing records of the referencing records.

Sorry for the long answer: I hope it’s clear enough. :slight_smile: Should you need more info, I’m here to help.