Image upload failures when using Gutenberg gallery block.

[talldanwp]

Transferring a Gutenberg issue from Github over to trac:
​https://github.com/WordPress/gutenberg/issues/8935

Many users are experiencing a "The response is not a valid JSON response" error when uploading images, usually caused by a timeout on the server.

In response to this, there was a change to the client side code in Gutenberg to upload images serially rather that in parallel. This improved things, but the error still seems to be happening for some users.

In my own testing I had to use multiple huge images to reproduce an error. Errors happened much more frequently uploading directly to the gallery block than when using the standard media uploader—I'm not sure if there's a chance the REST endpoint might be somehow less optimised than the async-upload endpoint that the media library uses.

Some details of the timeouts I received are here:
​https://github.com/WordPress/gutenberg/issues/8935#issuecomment-466306820

[Blamedutchie]

Before the update to WP5.1, in my case there was never an issue with file-sizes or time-outs. There was simply not enough time between adding the image/gallery block and the JSON error to be connected to a time-out. Also, all image files are below 1MB and on this host I have never had a problem before Wordpress 5/Gutenberg.

After the update to WP5.1 I no longer see the JSON error, but updating posts that contain images or galleries still give the red Updating failed banner, while the post does get updated.

Interestingly, I am also using the Meow Gallery Block plug-in and whether I use the media gallery OR an upload to add a gallery, the click here to refresh the preview link shows no gallery in the editor. When using the standard Gallery Block, galleries show as expected.

In both cases, although the red Updating failed banner shows, the post gets updated.

Cutting around corners: I wonder if we are looking at a JSON issue or a Gutenberg editor design flaw... Maybe connected to updating existing sites? Legacy php/html giving problems?

To make things even more intriguing; I have copied my site in a VirtualBox / Turnkey appliance, using the same theme and the same plug-ins and never do I receive a JSON or Updating failed error, even though the Virtualbox (deliberately) allows for smaller uploads and has a lower memory limit. The Virtualbox has cUrl enabled, the live site hasn't, but as far as I know, that should not be an issue when editing posts - it never was...

Tried a new post on the live site... Instead of the red Updating failed there is the red Publishing failed banner... Post gets published anyway.

I'm lost.

Live site: Ubuntu 16.04.1 / Apache 2.4.18 / PHP 7.0.33 / MySQL 5.7.25 / WP 5.1
Virtualbox: Debian 9.4 / Apache 2.4.25 / PHP 7.0.33 / MySQL 5.7.25 / WP 5.1

[subrataemfluence]

Not sure if my issue relates exactly with what @Blamedutchie but I also came across both Publishing failed and Updating failed issues quite a few times while working on version migration. It did not only happen with pages having images, it happened with full textual posts as well.

But for me it was not kind of a persisting issue for every post with images, but with some it came up. And yes, every time the post actually got published / updated in the background.

[Blamedutchie]

Replying to subrataemfluence:

But for me it was not kind of a persisting issue for every post with images, but with some it came up. And yes, every time the post actually got published / updated in the background.

That is exactly what makes investigating these issues so difficult. I've spent most of the past weeks trying to figure out what is (not) going on, but I'm at the end of my rope. Especially because a near exact copy runs flawless. #beatsheadagainstwall

[azaozz]

@subrataemfluence @Blamedutchie could you look in the browser tools "Network" tab for the returned value from the server when you see these JSON errors. Any unexpected output from PHP may cause therm, could perhaps be coming from something else like PHP notices, etc.

Looking at ​https://github.com/WordPress/gutenberg/issues/8935#issuecomment-466306820, this is the same old problem with creating image sub-sizes. Large images take a lot of time and server resources to process/resize. Currently all sub-sizes are created in the same PHP run. That sometimes fails on low powered servers or web hosting accounts with restricted resources when uploading very large images.

There is a ticket and a patch to fix this by separating the creation of image sub-sizes, #40439. If the failures are caused by the same issue, perhaps this should be closed as a duplicate.

[Blamedutchie]

@azaozz

Sorry for the late reply, I've been busy.
In some forum someone mentioned that the W3TC plug-in could have something to do with the issue, so I dived into its settings. To my surprise, there was a "cache admin pages" set to true... I never saw this setting, so I assume it came with one of the W3TC updates. I see no reason to have such a setting, why would any administrator want to see cached data, when working on a site. Changing the setting to false, appears to have solved the issue for me.

Oops! I see that I unintentionally set the resolution to invalid. I was hoping that editing this comment would also give me the opportunity to change the status again. My bad, sorry!

[spacedmonkey]

Related: #39553

[mredodos]

i have same issue on my multisite network with video upload.

[azaozz]

Been looking at this (on and off) for the past few weeks. Unfortunately still can't reproduce it consistently (apart from uploading made-up 200MB images that always cause a timeout).

Many users are experiencing a "The response is not a valid JSON response" error when uploading images, usually caused by a timeout on the server.

Wondering if we can add better error message there. As far as I see "not a valid JSON response" is most often caused by extra content like PHP notice appended to the JSON, HTTP 404, 403 or 500 error, and by a server timeout (connection closed). Knowing the exact cause would help to resolve this a lot, and also be a great addition to Site Health for WP 5.2.