conditional versions - not processed but versions still created

[jasper502]

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]

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]

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]

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]

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]

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..

[mshibuya]

There are 2 points coming into play:

• About the Fog file presence issue. I realized CarrierWave::Storage::Fog::File doesn't implement #empty?, where CarrierWave::SanitizedFile does. That's causing the behavior difference.
• For behavior of #version_exists?. It's named misleadingly, because what it does is just check if the conditionals given for the version are satisfied or not, regardless of existence of the file. So I think it's better to rename it like #version_active?, to reduce confusion like this.