I was having a hell of a time writing a post. The damn thing just would not save.
I either got a warning message (in red!) “Updating failed. The response is not a valid JSON response.” (see screenshot below) or I got an message saying saving had been successful but no little black pop-up confirmation box. Either way the post had not saved. Repeating the operation just ended up with the same result.
() – notice these apparently pointless empty round brackets here. They are what allows this post to be saved! More in a minute
In fact the first few times I got the red box then it was as if Gutenberg (or whatever triggers the warning) got bored telling me. So then I got no red warning BUT the post was not saved. If, after a failed save I tried to leave the block editor it warned me that I had unsaved changes. Changes I sadly could not save. (more on a work round for that in a minute).
The Finger Points at Gutenberg ()
I use Gutenberg. Aka – the Block editor. I forced myself to move over to it from the Classic editor a couple of years ago and I now don’t want to move back. BUT.. this is a show stopper! I think I had just updated to WordPress 6.3.1. Whether that is the cause, as of yet, I don’t know.
() – notice these empty brackets again!
These fixes entailed me cocking up all my plug-ins which (I hope) are now back to as they should be. But none of the options fixed my problem.
Just to add to the weirdness it appeared that the problem ONLY affects posts. Not pages. I also picked up on a couple of nebulous statements about “brackets” (see second link). Nothing clear. But it was all I had.
This below is not really a fix but it may-be is a work-round for you if you are in the same hole as me. It’ll have to do until I figure out a proper fix. Notice – even subheadings need the damn brackets!
Background and saving what you have ()
So being in the position that I couldn’t save my shiny new post to the server the first thing I wanted to do was make sure I got it backed up so I didn’t have to sweat over entering all again (for a third time). so I’ll start off explaining how to save an unsaved post that will require minimal effort to re-enter it if necessary. Skip this if you just want to go to my work-round.
Saving Your Post Locally ()
I had entered a whole post and had not noticed the failure to update. So the server had about a third of it. I put it down to some crazy key press or whatever and binned the defective post and started again. Same result. I was not keen on the idea of losing it again! So I didn’t close the tab on Firefox (remember: this is running locally). After some experimentation I found the best way to save the thing was to ignore the title but highlight the rest of the post. When you’ve done that the block editor controls appear as here at the top of the post text.
() – It’s those darn pesky empty bracket again!!
Select the three vertical dots and then “Copy Blocks”. This copies the post as html. Then open a text editor and paste. You get this. You can also do a straight forward normal copy (or ctrl C) but this just gives you a textual copy and you’ll lose all the formatting.
() – It’s those darn pesky empty bracket yet again!!
Why it’s better to use Copy Blocks ()
Using copy blocks means you can easily recreate the whole post in the block editor with a couple of clicks (even though it still wont save to the server until you fix the issue). You simply copy the text from the text editor and paste it into a single block in the Gutenberg block editor. Gutenberg works it all out.
So having saved the post I could now poke it around and find out what was wrong. After much experimenting this is what I found was my problem.
So.. The Problem : In Essence
I had an link (in my case to the Visual Studio Code download site) – this was fine!
BUT… after the link, in a different block I had a pair of round brackets with text in between them.
I kid you not. That was it.
The Problem Explained – as far as I can ()
The brackets (with text between them) broke the REST API and the post wouldn’t save. hence the “Not a valid JSON Response” banner. But this breakage ONLY occurred if there was a link somewhere in the text before they appeared. I could put round brackets wherever I liked after the link IF (and only if) the first pair of round brackets after the link had nothing in them. I found I could also put brackets anywhere in front of the link and it was fine. In writing this I just found that sub headers ALSO need brackets round them.
So, I am sure that this is a new problem that has been introduced sometime in the last 6 months. It could be in the Block Editor, the RestAPI, my security or the web-host security being over-reaching in its paranioa. I’d put my money on the last option as I have seen a few other folk complaining on Google about similar (though not the same ) issues all based around web host security. But it is just a guess and frankly life is too short and I’d suspect that this will be fixed soon.
I’d suspect that the security code checking the post update is seeing the URL then brackets so it is assuming it is trying to do some illicit function call to the “function” in between the brackets and blocks the update. i.e. its a bug in the hosts security code. Just a guess though.
Working Round this Nightmare ()
I’ve worked on this a bit more and have a temporary fix incorporating the info I gained from the investigation described above. It’s less of fix more of a work-round (or even a kludge) and there’s no guarantees it’ll work for everyone but it is described in this later post: Avoiding JSON Error with Gutenberg Block Editor. Below is my preliminary attempt predating the above link post..
My “solution” or work-round (for what it is worth – which isn’t much) is either:
Don’t use any round brackets after putting a link or image (maybe) in a post (square brackets appear to be fine).
Or Don’t use any links or images (hardly practical)
Or, (my preferred from now on) put a pair of empty brackets in the text just after the inclusion of a link or image. AND you also need them on the following header. (Arghhhhhh!)
If you look in this that’s what I’ve done here. Here I’ve left them undisguised them but normally I’d hope to bury them in some way.
Hope that helps.
p.s. If you know of a better fix/solution/work-round please tell me. This drove me mad.
p.p.s The next thing I am going to try is removing the spurious brackets after the post is up on the server. I don’t think this will work for links but I suspect they can be removed for images as the image will now be up on the server not on the local machine waiting to be uploaded.
See this later post for a more coherent description of what to do to work round this issue
Here’s the rest of my WordPress & related posts