Unable to upload 2500x1667 image

[zarino]

Paging @sagepe. This is a fun one.

@MyfanwyNixon tried to upload an image of a tower block. The file was 2500x1667 pixels, weighing in at about 2 MB size. The upload failed, with WordPress displaying this error:

Post-processing of the image failed. If this is a photo or a large image, please scale it down to 2500 pixels and upload it again.

Resizing the image down to something smaller, like 2000x1334 (0.8 MB) worked, but a 2495-pixel wide one didn’t.

It would be good to identify what was causing the 2500-pixel image to fail. It should pass WordPress’s big_image_size_threshold, so I’m wondering whether actually WordPress was running out of memory while trying to generate the thumbnails, and 2000x1334 is luckily just about small enough that it doesn’t trip the memory limit. Or something.

[MyfanwyNixon]

Actually, just to correct this. I downloaded the image to my own PC and resized it to 1,200 px width in Photoshop before attempting to upload.

[sagepe]

This might be because of the PHP settings - they are quite conservative in the docker container, upload_max_filesize is 2MB, so this might have triggered something under the hood. You used to get a clearer error message though.

There is a vast thread about this on the Wordpress forum. That seems to be conflating lots of underlying problems that result in the same error.

I could try building a new image with the various PHP variables increased if this is a major issue.

[zarino]

This happened again, with a 1.8 MB, 899 × 1599 pixel PNG. The Image block attempts to upload the file via ajax, but gets a "413 Request Entity Too Large" response from the server, and displays a "The response is not a valid JSON response" error back to the user:

When I converted the PNG to a JPEG on my Mac (taking the filesize down to 150 KB), the upload worked. As you’d expect.

It’s still tempting to delay fixing this until the site is moved off the temporary staging host. But Danielle’s starting to use the site in anger now, and it’s a bit rubbish that uploading images isn’t working consistently for her.

@sagepe how long do you think it’d take you to rebuild the docker image with more generous filesize limits?

[sagepe]

It shouldn't be too difficult, I'll take a look and see if I can do one quickly, if not I'll update here with an expectation for when I'll be able to get it sorted.

[sagepe]

PHP settings have been adjusted, the limits are now 64MB so hopefully enough - that should at least eliminate this as the root cause, anyway.

[sagepe]

@zarino - has there been an opportunity to test this?

[zarino]

@sagepe Sorry, no, I haven’t tested it again with the same image that was causing problems before.

[sagepe]

I think that there are two separate issues here.

Sadly, the issue that @MyfanwyNixon noted doesn't seem to be affected by the file size changes - I've just done some testing. I suspect that the different error seen by @zarino may be, thoug

The 2500 pixel issue may be a bug in Wordpress 5.3 and PHP 7.3, however, which is what we're using. I'll try rebuilding the container based on a PHP 7.2 image instead as this appears to be one of the solutions suggested.

[sagepe]

The issues remained with PHP 7.2, but I've made some tweaks to the nginx proxy config in the stack and also to our internal load-balancers and this now worked for an image up to around 5000X4000px - this is a bit of an edge case; it takes quite a few seconds for Wordpress to process so you have to ensure the various elements of the stack work together correctly so as not to time out or fail in other ways. In this case, we needed a combination of timeouts at the load balancer together with various buffer and file size changes within PHP and Nginx.

I suspect that this problem could manifest in various ways depending on the exact architecture of the stack used in the final deployment. Wordpress is processing larger images and this sometimes takes time. I suspect the reason there is a lot of confusion on various fora is because of the many factors involved - the time taken in the processing step and how the rest of the stack reacts to this is going to vary for almost every deployment.

This may not fix the issue for every possible case, but should for almost all reasonable ones. It's also worth clearing your browser cache if you see this error, too. We may need to test again once we've done the production deployment.

[zarino]

Thanks @sagepe. We’ll close this ticket for now, and open a new one if the problem comes back.