We would like to suggest developing an API to automatically clear query caches when an article is updated or republished.
We are a news publisher and focus on the republishing of our news content for google.
Such an API would help us to to automatically clear caches of article or index pages as soon as we change text, add embeds, changethe headline or the url of an article. Beeing able to clear chaches for those pages when they are updated would give us the opportunity to increase TTL for those pages and therefore improve response times for users and google bot.
Guest
Hi Alexandra,
Publishing platform emits cache clear events to delivery and Pagebuilder internally and clears article detail pages. This is actually already done, but has some gotchas and may break if customers implement their global content source responses outside of general conventions. Relatively recently we published a documentation section about this internal cache clearing workflow here: https://dev.arcxp.com/caching/automated-cache-clear/
Essentially any story publish (via Composer UI, or via Draft API) triggers this chain and tells:
Story updated, go tell CDN cache clear (same cache clear UI you have in Delivery tile in your Arc admin) to say clear cache for
/story/url/...Then CDN cache clear system tells PageBuilder Engine through the resolver configuration, to say, clear PageBuilder cache for that url's global content.
The biggest gotcha that we see customers unintentionally break this chain's last step, is if they change shape of ANS object's root
_idandtypeproperties. As long as your global content source returns those two properties at the root, untouched, the cache clearing system can tag and clear by composer/draft-api based updates. No need to additional API call to clear the cache.So your publishing updates show up in the article detail pages in seconds.
Can you guys review this documentation and see if we're describing the same need or if you are talking about a different capability.
Thanks for the idea! A feature similar to this is planned for early next year so that the PageBuilder cache is more responsive to changes in content.