I'm having a heck of a time with the ServerSideRender component for a Gutenberg block I'm developing. I'm seeing this error in the (non-)rendered block: Error loading block: The response is not a valid JSON response. But where can I see the actual JSON response?

In the Chrome Inspector Tools I see:

Failed to load resource: the server responded with a status of 502 ()

along with the request that was sent, with all the block attributes:


All the attributes look correct, and how they're handled in the PHP render callback is looking correct. I had the ServerSideRender working until yesterday, and now suddenly this "non valid JSON response error" is popping up.

I haven't made any changes to my render callback in PHP. I have even stepped through the render callback PHP function to make sure it was receiving all the attributes correctly and handling them correctly, and I have verified that that is the case. I have a function that will write to a debug.txt file, and I have stepped through the render callback making sure that each condition is working correctly. I can even see the final output that the render callback is returning, and it is correct. And yet, I am seeing this error on the Gutenberg block side. It would be helpful to have a more significant error message rather than "not a valid JSON response".

Looking at the Network tab of the Chrome Inspector Tools I am seeing that the actual response from the request posted above is 502 Bad Gateway - nginx.

I have no idea what this is supposed to mean, because the request from the block is being sent to the server callback, the server callback is processing the request and returning a correct response. Something is happening somewhere between the response that is returned from the callback and the client side rendering of the block. Any ideas what could possibly be going on?

  • Have you checked the PHP error log? That URL is extremely long, are you sure that it's valid at that length? Would it not make more sense to use block styles for things like font family etc rather than putting them on the block itself as parameters? It'd be easier to use, more performant, and have a much nicer UI with previews. Normally you would see the JSON response in the dev tools, but you can't see it because there isn't one. The response was not JSON, it was "502 bad gateway". – Tom J Nowell Jun 5 '20 at 12:56
  • only relevant error I can see in the logs would be this: 3146#0: *230188 upstream sent too big header while reading response header from upstream – JohnRDOrazio Jun 5 '20 at 13:45
  • since these attributes are being saved as a single option array in the ServerSideRender callback, is it possible to instead save to WordPress options from the client side code? And is it possible to read transients from the client side code? I am using transients to cache requests to an external service, and the ServerSideRender callback is checking against the transients. If I can do that client side, why by all means. – JohnRDOrazio Jun 5 '20 at 13:48
  • I seem to have found the solution by upping the proxy_buffer_size for my nginx requests, as indicated here: talk.plesk.com/threads/… . However, I can imagine that if it was a problem for myself in the development phase, it could very well be a problem for users in production phase, so it would be a good idea to avoid the ServerSideRender. I guess I'll turn this into a new question: whether transients and options can be handled in the client side apis. – JohnRDOrazio Jun 5 '20 at 14:48
  • storing it as options doesn't sound like it would solve the problem, I would expect it to multiply any existing problems. I would not completely change the question, it would be swapping the ground from under your feet. If you have a new question, ask a new question don't change an existing one, and I would STRONGLY advise agaiinst the transients/options path, I cannot state more strongly that it is the wrong approach – Tom J Nowell Jun 5 '20 at 19:13

After discovering the exact problem in this case, the request headers being too large because ServerSideRender sending too many attributes in a GET request, I opened a ticket on the Gutenberg development repository proposing a few possible solutions for this issue. And the issue had actually already been addressed because I wasn't the first one to have this problem, so there is currently a pull request to solve this by allowing POST request to be made instead of GET requests.

As for the initial question of getting a more significant response from the ServerSideRender when there is an error, that still stands. It would be helpful to see something more than Error loading block: The response is not a valid JSON response. Perhaps seeing what the exact http status code from the response is, instead of having to dig for it in the Network requests of the browser's Inspector Tools...


The problem is that your block has a lot of attributes, and when they're turned into a GET url the HTTP headers are larger than your Nginx setup is configured to handle.

This is why you get a 502 Gateway error, it isn't a WP error, WP doesn't even get loaded.

There are 5 possible solutions:

  • require nginx configuration changes in order to use your code, to support the super long URLs
  • reduce the number of attributes passed to the server, perhaps by breaking up the block, or relying on block editor features such as block styles rather than dedicated attributes
  • re-implement using javascript, and use an API to interact with PHP yourself, allowing you to do the necessary PHP bits then apply the attributes yourself in JS
  • Break this block apart into multiple blocks, it sounds like it does a lot and might benefit from composability

But the final one:

  • Don't rely on serverside rendering to display both the saved output, and the edit output. They don't have to be the same. You don't even need to use server side rendering in the edit function of your block, you could make it render a placeholder in the edit screen, or implement something completely different
  • when you say, "re-implement using javascript, and use an API to interact with PHP", that was my "new" question about whether options and transients can be handled from the client side using an API: does WordPress offer a javascript API for getting / setting options or getting / setting transients? If not, my guess is it would have to be handled via an ajax request to admin-ajax.php, which would pretty much substitute everything I've been doing in the ServerSideRender callback (and avoid a re-render each time a styling option is changed) – JohnRDOrazio Jun 7 '20 at 15:10
  • if there is an answer to that, perhaps this would be the place to put the answer: wordpress.stackexchange.com/questions/368334/… – JohnRDOrazio Jun 7 '20 at 15:28
  • I have opened an issue on the Gutenberg development repository, where I propose a few possible solutions to the specific problem I encountered: github.com/WordPress/gutenberg/issues/23004 In any case, the first question I asked about getting a more significant response from ServerSideRender, more than a question, is yet another request, perhaps I will open another issue. It would be helpful to know a little more about why the response is considered invalid, for example the http status code, instead of digging for it in the network requests of the browser's Inspector Tools... – JohnRDOrazio Jun 8 '20 at 18:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.