Skip to content
This repository was archived by the owner on Jan 4, 2022. It is now read-only.

V8 Version of Toolkit? #30

Open
c9mb opened this issue Jul 24, 2020 · 5 comments
Open

V8 Version of Toolkit? #30

c9mb opened this issue Jul 24, 2020 · 5 comments

Comments

@c9mb
Copy link

c9mb commented Jul 24, 2020

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
Copy link

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

@c9mb
Copy link
Author

c9mb commented Mar 4, 2021

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
Copy link

Any updates on V8?

@Jeavon
Copy link
Contributor

Jeavon commented Mar 30, 2021

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
Copy link
Author

c9mb commented May 26, 2021

@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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants