Custom Error Messages in the Upload Widget?

Comments

8 comments

  • Official comment
    Avatar
    Gil Noy

    Hey David,

    Thanks for your feedback, we opened a feature request that will be handled in future releases. Currently there is no ATA

    Hope this helps, please let me know if you have any further questions.

    Best

     

    Gil

    Comment actions Permalink
  • Avatar
    Raya Straus

    Hi Ross,

    It currently, not possible to customize the display error.

    Please let us know if you have any other questions.

     

     

     

     

    0
    Comment actions Permalink
  • Avatar
    David Ziegelheim

    This is a major issue. It isn't just a file is too large. It is also an image is too small or image is too big. Or image is of the wrong type.

    In a deployed application, a user trying to upload an image at 3 am can't be left with an obtuse error message and no recourse. Nor is there a way to determine if the image doesn't meet the criteria before it is uploaded and it is too late after it is uploaded.

    Fixing this should be a very high priority. 

    1
    Comment actions Permalink
  • Avatar
    Shirly Manor

    Hi David,

    When using our upload widget version 2.0 you have an option to set part of the errors.

    Fro the server you can set the file too large error in the upload widget:

    {uploader: {errors: {file_too_large: “File size ({{size}}) exceeds maximum allowed ({{allowed}})” } } }

     

    And from the client side, you can set the:

    “max_dimensions_validation”: “Image dimensions ({{width}}X{{height}}) are bigger than the maximum allowed: ({{maxWidth}}X{{maxHeight}})“,
    “min_dimensions_validation”: “Image dimensions ({{width}}X{{height}}) are smaller than the minimum allowed: ({{minWidth}}X{{minHeight}})”

     

    You can learn more about our new upload widget here:

    https://cloudinary.com/documentation/upload_widget_2

    0
    Comment actions Permalink
  • Avatar
    Adam

    I've run into this as well during an evaluation of this service and it is a roadblock -- the way the widget handles errors is extremely user unfriendly.

    The example given isn't very clear, but for anyone else it appears the error message customization is done via the locale strings when defining the widget:

    var widget = cloudinary.createUploadWidget({
      text: {
        "en": {
          "uploader": {
            "errors": {
              "file_too_large": "File size ({{size}}) exceeds maximum allowed ({{allowed}})"
            }
          }
        }
      }

    }

    However, it appears that it doesn't properly substitute the size variables even though indications are that it should.  With the above configuration the message that gets output is : "File size () exceeds maximum allowed ()"

    Also, the error data available isn't particularly helpful -- it contains a "status" and "statusText" field, which both contain the error message.  Shouldn't status be something like a constant (eg "file_too_large") to make it easier to identify as an error type?

    Considering the last response here was 8 months ago as of this writing and there are currently no error handling customizations available it doesn't seem like this is a priority or has any kind of reasonable solution.  It's too bad, things looked pretty good up to this point.

    As an aside - I'm not sure why this WYSIWYG doesn't allow <pre> blocks given the fact that there could be code examples involved in a lot of situations.

    0
    Comment actions Permalink
  • Avatar
    Ido

    Hi Adam,

     

    I've confirmed with our product and dev teams that the customization of errors for the upload widget is indeed still being reviewed and is actively being looked at. 

    Regarding the incorrect variable unfurling, I've tried to reproduce this and I manage to see customized errors correctly. Could you share your implementation of the widget so we could take a closer look?

     

    Regarding the fields for errors ('status' and 'status text'), We'll take that internally as well and see how to approach this.

    0
    Comment actions Permalink
  • Avatar
    Adam

    The variable unfurling is working correctly.  I failed to notice that the syntax coincides with the syntax for my template engine, which I have corrected.

    0
    Comment actions Permalink
  • Avatar
    Ido

    Great, glad to hear!

     

    Let us know if there are anymore questions

    0
    Comment actions Permalink

Please sign in to leave a comment.