Can mount_base64_uploader also handle normal file uploads?

[jmuheim]

I want to offer the users of my website to either use a standard input type="file" or a textarea with a base64 string.

I hoped that mount_base64_uploader would accept both kinds, but it seems it doesn't. What would you recommend to implement such a behaviour?

[y9v]

Actually it already does that.

If it is not working for you, i would suggest you to check your form (i suppose you have two fields for the same property in one form, and the second one overrides the first one)

[jmuheim]

Hm and I indeed thought that I had this working already some time ago, so I was surprised, too!

I will check again what you said. Thanks for the fast response!

[jmuheim]

Okay, I tracked it down a little further:

• When creating a nested object, the upload using input type="file" works as expected
• When creating a nested object, the upload using textarea and base64 string works as expected
• When updating a nested object, the upload using input type="file" doesn't work
• When updating a nested object, the upload using textarea and base64 string works as expected

Interestingly, the option to remove an existing file of a nested object doesn't work either, regardless of whether mount_uploader or mount_base64_uploader is used.

All this seems to be only the case on nested objects. Any idea? I will check out whether my test app from the last issue shows the same behaviour.

[jmuheim]

The dummy app shows the same behaviour, I simply changed mount_uploader to mount_base64_uploader for both User and Attachment.

https://github.com/jmuheim/test-carrierwave-base64-update/blob/42e97054b30f375d2e0f37764170820f9393362b/app/models/attachment.rb

[jmuheim]

Oh, it seems to have to do with something like in the last issue! When I only change the file field, then it doesn't have any effect on update. But if I also change another field (e.g. the name), it updates correctly!

[y9v]

does the failure persist if you use the regular mount_uploader?

[jmuheim]

No, it only happens with mount_base64_uploader. And it only happens for nested objects. You can try it in the test app.

[y9v]

After a short investigation i found out, that the carrierwave gem does not marks the attribute as changed for some reason.

So i think i could just mark the attribute as changed before calling the super method from the carrierwave gem. But i'm not sure that this is correct.

[jmuheim]

Thanks for investigating this. Should we propagate this issue on the carrierwave repo?

[jmuheim]

Would you help me writing the description for the issue? I think you can do this much more precise than I can. I'm willing to write some passing/failing specs showing the problem, if needed, too.

Would be nice to have this issue created before end of the week, as I will be on holidays next week.

[y9v]

I think i actually was wrong :(

Looks like the setter method from my gem overrides the method from the carrierwave, therefor it is not marking the attribute as changed for regular files. I'm sorry for any inconvenience, and i will make a quick in the next hour.

[jmuheim]

Thanks, this is great to hear!

[y9v]

So this should be fixed in version 2.1. Sorry again for the delay

[jmuheim]

Nearly everything seems to work now, except one thing:

When updating a nested object, the upload textarea and base64 string doesn't work, as long as it's the only changed attribute

[y9v]

That's strange. Was this working before?

[jmuheim]

I can't say it. It sounds familiar, but I don't really remember.

[y9v]

Pushed a new minor version. It should fix the mentioned problem

[jmuheim]

Alright, it's working perfectly now! Thank you.

[g8d3]

It would be great if you could clarify in readme that using mount_base64_uploader will not break mount_uploader. Or some note that clarifies that this gem will allow to receive files by both an API and a form.

[y9v]

@juanpastas yep, that's a good idea.