search

CrumpledDog / Umbraco-AzureCDNToolkit

Makes it easy to fully utilise the Azure CDN with a Umbraco website
13 stars 14 forks source link

V8 Version of Toolkit? #30

Open c9mb opened 3 years ago

c9mb commented 3 years ago

Are there any plans to create a V8 version of this toolkit?

I am starting on migrating V7 sites to V8, and currently make extensive use of UmbracoAzureCDNToolkit for rendering AzureCDN urls when using ImageProcessorAzureBlobCache & UmbracoFileSystemProviders.Azure

stefankip commented 3 years ago

Would've loved to see this as well, but I think it's not gonna happen.

c9mb commented 3 years ago

I agree - there are 301/302 latency elimination benefits, ease-of-use benefits in accessing cached cropped versions, and source-file obscuration benefits that all flow from the package. I know that @Jeavon was considering a v8 version (mentioned in other issues) but it seemed to lose priority - which is totally understandable for a 'free' package developer, and must be respected. I honestly am yet to seriously address this issue (still stuck on v7) but off the top of my head I don't see an easy option to replace it in v8.

dKumarmj commented 3 years ago

Any updates on V8?

Jeavon commented 3 years ago

Hello, I have decided to retire this package, at the time I developed this it served a great purpose to support the easy implementation of Azure CDN, specifically to eliminate the 301 issue as well as some other issues.

However in the 5 years since I built it the adoption of reverse proxy CDN has been massive (Cloudflare, Front Door, etc.) and I don't see there's a need for the approach I took with this package.

I have also included in Slimsy v3 the option to easily use Azure CDN as a reverse proxy if Cloudflare/Front Door are not an option. See https://github.com/Jeavon/Slimsy/blob/dev-v3/Docs/Azure-CDN/index.md for more info.

I did archive the Github project but I've undone it for now as I would love any feedback you have!

c9mb commented 3 years ago

@Jeavon It's unfortunate to see it won't be migrated, but I guess understandable.

The package does have at least one feature that I have struggled to find an alternate solution to - direct rendering of the /cache location for a processed image.

Reverse proxy of the /media is fine if you don't care about direct image access, but I have a large client who is using ImageProcessor to apply watermarks and overlays to cached versions of their commercial images, and the cache url makes it pretty hard for people to bypass that and access the source image from the media library. Not sure how I'm going to handle that for V8/9