Wp-calypso: (8P) Editor: no warning or error given when adding media to media blocks that cause site to exceed storage limit

[designsimply]

Steps to reproduce:

1. For a WordPress.com Free site, go to My Sites > Site > Media.
2. Add items until you run out of space.
3. Go to My Sites > Site > Posts > Add new post.
4. Add a title and an image block.
5. Drag an image onto the block that exceeds the site storage limit.

Result: I expected to see a warning about going over storage capacity, but no error ever appears and the spinner seems stuck. You never get a warning or error message but you can see a quick preview of the image uploading even though the upload won't ever go through! (11m58s)

^{Tested using Safari 13.1 macOS 10.15.4 on WordPress.com Free site gotravelrewards.blog logged in as testuser0313 unproxied.}

[davemart-in]

~Note: For Business and eCommerce customers who signed up prior to August 2019 we need to make it so that the 200GB upload quota does not apply and they do not see any upload error messages. Let's chat about this once this issue gets picked up.~

Edit by @marekhrabe: separated into #44930, not part of this task anymore

[obenland]

Notes from Backlog Grooming:

• 90% sure image uploads can show an error (at least a generic one) when the upload fails.
• maybe we are just returning it wrong from the endpoint and the block editor doesn't understand things have failed?
• It’s important to keep in mind how the file was trying to be uploaded since there are different handlers. MediaPlaceholder, MediaReplaceFlow, just dropping in the editor canvas (don’t know whats the component here, guessing some embed?). This seems to be a MediaPlaceholder component
• For all blocks supporting any kinds of uploads, there is a shared part of the code and a custom one specific to this block. we need to definitely determine where this fits as we might be affecting many blocks (and we might want to, as the upload limit goes far beyond just images)

[obenland]

I also wonder if it's connected to how these space errors are returned from the API, with that | as mentioned in https://github.com/Automattic/wp-calypso/issues/43783#issuecomment-651859534

[obenland]

Testing with add_filter( 'get_space_allowed', '__return_zero' ); I get the following error:

I'll try and replicate differently.

In image blocks it's using the wp/v2/media endpoint, so the bug mentioned in https://github.com/Automattic/wp-calypso/issues/43783#issuecomment-651859534 is not the cause here.

[designsimply]

I re-tested this issue today and found the problem is still happening where if I drag an image into the block editor on a blog where the storage limit has been reached then the media upload fails silently without giving a helpful error message. (13m32s)

This is what I saw after giving up after ~12 minutes and closing then re-opening the post:

^{Tested using Safari 13.1.1 macOS 10.15.4 on WordPress.com Free site gotravelrewards.blog logged in as testuser0313 unproxied.}

Next level: instead of saying 14 KB needed, consider adding a call to action such as "Upload limit has been reached. Please review your plan." I didn't find the "14 KB needed" part of the message very helpful from a user perspective. Let me know if you'd like me to open a separate issue for this part!

[obenland]

It works fine in Chrome but I was able to reproduce it in Safari when dragging an image into the block editor without adding a block first. It looks like the API request to upload the image never fires, so I wonder if it's a Gutenberg bug on multisites in Safari.

[designsimply]

I couldn't get it to work in Chrome! 😕 (1m13s)
^{Tested using Chrome 84.0.4147.125 macOS 10.15.4 on WordPress.com Free site gotravelrewards.blog logged in as testuser0313 unproxied.}

[mreishus]

Unable to reproduce in linux/firefox/80.0b8, linux/chromium/85, ios/safari/13.6.1.

Test Steps:

• Added filter add_filter( 'get_space_allowed', '__return_zero' ); to sandbox.
  
  
  
  • Also tried add_filter( 'get_space_allowed', function () { return 5; } ); in case 0 was a special case.
  
  
• Site used: testsite10mmr while sandboxed
• Verified media library showed 100% space used
• Created new post
• Desktop browsers:
  
  
  
  • New image block, click upload
  
  
  • New image block, drag into image blocka
  
  
  • Drag image into empty space without adding an image block
  
  
• Mobile Browser:
  
  
  
  • New image block, click upload
  
  

In all cases I saw the "Not enough space to upload. 2,453 KB needed" message.

Above we have reports of the issue happening in mac/chrome/84 and mac/safari/13.1.1. I'm also wondering if there's something other than the browsers causing the different results.

[frontdevde]

logged in as testuser0313 unproxied.

@mreishus Not sure it could be related but just in case have you tried whether proxied/unproxied yields a different result?

[mreishus]

Hmm, have not, I was proxied the entire time I was testing. That could be it.

[cpapazoglou]

