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

conditional versions - not processed but versions still created #1926

Open
jasper502 opened this issue Apr 22, 2016 · 4 comments
Open

conditional versions - not processed but versions still created #1926

jasper502 opened this issue Apr 22, 2016 · 4 comments

Comments

@jasper502
Copy link

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
Copy link
Author

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
Copy link

hmistry commented Apr 23, 2016

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
Copy link
Author

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
Copy link

amenon commented Aug 15, 2016

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.

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

3 participants