Skip to content
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

Exported transloadit derivatives not using pretty_location? #9

Closed
ksouthworth opened this issue Oct 30, 2020 · 2 comments
Closed

Exported transloadit derivatives not using pretty_location? #9

ksouthworth opened this issue Oct 30, 2020 · 2 comments

Comments

@ksouthworth
Copy link

I've got my Transloadit transloadit_processor and transloadit_saver methods hooked up as shown in the docs here:
https://github.com/shrinerb/shrine-transloadit#usage

after calling

attacher.transloadit_save(response["results"])
attacher.derivatives

my derivatives are there, however their paths on the storage (S3) seems to be using the default locations, instead of going through the code I have in my custom generate_location(io, name: nil, record: nil, derivative: nil, metadata: {}, **options) method as part of the pretty_location plugin.

In my generate_location implementation I'm nesting files underneath a few directories, something like

accounts/{account_id}/responses/{response_id}/videos/{video_id}

This is working for the main file when I upload it through Shrine, but not for any of the derivatives I'm pulling in via the transloadit_saver and merge_derivatives methods.

Basically, the uploaded file is being correctly stored at the S3 path:

accounts/123/responses/456/videos/789/original.webm

but the derivatives coming in via shrine-transloadit are not, instead shrine is sticking them at the root of the storage in a path like:

bc/97dbdbdc9d4f02be1475d647b263da/original-14a4d011c346d4b657467cd4b7bb74d6.webm

Is there a way to make these transloadit derivatives go through the same pretty_location logic so I can store them alongside the original?

Thanks!

@janko
Copy link
Member

janko commented Oct 31, 2020

Yes, Shrine won't use its own #generate_location method, as it doesn't have all the information this method might expect.

You can pass the :path parameter to the #transloadit_export_step method you're calling in your Attacher.transloadit_processor block, which will get forwarded to the underlying step, e.g:

import = file.transloadit_import_step
encode = transloadit_step "encode", "/video/encode", use: import

# pass derivative name, filename metadata for extension, and attacher context
encode_location = store.generate_location(nil, derivative: :encoded, metadata: { "filename" => "name.mp4" }, **context)
export = store.transloadit_export_step use: encode, path: encode_location

assembly = transloadit.assembly(steps: [import, encode, export])
assembly.create!

@ksouthworth
Copy link
Author

@janko your recommendation is working, thanks!

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

No branches or pull requests

2 participants