Switched to User through store admin and I can reproduce it. It only happens when user drags an image to the canvas. I will report later my findings or just fix it.

[cpapazoglou]

The problem derives from the fact that add_filter( 'get_space_allowed', '__return_zero' ) returns no available space at all where in fact the reality is totally different for most of our users. Let's say a user has 1mb left space, uploading an image of exact 1024kb would be very surprisingly and rare. Let's assume they upload an image of 1000kb. The space left then would be 24kb insufficient for any image upload.

Cases:
1) uploading through the media library or the image block return the correct error (the api is triggered)
2) dragging the image to the editor stalls, the api is never triggered

Steps to reproduce (2)

• Got to /wp-admin/upload.php in your sandbox
• Check how much space you have available
  
• Go to /wp-admin/options.php
• Change the blog_upload_space so that you have available less than 100kb (value should be in mb, accepts decimal). Be careful to note down the previous value
• Go to the editor, open the network in developer tools
• Go to the editor, drag n drop an image > 100kb
• You will see that the image is converted from blob but then the api is not triggered

I assume it is something Gutenberg related as the user suggested they have seen this behaviour again in a non WordPress.com site. I keep digging.

[cpapazoglou]

To debug Gutenberg on your environment you may use pc9Uba-1F-p2

Adding a debugger here may give you a headstart
https://github.com/WordPress/gutenberg/blob/4405e7ba37cdf1ea1249a8dd5799952b3b757bf5/packages/components/src/higher-order/with-notices/index.js#L92-L105

[jeryj]

I think I've tracked down the issue. I'm not sure how best to solve for it, but here's what's happening:

• The uploader uses maxUploadFileSize to determine if we should open a request or not to upload the file
• It assumes that maxUploadFileSize will be consistent
• it uses wp_max_upload_size() to set it
• On multisites, wp_max_upload_size() is actually variable determined by the maximum file size OR the amount of space left after it gets filtered through this function:

function upload_size_limit_filter( $size ) {
    $fileupload_maxk = KB_IN_BYTES * get_site_option( 'fileupload_maxk', 1500 );
    if ( get_site_option( 'upload_space_check_disabled' ) ) {
        return min( $size, $fileupload_maxk );
    }

    return min( $size, $fileupload_maxk, get_upload_space_available() );
}

• Back to Gutenberg... If there’s not enough space left when you try to upload a file, it returns the error without ever trying to upload the file
• Our error messages are waiting for an error response from the API, which never happens, because the request never goes through.

After removing that check for the maxUploadFileSize in order to force an upload, we get this correct behavior when dragging an image onto the editor canvas:

I'm not sure what the best route to fix this would be. Do we:

• Use a different function than wp_max_upload_size() to set the maxUploadFileSize so that it's consistent?
• Change the behavior of `wp_max_upload_size() in core so that it's always consistent?
• ... something else?

[cpapazoglou]

Thanks @jeryj for looking into this. From my point of view, the problem is that wp-calypso (or Gutenberg) doesn't do anything (?) on the error reported by Gutenberg. It seems like a callback function is not firing or a render doesn't happen.

Back to Gutenberg... If there’s not enough space left when you try to upload a file, it returns the error without ever trying to upload the file

In fact, it is far better to prevent the upload itself and show the error than wait for the API to respond with the error. This way:

• we can provide a faster experience to the User
• use less server resources.

Actually, I assume we need to fix the following
https://github.com/WordPress/gutenberg/issues/21559

[jeryj]

Actually, I assume we need to fix the following
WordPress/gutenberg#21559

Agreed! That looks like one of the issues. I guess there are two separate things:

1. The image drag/drop into the canvas max upload size is not being caught correctly.
2. The maxUploadFileSize is not always the correct error. We should have a way to catch the difference between a file being uploaded that is too large for the system vs a file that is exceeding the amount of space left on the server.

[cpapazoglou]

The maxUploadFileSize is not always the correct error. We should have a way to catch the difference between a file being uploaded that is too large for the system vs a file that is exceeding the amount of space left on the server.

You are right @jeryj! Thanks for bringing this up! It seems that they used maxUploadFileSize as a shortcut for two different things. Are you up on creating a separate issue to address/triage it?

[cpapazoglou]

I have tested and reviewed the following PR which will ultimately close the current issue
https://github.com/WordPress/gutenberg/pull/24398

[jeryj]

Issue created for the incorrect Gutenberg upload error message: https://github.com/WordPress/gutenberg/issues/24948

[cpapazoglou]

I created a new PR so we can make progress faster
https://github.com/WordPress/gutenberg/pull/25004

[cpapazoglou]

The PR is merged, so the fix will be shipped with the next Gutenberg version in WordPress.com