Hey, I've seen this exact behavior after page type conversions. The issue isn't just block cache - it's that the published event isn't firing properly for converted pages because their ContentVersion or SaveAction flags don't match what the cache eviction system expects.
Clearing specific cache keys manually works as a hotfix, but you'll need to maintain that list forever. Better approach: run a one‑time script that forces a "re‑publish" without changing content – that resets the internal state. Something like:
var pages = _contentLoader.GetChildren<NewsPageV2>(contentReference); foreach (var page in pages) { var writable = page.CreateWritableClone(); _contentRepository.Save(writable, SaveAction.Publish, AccessLevel.NoAccess); }
This triggers the proper event chain and cache invalidation. We used it on 2000+ imported articles and never had the issue again.
If you still prefer the cache purge route, at least scope it to the specific page type instances rather than all viewmodels.
We're building a new CMS 12-site for one of our clients and they have an extensive news archive that they wanted to import.
We've created a dummy model for the old NewsPages (with the same guid as the old CMS 11 news pages) and imported them. With the "Convert page type"-function We've converted those NewsPages to our new NewsPageV2 page type. So far so good.
But I've noticed now that these imported pages doesn't invalidate cache on publish. That is, If I edit the header property the value are saved in edit mode and it looks good when I preview but if I visit the page the header isn't updated at all and I need to restart the application for this to work.
When I debug I see the old values in the properties as well, and the NewsPageV2 page type works like excepted if you create a new page with it.
Has anyone else encountered this type of problem? We're on Episerver 12.34.2