Can't remove invalid image from Upload Widget queue

sitdev
sitdev Member Posts: 3

We are using the Upload Widget using the following default options merged with additional per-instance options to restrict the allowed image dimensions:

const defaultOptions = {
  cloudName: '***',
  uploadPreset: '***',
  sources: ['local', 'url', 'dropbox', 'google_drive'],
  multiple: false,
  maxFiles: 1,
  clientAllowedFormats: ['image/jpeg', 'image/png'],
  maxFileSize: 1024 * 1024 * 2, // 2 MB
  validateMaxWidthHeight: true,
  thumbnails: false,
}

const instanceWidth = 750
const instanceHeight = 750

const instanceOptions = {
  maxImageWidth: instanceWidth, 
  minImageWidth: instanceWidth,
  maxImageHeight: instanceHeight, 
  minImageHeight: instanceHeight,
}

window.cloudinary.createUploadWidget(
  {
    ...defaultConfig,
    ...instanceOptions,
  },
  (error, result) ⇒ { /* Callback */ }
)

Because validateMaxWidthHeight is set, the Upload Widget blocks the upload of an image that's not 750x750 (in this case). However, after closing the widget and re-trying with a new image that has the correct dimensions, the invalid upload is still showing in the queue, even though the widget is set to single-image mode.

There doesn't seem to be a way to remove the invalid upload on this screen, and the Done, Abort all and Retry failed buttons are all disabled or do nothing. Because the valid image still fires the "success" event, we can still add the resulting URL to the containing form data and work around this awkward screen by closing with widget programmatically after the "success" event. However, is there a better solution where we don't end up with both an invalid and a successful image on this screen? The Docs state that using validateMaxWidthHeightis supposed to cancel an invalid upload, however this doesn't seem to entirely true since the invalid image is still stuck in the upload queue with no obvious way to clear it.

Best Answer

  • Wissam
    Wissam Member, Cloudinary Staff Posts: 103
    Answer ✓

    Hi there,

    Thank you for sharing your input and workaround.

    I will share your input internally to improve the behavior.

    Best Regards,

    Wissam

Answers

  • moip
    moip Cloudinary Staff Posts: 3

    Hi there,

    To reset the widget state (line 83,84 of https://jsfiddle.net/7boes0vh/

      myWidget.close();
      myWidget.open();
    

    Regards,

    Mo

  • sitdev
    sitdev Member Posts: 3

    Thanks for putting together that example. However, this doesn't actually clear the queue or fix the state of that queue screen; it just moves the widget back to the upload source screen, which isn't helpful to the user, who just finished uploading an image and needs feedback in the UI. Is there a way to skip showing that queue screen completely?

  • Wissam
    Wissam Member, Cloudinary Staff Posts: 103

    Hi there,

    To reset the Cloudinary upload widget, you can use the destroy method followed by initializing a new instance of the widget.

    // Destroy the current instance  
    myWidget.destroy();

    // Initialize a new instance of the widget
    myWidget = cloudinary.createUploadWidget({…..


    You can read more about the destroy method in the following documentation:
    https://cloudinary.com/documentation/upload_widget_reference#destroy

    Best Regards,

    Wissam

  • sitdev
    sitdev Member Posts: 3

    Actually, I found a way to avoid seeing that screen without resetting anything, by using the hide()method on the upload-added event and then handle all error and success states outside the widget:

    let resultMessage, url
    
    const widget = cloudinary.createUploadWidget(options, (error, result) => {
      if (error) {
        resultMessage = error.statusText // display error message on page
        widget.close()
        return
      }
      if (result.event === 'upload-added') {
        widget.hide()
        return
      }
      if (result.event === 'success') {
        url = result.info.secure_url // set image url
        widget.close()
      }
    })
    

    While this works, I still think that we shouldn't have to do this manual workaround to avoid seeing that broken queue screen. What's the best avenue to officially report this defect? Thanks.