You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Try to simplify it by grabbing the cachekey that is used in the base class CacheTagHelper from Microsoft
Track that rerference/key in our dictionary/list which we can remove from the IMemoryhCache on ContentPublished, Media & Dictionary with CacheRefresher notifications
// Set the endabled flag to false & lest base class
47
+
// of the cache tag helper do the same stuff as before
50
48
this.Enabled=false;
51
-
awaitoutput.GetChildContentAsync();
52
49
}
53
50
else
54
51
{
55
-
// with the CacheTagHelper we are wrapping here it's really difficult to clear the cache of the Tag Helper output 'on demand'
56
-
// eg when a page is published, with Umbraco's CachedPartial that's what happens, so if you change the name of a page, and the site navigation
57
-
// is cached with a cached partial, the cache is automatically cleared.
58
-
// it seems for CacheTagHelper the .net core advice when you want to break the cache is to update the varyby key, the previous key in the cache will be forgotten
59
-
// and fall out of the cache naturally... (but I did later on find this article: https://www.umbrajobs.com/blog/posts/2021/june/umbraco-9-net-core-caching-part-1-cashing-shared-partial-views/
60
-
// where it talks about being able to clear the actual cache tag using reflection.. - it won't work on loadbalanced servers - using wrong notifications!
61
-
// ... so maybe that's the way people will ultimately prefer to go...
62
-
// but for this tag helper we just track the last time a peace of content, dictionary item or media was published, and use that datetime in the varyby cachekey
63
-
// so everytime something is published in Umbraco, the cache tag helper will have a different cache key and this will produce a new cached result
64
-
// this might be a bad thing?
65
-
// so we have a setting to turn this off, so the tag helper is still usable as the existing .net core cache tag helper, without caching in preview or umbraco debug
66
-
// which is still handyish
67
-
if(_updateCacheKeyOnPublish)
52
+
// Defaults to true - have to explicitly opt out with attribute set to false in Razor
53
+
if(UpdateCacheKeyOnPublish)
68
54
{
69
-
// ironically read the last cache refresh date from runtime cache, and set it to now if it's not there...
// if an expiry date isn't set when using the CacheTagHelper, let's add one to be 24hrs, so when mulitple publishes occur, the versions of this taghelper don't hang around forever
76
-
if(this.ExpiresAfter==null)
77
-
{
78
-
this.ExpiresAfter=newTimeSpan(24,0,0);
79
-
}
80
-
}
55
+
// So before we go into our base class
56
+
// Grab the cache key so we can keep track of it & put into some dictionary or collection
57
+
// and clear all items out in that collection with our notifications on publish
81
58
82
-
awaitbase.ProcessAsync(context,output);
59
+
varcacheKey=newCacheTagKey(this,context);
60
+
varkey=cacheKey.GenerateKey();
61
+
varhashedKey=cacheKey.GenerateHashedKey();
62
+
_cacheKeys.CacheKeys.TryAdd(key,cacheKey);
63
+
}
83
64
}
84
-
}
85
65
86
-
}
87
-
88
-
privatestringGetFallbackCacheRefreshDate()
89
-
{
90
-
// this fires if the 'appcache' doesn't have a LastCacheRefreshDate set by a publish
91
-
// eg after an app pool recycle
92
-
// it doesn't really matter that this isn't the last datetime that something was actually published
93
-
// because time tends to always move forwards
94
-
// the next publish will set a new future LastCacheRefreshDate...
0 commit comments