Make WordPress Core

Opened 8 years ago

Last modified 5 years ago

#39647 new defect (bug)

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

Reported by: kirasong's profile kirasong Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.4
Component: Media Keywords: needs-testing has-patch
Focuses: ui, administration Cc:

Description

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.

Attachments (4)

Screen Shot 2017-01-19 at 10.53.10 PM.png (13.7 KB) - added by kirasong 8 years ago.
"HTTP error." -- This one was after a timeout.
patch.39647 (1.3 KB) - added by ramon fincken 5 years ago.
patch.39647
ticket_39647.png (49.4 KB) - added by ramon fincken 5 years ago.
result of a timeout message
patch.39647.20190920.1 (2.7 KB) - added by ramon fincken 5 years ago.
patch.39647.20190920.1

Download all attachments as: .zip

Change History (39)

@kirasong
8 years ago

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

#1 @SergeyBiryukov
8 years ago

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/

This ticket was mentioned in Slack in #core-media by mike. View the logs.


8 years ago

#3 @SergeyBiryukov
8 years ago

#39810 was marked as a duplicate.

This ticket was mentioned in Slack in #core-media by mike. View the logs.


8 years ago

#5 @kirasong
8 years ago

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).

This ticket was mentioned in Slack in #core-media by mike. View the logs.


8 years ago

#7 @zodiac1978
8 years ago

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

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


8 years ago

This ticket was mentioned in Slack in #core-media by mike. View the logs.


8 years ago

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


8 years ago

#11 @kirasong
8 years ago

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

This ticket was mentioned in Slack in #core-media by mike. View the logs.


8 years ago

This ticket was mentioned in Slack in #core-media by mike. View the logs.


7 years ago

#14 follow-up: @pengriffix
7 years ago

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

Version 1, edited 7 years ago by pengriffix (previous) (next) (diff)

#15 in reply to: ↑ 14 @kirasong
7 years ago

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.

This ticket was mentioned in Slack in #core-media by desrosj. View the logs.


7 years ago

#18 @kirasong
7 years ago

See #43525 for retry/auto-retry.

This ticket was mentioned in Slack in #core-media by mike. View the logs.


7 years ago

This ticket was mentioned in Slack in #core-media by mike. View the logs.


6 years ago

#21 @kirasong
6 years ago

  • Milestone changed from Awaiting Review to Future Release

#22 @SergeyBiryukov
6 years ago

#47450 was marked as a duplicate.

#23 @ramon fincken
5 years ago

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();
		});
Last edited 5 years ago by azaozz (previous) (diff)

@ramon fincken
5 years ago

patch.39647

@ramon fincken
5 years ago

result of a timeout message

This ticket was mentioned in Slack in #core-media by ramonfincken. View the logs.


5 years ago

#25 @ramon fincken
5 years ago

  • Keywords needs-testing has-patch added

This ticket was mentioned in Slack in #core-media by ramonfincken. View the logs.


5 years ago

This ticket was mentioned in Slack in #core-media by mike. View the logs.


5 years ago

This ticket was mentioned in Slack in #core-media by mike. View the logs.


5 years ago

This ticket was mentioned in Slack in #core-media by mike. View the logs.


5 years ago

#30 @azaozz
5 years ago

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).

This ticket was mentioned in Slack in #core-media by mike. View the logs.


5 years ago

#32 @ramon fincken
5 years ago

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

#33 @ramon fincken
5 years ago

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
5 years ago

patch.39647.20190920.1

This ticket was mentioned in Slack in #core-media by ramonfincken. View the logs.


5 years ago

#35 @SergeyBiryukov
5 years ago

#48135 was marked as a duplicate.

Note: See TracTickets for help on using tickets.