Unpublished document webhook trigger does not invalidate cache

[peterjaap]

Both webhook controllers now use the document ID in the payload to retrieve documents through the API and consequently flush the relevant cache types.

This works perfectly fine on publish. However, on Unpublish, the document is not retrievable through the API anymore. So we don't have data on what custom type it is and we can't flush the cache.

So triggering a webhook on an Unpublish trigger doesn't invalidate anything right now.

[peterjaap]

Unfortunately it is not possible to query unpublished documents; https://community.prismic.io/t/query-unpublished-draft-archive-documents/6537/7

[peterjaap]

Three ways to circumvent this from most desirable to least desirable;

1. Add the Prismic document ID to the Magento cache tags of the relevant pages, so we can flush the cache using solely the Prismic document ID. This makes flushing the cache much more granular (on individual cache item basis instead full cache when the matching document type is selected)
2. Keep track of each document ID and it's Prismic document type in a pivot table so we can match it
3. Don't even care about the Prismic document type, just nuke the complete cache on any trigger

[peterjaap]

Actually, solution 1 would only work for Prismic custom types that are standalone pages like Blog, Landing Page, News, Agenda, etc.

This won't work for Prismic custom types that are used as "blocks" like USP's or Footers because those might show up on every page. So for best results, we need a hybrid approach between solution 1 and solution 2.

[peterjaap]

Since Magento cache tags are the responsibility of the blocks in a certain page, the way for us to handle this is to add tags to a block that is being included when a page is rendered using Prismic data. That means adding it to prismicio_default.xml because that handle is being added in every relevant
Prismic frontend controller.

We could abuse one of the existing blocks but I'd vote in favor of creating a new block just to handle the cache tags, which doesn't output anything. The block should have a _construct (not a __construct, mind the single underscore) like this;

protected function _construct()
    {
        parent::_construct();
        $this->addData([
                'cache_lifetime' => 86400,
                'cache_tags' => ['prismicio', 'prismicio_' . $prismicDocumentType, 'prismicio_' . $prismicDocumentId]
            ]
        );
    }

For this, we probably need to store $prismicDocumentType and $prismicDocumentId in the registry in the controller and fetch it from the registry in the block.

This way we can flush specific cache entries by using specific or more generic cache tags;

• prismicio
• prismicio_blog
• prismicio_Y9vZtxAAACQARTQo

[peterjaap]

@JeroenBoersma thoughts on this?

[peterjaap]

Wait, maybe we can retrieve the document ID and add cache tags on the extension's AbstractBlock? That way, every page that includes any of the Prismic blocks can get the cache tags and can be flushed using just the documentId so we won't need a hybrid approach.

[peterschriever]

In a nextjs project which also uses prismic I stumbled across a very similar problem. This project uses webhooks from prismic to revalidate static content from next. However when Prismic only sends the document id, there is no way to figure out which url this document corresponds to and rebuild content in next.

Eventually I figured out a way of working around this was to always revalidate the Prismic data at least once every day or so, using nextjs default Incremental Static Regeneration method. Unfortunately this means the website does not update on-demand.