Persist rendered picture variants #1882
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![codeclimate[bot]](https://avatars.githubusercontent.com/in/9403?s=60&v=4){kind=small}
|
TODO
|
tvdeyen
force-pushed
the
remote-images
branch
5 times, most recently
from
cd464cb to
db7c83d
Compare
tvdeyen
force-pushed
the
remote-images
branch
4 times, most recently
from
1105b6b to
57315f6
Compare
mamhoff
approved these changes
Jul 17, 2020
tvdeyen
force-pushed
the
remote-images
branch
2 times, most recently
from
3909333 to
5d29b87
Compare
|
@mamhoff extracted several PRs |
The Picture::Url module included transformations to create a variant out of an image. Let's seperate that in it's own class so we can extract url generation into a class.
We only need them in the PictureVariant
Meant as extension point for alternative URL representations of picture variants. For example images hosted on S3 would return the `remote_url` in its url class.
The default of the url format in dragonfly is `:name` what is an alias to `:basename.:ext`. We used to pass `Picture#name` (without the suffix) into the ragonfly `url` method. Since we now extracted the url generation out of the picture class it might be possible to pass a dragonfly attachment (generated by PictureVariant) into the url class. Leading to duplicated extensions in the url, because dragonflys name is basename+ext
In order to be able to cache images on remote storages we need to lazy process the image variant during URL generating.
We need those calculations in the picture model, but not in the picture variant class.
w/o this change we cannot test presence of validations
A persisted reference to a renderd picture
Whenver we generate an URL for a processed image (resized, cropped or encoded in a dfferent format) we persist a thumb and return its public uid as an url for performance reasons. Next time we hit the same image it will be served by the webserver instead.
Instead of repeating this rescue logi let's rescue that where we call the chain of things.
Dragonfly sets it to the image_file name anyway. Setting it to a staitc value even if the image_file might have another filename is not reflecting actual behavior.
With the Attachment.url_class it is a extension point for alternativ url classes (ie. for remote URLs from S3)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is this pull request for?
Alchemy has image processing build in thanks to the wonderful Dragonfly gem.
The image processing though, happens on-the-fly, not up-front like in image attachment libraries like paperclip. This gives lots of flexibility and enables us to provide image cropping right in Alchemy's UI.
But it this has performance implications. Using
Rack::Cachehelps, but is not ideal for larger sites. Also larger sites will most likely use a cloud file storage like AWS S3 to store images anyway. Since Dragonfly has support for storing the master images on S3, it does not have built in support for persisting the result of a rendered image.This PR introduces (besides a lot of refactoring regarding processing images) a new active record model
Alchemy::PictureThumbthat holds thesignatureto an image transformation process (a serializedDragonfly::Job) and auidto the resulting rendered image. This uid is then returned as thepicture.url.So, the first time a picture gets rendered it processes and encodes the image and stores the result in the configured
Dragonfly::Store(defaultDragonfly::FileDataStore). For normal installation this means the thumbnail is served from thepublic/picturesfolder and usually picked up by your Webserver before it even hits the Ruby process.For installations that use S3 as its datastore the image thumbnail will be stored in the S3 bucket and the public bucket URL returned as
picture.url, so next time the picture url is hit it loads the image directly from S3.**) the latter needs the yet to be released
alchemy-dragonfly-s3gem.Checklist