carrierwaveuploader / carrierwave

Classier solution for file uploads for Rails, Sinatra and other Ruby web frameworks
https://github.com/carrierwaveuploader/carrierwave
8.78k stars 1.66k forks source link

conditional versions - not processed but versions still created #1926

Open jasper502 opened 8 years ago

jasper502 commented 8 years ago

I have an uploader where the files can be pretty much anything. I wanted to make previews of images so based on the various docs I created a conditional version. My side is available here:

https://gist.github.com/jasper502/b3daff11631f62607fb758fbebeb2bec

It sort of works. The non-image files are not processed but the versions are still created. For example upload.file.small.url will always return something like /model/3/uploads/24/preview_small.jpg even if the file was not an image.

Now the even stranger part - in my local dev env if I call upload.file.small.present? I get false and in my staging env on deploy it returns true. So I had an index page where it would display either the preview image or a generic file icon. So in dev it works fine but on my remote deploy I get a page of broken images.

My interim solution will be to just do a check on the content_type again to display an image or not. I have tried to have a look in the source code to see if I could suggest a pull request but this is a bit over my head.

I will mention that in dev my storage is file and on staging I am using S3/fog. That is the only obvious difference and not sure how that would create the difference on the true / false result.

jasper502 commented 8 years ago

As a follow-up down the road I wanted to add additional conditional versions - for example for a PDF or a MS Word file etc. checking the presence off the version would really come in handy in this case vs having to check against some hash of file types or setting another attribute in the model to indicate an upload that would have a preview.

hmistry commented 8 years ago

To your point of versions being created in the uploader object but the actual file does not exist... this created a lot of initial confusion for me where I spent time trying to understand what was going on and why its doing that (documentation was not helpful).

To the creators, I think the correct behavior should be not to create any version objects until you actually give the green light to process it. Then there is consistency in the uploader object data model with what is actually there i.e. file versions that match up with uploader's versions hash.

jasper502 commented 8 years ago

I agree with @hmistry - from what I gather there is no way to even do that now. I tried wrapping the entire version block in an if block but you can't even do that in the uploader.

amenon commented 8 years ago

I ran into this issue as well, and just checking for the presence of the file does not work in my case as there could be a file with that version name for another image. I used the image.version_exists?(version_name) method to determine if there truly was a version for that image. This is the method that Carrierwave call internally when processing versions.

But it would be better if the version objects that are created actually respect the conditions.

yaroslavrick commented 1 month ago

In my case, image.version_exists?(version_name) - always returns true... which is strange.

But this can help:

tester_with_needed_avatar_version.avatar.versions[:profile_medium].file.exists? # => true 
tester_without_needed_avatar_version.avatar.versions[:profile_medium].file.exists? # => false

But this is strange, that .version_exists? work as not expected..