Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate transforms on Asset upload #1544

Closed
khalwat opened this issue Mar 17, 2017 · 6 comments
Closed

Generate transforms on Asset upload #1544

khalwat opened this issue Mar 17, 2017 · 6 comments
Assignees
Labels
enhancement improvements to existing features

Comments

@khalwat
Copy link
Contributor

khalwat commented Mar 17, 2017

Generating asset transforms can be very time-consuming, and they happen when speed is critical: when servicing frontend requests, either when the page is loaded, or when the transform is requested (depending on the config setting).

Instead, it would be very useful to be able to have the asset transforms when an Asset is uploaded, at which time performance is not critical.

The way I'd envision it working would be that there would be a checkbox per Asset source:

[X] Generate transforms on Asset upload

And then with a list of the available transforms so you can choose which ones should be generated, and which ones would not. Thus as soon as a client uploads an image, the transforms needed on the frontend will automatically be created for them.

This has the added bonus of triggering EVENT_GENERATE_TRANSFORM so plugins like my ImageOptim plugin would be able to optimize the images—which can also be time-consuming—on image upload, rather than slowing down front-end requests.

The fallback path of it checking to see if the transformed image exists on the frontend request would still be there, of course, in case the transformed images are somehow removed after they've been uploaded.

If the user chooses to Update Asset Indexes it would similarly cause all of this to be rebuilt at a time when performance is non-critical.

If you use dynamic transforms in your templates, they would not be able to benefit from this, but I think that's a reasonable separation to make.

@MattWilcox
Copy link

Oh man, so very much this. The time for hardcore processor crunching is on edit, not when a member of the public is trying to see a page.

@nateiler
Copy link
Contributor

Great feature. Might also be worth looking into the processing happening via task as well.

@michaelrog
Copy link

(Sort of related: #1690)

@khalwat
Copy link
Contributor Author

khalwat commented Sep 15, 2017

So if this never gets rolled into core, this plugin does it for you:

https://github.com/nystudio107/craft3-imageoptimize

(amongst other things)

@j-greig
Copy link
Contributor

j-greig commented May 8, 2018

Adding my +1 for this (having just changed an image source over and witnessed a painful rebuild of all the thumbs everywhere)

@brandonkelly brandonkelly added enhancement improvements to existing features and removed feature labels Mar 5, 2019
@kara-todd
Copy link

kara-todd commented Sep 17, 2020

Not to necro and old thread here but... I also ran into this issue. :)

I found a hacky way to do this using the WebHooks plugin. I created a webhook which fires on asset save and then used twig to make a get request to the asset url transform (i.e. {{ event.sender.getUrl("transformHandle") }}.

Edit:

The above does work, but with a big caveat. The webhooks plugin by default stores the response body of a request and tries to insert it into the database. This is problematic for large binaries to say the least. My workaround was to create a site module with a simple controller that took the assetId and transform handle as parameters and then made a GET request to the transform url via Guzzel... Working so far. :)

Hope this helps any other poor souls who stumble across here.

@craftcms craftcms locked and limited conversation to collaborators Jun 22, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement improvements to existing features
Projects
None yet
Development

No branches or pull requests

8 participants