Base and eager transformations are not sent to cloudinary

[skwp]

I've customized the attachinary template to include some base transformations. Here's an example of what my template looks like:

<script rel="attachinary-template" type='text/html'>
    <ul>
    <% for(var i=0; i<files.length; i++){ %>
      <li>
        <img
          data-orig-width='<%= files[i].width %>',
          data-orig-height='<%= files[i].height %>',
          data-public-id='<%= files[i].public_id %>',
          src="<%= $.cloudinary.url(files[i].public_id, { "transformation": ["max_1600",{"effect":"contrast:5"},{"effect":"unsharp_mask:50"}], "eager": [{"width":96,"height":96,"crop":"thumb","gravity":"south","angle":"exif"},{"quality":85,"width":210,"crop":"limit","angle":"exif"},{"quality":85,"height":640,"width":640,"crop":"limit","angle":"exif"}], "version": files[i].version, "angle": 'exif', "format": 'jpg', "crop": 'thumb', "gravity": 'south', "width": 96, "height": 96 }) %>"
          alt="" width="96" height="96" />
        <a href="#" data-remove="<%= files[i].public_id %>">Remove</a>
      </li>
    <% } %>
    </ul>
  </script>

You'll notice there's a 'max_1600' named transformation there and some eager transformations. I noticed this stuff did not end up correctly done at cloudinary. I started digging into cloudinary.js, by placing debugging calls inside generate_transformation_string

I see that this method is entered no less than 4 times after I upload my image..each time from the Attachinary.addFile method. I'm not sure why that method is invoked 4 times for a single file upload. But the first time it is invoked, the transformation strings appear correct based on my logging.

    log("Cloudinary.js Base transformation", base_transformations);
    log("Cloudinary.js Named transformation", named_transformation);

By the second time, they are wiped out and those arrays are empty. I am digging further but this is mind boggling. First - why addFile fired 4 times, and second, why this transformation generation code is not idempotent.

[skwp]

Correction, addFile is not fired 4 times but the generate_transformation_string method is called 4 times internally to cloudinary.js. This may not be an attachinary bug. Not sure yet.

[skwp]

I think this is a cloudinary.js bug after all. Closing this - the cloudinary.js is here: cloudinary/cloudinary_js#6

[skwp]

Ok I'm getting slowly to the bottom of the issue. What I was looking at is the cloudinary public_id call which is not where the eager transformations are passed in. I now believe this is actually a form generation problem. in Attachinary::ViewHelpers.attachinary_file_field_options, we do not take into account eager or transformation options to pass to the API. I believe if I modify this method to accept such options, we'll be able to actually do the transformations as allowed by cloudinary api.

[skwp]

@assembler have you ever used eager or base transformations in cloudinary? It really looks like this plugin doesn't support it out of the box. This is what i had to add:

In my app:

      has_attachments :photos, :order => 'position ASC',
        :cloudinary => {:eager => [...array of eager transforms..], :transformation => {...}}

In Attachinary::ViewHelpers.attachinary_file_field_options

      options[:cloudinary] ||= options[:attachinary][:cloudinary] || {}

Instead of initializing it to an empty hash. This way the transformations are passed through from the model declaration. I'm not sure if you intended to pass them in some other way, but I can't figure out how to pass them in otherwise. I'm using the simple_form version of the file field.

        = form.input attachinary_field, :as => :attachinary

The other option would be to pass them as html options but that doesn't seem right. Semantically putting them on the model seems to be reasonable, although not ideal. I think it would make more sense to pass them through in the form input somehow. Thoughts?

[skwp]

So it looks like attachinary_file_field supports this just fine, but the simple form version has no way of passing the :cloudinary params.

[skwp]

Turns out cloudinary had a bug where it was erasing the transformation parameter out of the hash. You should probably update your gemfile to the latest cloudinary version. cloudinary/cloudinary_gem#61 although they didn't bump the gem version yet.