Bust node cache on publish of another node

[swudged]

The package (whilst great!) currently doesn't have the functionality to clear the cache of a node based on the publish of another node. In my test example, I am caching all content, dynamic and static, as your instructions suggest to do. My homepage lists articles and recipes, as do the respective landing page sections on the site. If I update an article or recipe or create a new one, the homepage and landing pages stay cached in Cloudflare and users will need to wait until the cache has been cleared in order to see these changes.

A simple way to fix this is to go and clear the cache for the homepage and the landing pages, but having to ask content editors to remember to do this every time seems a bit of an ask, and likely to fail once the site is live.

It would be great if I was able to choose that on save of x doctype, y doctype's Cloudflare cache is cleared. This would allow for multiple areas of the site to be cleared in cache when a dependant node is created or updated.

Is this something you would be interested in adding to the package?

[jmcaveney]

Hi,

Apologies for the delay. I think this slipped through our tasking.

That's something we've discussed before, and certainly something we'd be interested in adding to the package. I wonder if that's a multinode tree picker property we look for and then clear those pages selected, with or without descendants, when the page is published (like the property we use for disabling the autopurge).

Or would setting up the doctype relationships make more sense?

[DanDiplo]

Maybe a simple way around this would be to add some kind of events and API that developers can hook into. A kind of OnCacheClear() event that passes a reference to the node being cleared. Then, as a developer, we can hook into it and then call your API to clear what other related nodes are needed. It could work similarly to the way Umbraco events are raised and handled.

Pseudo Code:

        CloudFlareCache_Cleared(ClearEventArgs<IPublishedContent> e)
        {
            if (e.DocTypeAlias == "Home")
            {
                var newsItems = e.Descendants("NewsItem");

                CloudFlareService cs = new CloudFlareService();
                cs.ClearCacheForNodes(newsItems);
            }
        }

Just a thought!

[jmcaveney]

Probably worth adding regardless, but I thought @mrdbarker was looking for something in the gui to do it.

We may not have time to add that for a while, but if someone wants to send a pull request we'd be happy to take a look.

[swudged]

Hi, I hadn't been notified of these comments either so apologies for the delay too!

Having thought about it, would it make more sense to bust URLs instead? This would solve the original issue mentioned and could offer more flexibility going forward. I'm using pjax and need a way to bust both the page that the user lands on and the reconstructed URL that I make on the client side. We'd need something in the gui like you say, but this shouldn't be too difficult to do.

I'm not familiar with Cloudflare's API.. am I right in thinking this is feasible though?

[LoganPeck]

Hi @mrdbarker if I understand your question correctly, UmbracoFlare does bust the urls behind the scenes. I use the UrlProvider in the RoutingContext to call "GetUrl" and "GetOtherUrls" (see this method) and then traverse up the content tree to get all of the domains that that node has assigned to it.

I'm not sure I understand what you mean by "reconstructed URLs that you make on the client side", care to elaborate? I definitely think that we need to add support to clear the cache for nodes on another nodes publish event. I have ran into that on my own website as well. It shouldn't be too difficult, the back-end code should already be there, it would just be a matter of getting the GUI set up for it.

Let me know what you think.

[swudged]

Hey @LoganPeck,

The reconstructed URLs I was referring to was suffixing pages with ?isPjax=true and then delivering a slightly different response based on that. There was a good article on 24 Days In Umbraco last year. My example for the URLs would be as follows.. I save a recipe and the following pages would also need to be cleared from the cache:

https://myrecipesite.com/
https://myrecipesite.com/?isPjax=true
https://myrecipesite.com/recipes/
https://myrecipesite.com/recipes/?isPjax=true
https://myrecipesite.com/recipes/:node-name/
https://myrecipesite.com/recipes/:node-name/?isPjax=true

Going forward, I (hypothetically so) have changed my site so I expose a data layer at the following urls which would need clearing on save:

https://data.myrecipesite.com/recipes/
https://data.myrecipesite.com/recipes/:node-name

If the package instead allowed you to add URLs to bust based on a doc type, rather than setting up some kind of association to other doc types, could this cover all possibilities?

[clarkd]

CloudFlare is most often configured to ignore query strings, i.e. "?isPjax=true" so in theory, you shouldn't need to purge both URLs etc. Just a thought...

[swudged]

Thanks for the heads up! I currently have caching by query string turned on but will consider changing that going forwards.

[markadrake]

Just circling back around to this. I wonder if there is anything we can leverage in the current CloudFlare API to allow us to detect variations of a URL (any querystring) and delete cache for that document too? First glance at the API docs (v4) aren't promising.

[markadrake]

Hi everyone! Since it's been a while since we last spoke about this issue I'm going to go ahead and close this out. If it becomes an issue again, please open up a new issue and we'll pick it back up. Thanks.