Agree with Chris -
Currently, when content authors choose to upload image or other media files and replace existing media with the same name, the old replaced media lingers in the CDN cache. The CDN cache can be quickly purged through the PaaS portal, but this is a manual step that requires accessing another site outside the CMS itself.

This becomes even more problematic when you in a Cloudflare O2O setup.

It would be good if Optimizely could provide an API to purge the CDN cache for the specific file in question.

We’re currently gathering additional feedback on this idea. If you have any more context, examples, or specific use cases, please share them - it really helps us understand how this would best support your workflow. Thanks for contributing to the conversation!

As a DevOps engineer, I'd like to be able to perform a rolling restart of my sites after deployment via the APi. I'd also like to be able to clear the CDN cache via APi.

We often perform these tasks after a deployment, so to allow this to happen as part of our deployment Pipeline in Azure DevOps, rather than having to manually log in to the PaaS portal and click buttons every time, would be beneficial.

Currently, when content authors choose to upload image or other media files and replace existing media with the same name, the old replaced media lingers in the CDN cache. The CDN cache can be quickly purged through the PaaS portal, but this is a manual step that requires accessing another site outside the CMS itself.

It would be good if Optimizely could provide an API to purge the CDN cache. This would allow development around purging the CDN cache.

But ideally, functionality could be built into CMS for this. When replacing an existing media file with the same name, CMS could have the ability to use the Cloudflare API to purge that file from the cache by URL ("Purge Cached Content by URL" in the Cloudflare documentation at https://developers.cloudflare.com/api/resources/cache/methods/purge/. ).

It would be helpful to Enhance the Deployment API to allow passing a parameter to clear CDN cache after deployment completes.
Reference: https://docs.developers.optimizely.com/digital-experience-platform/docs/deploy-using-powershell

It would be nice if you could expose endpoint so that we could invoke purging of CDN cache after successful deployment to production environment hosted in DXP. I have found that Cloudflare actually supports that via
az cdn endpoint purge -g fagf01mstry1y19inte --content-paths '/*'
but for that to be used by us you would have to wrap it in your endpoint if I understood correctly based on answer to my support ticket.

In Episerver DXP we get a CDN from CloudFlare. Great!
If an editor deletes a media file in edit mode, the file can still be cached for hours in the CDN. This could be bad if the content really NEEDS to be removed right away, and the editor is not aware of the CDN cache.
When Episerver controls the entire platform, it should be possible to use the CloudFlare API to automatically purge the cache for items that are either deleted or updated.
I find it surprising that this is not already in place.
The current workaround is to purge the entire cache from the PaaS portal, or create a support ticket to purge the selected content item. None of these options are optimal.

Common deployment pattern within the DXP when using Azure Devops or another CI/CD system.
* Deploy package
* Clear CDN in Pass Portal
Ideally having to manually login to do this step shouldn't be required.
Can we get the CDN clearing added to https://world.episerver.com/documentation/class-libraries/rest-apis/dxc-service/ and the Powershell so we can add that in to the pipeine.
Also world needs some tags for the DXP / Deployment API

To add highly performant sites granular control of the CDN is required by customers/partners. So being able to purge the CDN for a single URL is an often requested feature. Example could be that a highly trafficked (no personalised landing page could be cached on the CDN ensuring global performance and also taking load off Azure.