Make media upload "HTTP error." more user-helpful

[kirasong]

Since the introduction of the Media Gallery in WordPress 3.4, the error messages when users attempt to upload media have been reduced to a detail-less “HTTP error.”, without any suggestion as to how users can move forward, and limited information for users to be able to contact their hosts to get help.

This is user hostile, and not in line with many of the assertions in ​WordPress Philosophy.

There’s no doubt that error messages must exist, but they should be useful, providing next steps for users.

A few possible parts/steps of this:

• Retry
• Auto Retry
• Better error messages where possible (Timeout, Out of Memory, in user terms)
• Expand for Exact Details to give to host (or WP_DEBUG enables this?)
• Troubleshooting Steps, or link to troubleshooting steps

This should be possible to accomplish in stages, which will likely each need their own tickets.

One of the first steps for "Retry" is to make image upload/thumbnail creation able to be resumed, rather than only adding the meta after all sizes are created.

[kirasong]

"HTTP error." -- This one was after a timeout.

[SergeyBiryukov]

Since the introduction of the Media Gallery in WordPress 3.4, the error messages when users attempt to upload media have been reduced to a detail-less “HTTP error.”

FWIW, that message wasn't new in 3.5 media overhaul, it existed since the introduction of SWFUpload in 2.5, see [6659]:
​http://geek.thinkunique.org/2008/03/30/fix-wordpress-25-upload-error-http-error/

[SergeyBiryukov]

#39810 was marked as a duplicate.

[kirasong]

As noted in the Slack mention above, @joemcgill and I met about this ticket a bit at Loopconf regarding what would be necessary for the first steps here.

They look something like:

• Improve JS handling of http error codes and body, to provide more detailed error messages
• Save progress of meta/multi_resize during creation of the intermediate images (with save basic meta before starting resizing process)
• Resume multi_resize without re-uploading the file

I've got a pretty good idea of what the latter two will look like, but any insights of the JS handling -- in particular, why we're not surfacing any error details -- would be appreciated. I remember that there were technical challenges (rather than deciding the information was not helpful) involved in resolving this, but do not remember all of the background.

I don't think it necessarily needs to happen in this order, as making it so that thumbnail resizing resumes in any form will help more users be successful in getting their images uploaded (and eventually not having the HTTP Error show up).

[zodiac1978]

It seems that the JSON Response sometimes contains some useful information which could (should?) be used.
​https://sebastian.expert/fix-wordpress-an-error-occurred-in-the-upload-please-try-again-later/

As a moderator in the German support forums this is often a problem for beginner. They just get this "HTTP error" and they do not know what to do.

They don't know too, that specials characters (or combining characters) are not a good idea for file names. See: #24661, #22363, #35951, #30130

[kirasong]

See #40439 for the "Save progress in meta" part noted above.

[pengriffix]

I got this when i tried uploading an image of 2mb. How can i fix this. ​https://vevomack.blog/jaden-smith-u/

[kirasong]

Replying to pengriffix:

I got this when i tried uploading an image of 2mb. How can i fix this. ​http://rapbible.me/wp-content/uploads/2017/06/screenmunch.png

This ticket is about making this error show what the actual problem is -- as in, just seeing that it is an HTTP error could mean many things at this point (which is frustrating, I agree!).

I'd suggest asking in the ​support forums, since usually seeing "HTTP Error" does not indicate a bug in WordPress core.

[ramcharan25]

am having the same problem ... ​https://instrumentalfx.co/wp-content/uploads/2017/09/Screenshot-2017-9-23-Upload.png

[kirasong]

See #43525 for retry/auto-retry.

[SergeyBiryukov]

#47450 was marked as a duplicate.

[ramon fincken]

I have been working in catching the PHP error using a 6 second timeout and @azaozz' multi subsizes plugin https://core.trac.wordpress.org/ticket/40439#comment:48

What happens : we add

<?php
header( 'X-WP-lasterror-message: ' . $r['last_error_message'] );

which can be read in the JavaScript frontend. (yes it will need more user friendly-ness)

It needs this PHP patch plus this for JS
OPEN
wp-includes/js/plupload/handlers.js

FIND

function uploadError(fileObj, errorCode, message, uploader) {

REPLACE WITH

function uploadError(fileObj, errorCode, message, responseHeaders, uploader) {

FIND

		case plupload.HTTP_ERROR:
			wpQueueError(pluploadL10n.http_error);
			break

REPLACE WITH

		case plupload.HTTP_ERROR:
			
			message = pluploadL10n.http_error;

			var myRegexp = /x-wp-lasterror-message: (.*)/gm;
			var match = myRegexp.exec( responseHeaders );
			if( match[1] ) {
				message += ' ' + match[1];
			}

			wpQueueError(message);
			break

FIND

		uploader.bind('Error', function(up, err) {
			uploadError(err.file, err.code, err.message, up);
			up.refresh();
		});

REPLACE WITH

		uploader.bind('Error', function(up, err) {
			uploadError(err.file, err.code, err.message, err.responseHeaders, up);
			up.refresh();
		});

[ramon fincken]

patch.39647

[ramon fincken]

result of a timeout message

[azaozz]

Looking at this again, thinking it will need to be more "integrated" with Site Health somehow. See #45933 and #44458.

Basically timeouts and out-of-memory errors while uploading an image are an exception from the general "fatal error" handling. In addition the AJAX responses are... "hacky" (they don't use wp_send_json_success|error) but the response is expected to be json for the Media Modal.

Also thinking it won't be enough to just show the cause for the fatal error. It should include "next step" or "try this now" part too (see changes to the default HTTP 500 error messages while uploading in #47872).

[ramon fincken]

yes it will be better, my intentions are to set this up in order for another ticket/patch to sort of "translate" the error messages even better so real humans (end users) are able to go further at the point of error occurance

[ramon fincken]

Better patch with PHP and JS this time.
Rewritten to match latest trunk.

And .. does not expose the error to the world using this (and a filter thereafter)

$sent_header = ( WP_DEBUG || ( is_user_logged_in() ) );

If you want to test this you might need to disable this in handlers.js because it will loop forever in the current trunk versioning @azaozz

			// If the file is an image and the error is HTTP 500 try to create sub-sizes again.
			if ( status === 500 && isImage ) {
				tryAgain( up, error );
				return;
			}

More info on that in ticket #47872 https://core.trac.wordpress.org/attachment/ticket/47872/47872.diff

[ramon fincken]

patch.39647.20190920.1

[SergeyBiryukov]

#48135 was marked as a duplicate.