Category: Wordpress CMS

If you are using the Block editor on WordPress also called Gutenberg and you’re getting the following JSON error with a red banner when you try and save a post:

This may be of help. To call it a fix is a bit too enthusiastic. It is more of a Kludge but it got me out of a hole and it may help you. No guarantees though. If you want to read about the whole sorry saga that led to this post there this earlier post of mine here. This is based on what I learned there (the hard way) and is recorded in that post.

Background

The problem is nothing to do with Gutenberg or WordPress but is due to security rules on your host that veto the JSON update because in certain circumstances the data held within the JSON transfer (aka you blog post) will look suspiciously like an attempt at hacking your blog.

So this is in essence an incompatibility between Gutenberg and (usually) the Apache2 Modsecurity module on your host. Or rather the rules used to drive it. Here’s a great description by a lady far, far cleverer than me Fixes for Update Failed Not Valid JSON Response in WordPress

One Way forward that avoids this Kludge

It is possible to avoid this JSON Error with Gutenberg Block Editor by getting your host to modify it’s modsecurity rules for your blog by disabling certain rules for your site by whitelisting anything coming from your home/work URL for your blog URL.

Obviously though this entails you raising a ticket on your host and then persuading them to accommodate you.

As well as that they generally need a static URL to associate with the rule waiver. So if you’re URL is likely to change or you need to do work on your blog from different locations this will be a pain.

So I thought I’d see if there’s anything that can be done about it without whitelisting.

Itemising the Problem

In my last blog post I pointed out that the problem appeared to be caused by having round brackets with text in (like this). Here’s a summary of what I found:

1. Having round brackets (either with or without text in between them) BEFORE any links/images caused no problem.

2. Having round brackets with text in (like this) after a link ALWAYS caused a problem UNLESS there were a pair of empty brackets – like this () between the link and the populated brackets.

3. Including an image SOMETIMES (more often than not) causes the same behaviour as a link aka a JSON error. Again a pair of empty brackets was required to be in the post after the image but before a populated pair of brackets to get the thing to save.

JSON Error with Gutenberg Block Editor: The Fix (or Kludge)

The thing I have found out (at least on my rig) is that it does not matter where the () occurs just as long as it is before any populated brackets. First of all I placed them in text (ugh! Ugly). But then I had an idea. Why not place it in an html comment? An html comment is invisible in the rendered post and is easily added along with text.

Take a block with a link in it you’ve added to Gutenberg. If you look at the html it looks like this:

<p>some text here<a href="https://code.visualstudio.com/download/">This this link</a>more text</p>

So lets add an invisible pair of brackets as an html comment like this

<p>some text here<a href="https://code.visualstudio.com/download/">This this link</a><!--()--> more text</p>

Job done.

Similarly for an image..

The html looks like this:

<figure class="wp-block-image aligncenter size-full"><img src="http://testsite1.thistestsite.co.uk/wp-content/uploads/2023/10/predicted-disasters.jpeg" alt="see what happens here" class="wp-image-14"/><figcaption class="wp-element-caption">Plus a caption (here) it seems</figcaption></figure>

Change it to look like this.

<figure class="wp-block-image aligncenter size-full"><img src="http://testsite1.thistestsite.co.uk/wp-content/uploads/2023/10/predicted-disasters.jpeg" alt="see what happens here" class="wp-image-14"/><figcaption class="wp-element-caption"><!--()-->Plus a caption (here) it seems</figcaption></figure>

It seems that if the addition of the empty brackets goes anywhere else it triggers an error in the block editor. So you will be forced to have a caption field – even if it is empty. It also means you MUST NOT have populated brackets in the alt text field.

Modifying the HTML in Gutenberg

The need to have these empty brackets means that you need to modify the html within the Gutenberg editor before it will save. This though is easily achieved.

For links: Select the block containing the link that’ll have text plus link or maybe just a link. Click the vertical three dots on the right hand end of the controls. Select edit as HTML. Add the html comment containing only a pair of empty brackets immediately after the link terminator ( that’s the </a> ). What you need to add is this:

<!--()-->

For images: select the image then select edit as HTML as above. Add the <!– () –> in front of the caption text. This means you must have a caption field – even if it is empty. You can trigger the caption field by just adding a space or any temporary text then when editing the html remove the temporary text and add the <!–()–>

That’s it. There may be many other block types that will suffer from this problem but these are the main two and if (like me) they are more-or-less the only ones you use other than headers and paragraph blocks this may work for you too.

This though is ugly. I’m not wildly happy about promoting it as a fix because at best it is a work-round or a Kludge if you want to be brutally honest. Also it works (for me) today. It may not work tomorrow.

But if you are brick walled by this problem it may be a (temporary) solution. I know it sounds crazy. But there it is.

Hope that helps.

Chalkie.

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.

I did the inevitable Googling of “Not a valid JSON Response” and tried all of the suggested fixes on this link and on this link.

() – 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 ()

The first thing to realise about the block editor is that it is NOT running on your server. It is a Javascript application that is running in your browser i.e. on your computer. So until it or you does an update to your website the data is local. If it cannot communicate correctly (using what is known as the REST API) with your server then you cannot add/update posts on your server. That’s what’s happening. Your (my) post data is not getting out of the PC. The “Not a valid JSON Response” means it cannot upload your post.

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

I had had an annoying problem where I’d log into one of my WordPress sites, then attempt to change the side bar and remove (say) a block of code that pulls in an iframe from another site (i.e. Twitter or Amazon or whatever) I got blocked by my security Wordfence plugin with a XSS cross scripting error. The actual site works fine it is just the admin cannot change anything. I first fixed this back in 2020, then forgot about it. I then changed my admin URL (i.e. broadband provider) and it re-appeared. Now as a penance I’m writing it up.

The Problem:
When I tried and change anything using Appearance → Customise in WordPress dashboard the item I want to change gets blocked with this “Potentially Unsafe operation” on the left:

Later I receive my Wordfence email outlining Wordfence activity and I get this sort of thing in the “Recently Blocked Attacks” section.

The IP address (blanked out in the “Blocked Attacks” image) is my own. Wonderful though the Wordfence plugin is (and it really IS wonderful!) it is blocking me from changing anything! Which is rather sub-optimal, although I can still post.

The fix is simple – when you know where it is in the Wordfence plugin.

Select the Wordfence top level menu item in the WordPress Dashboard. Then select the “Live Traffic” Tab. You will see a list of blocked activities. Identify the one that has your IP address on it and then click on the “eye” on the far right of the summary line.

After you have clicked the “eye”, you then get this.

Select the “ADD PARAM TO FIREWALL ALLOW LIST” Then you are done! Your false Wordfence XSS Cross Scripting Error should go away.

You can now check that this has been implemented (and also exactly who is allowed to bypass the firewall) by clicking on the “All Options sub-menu item in the Wordfence menu in the WordPress dashboard.

In the “Rules” section make sure “whitelist” is on. (It should be) Then go down to “AllowListedURLs” and expand it. Here you should see your newly whitelisted URL. You can turn it (and any other ones) on and off from this menu too. I did not need to log out/in for changing enable/disble to work but you may need to.

Anyway hope that helps.

WordPress is a complex beast and occasionally an update (automatic or otherwise) will fail to take the site out of maintenance mode after it completes. Most people never actually see their site in maintenance mode. It’ll look something like this below though you may not have the fancy image – just a battleship grey background.

Google Webmasters (and it’s Google Search Console ) provides you with a Domain property verification string to allows you to get the full search data going to your site. The Domain Property shows all the search data for your site in one place rather than (say) separate data for https and http access. It is worth using.

I had a little trouble getting Yoast breadcrumbs to work properly. Most of the Yoast plugin needs no other modification to your theme. It works right out of the tin and is an excellent product. But to get Yoast breadcrumbs to work you need to do a code mod. The question is where should this code modification be done.

A soft 404 error is one where the website shows a 404 Not Found error page BUT then completes with a HTTP status code 200 (OK). Here’s how to fix the issue.

There are many Google Analytics plugins for WordPress. Most also give you some form of display of this data in the wp-admin area. But you also get the endless plugin promotions trying to get you buy the enhanced version. While I don’t mind (that much) people trying to sell their wares (especially when I’m using a free version) sometimes it just grates.

So if rather than using a plugin you would like to just code and forget it, you can simply add a function into a file in the site child theme. Then you can check it works and forget about it. That’s what I do.

It is a good idea to always keep a recent local WordPress back up copy of your one.com hosted website. One.com is one of the more reliable hosting companies and they offer a backup facility for customers. But even so, if you have a recent local copy of your website safely stored on your hard drive there is no question about your ability to restore your site should the worst happen.

Here’s my personal notes (with an intro) on creating a local backup of a Hostpapa wordpress site. Maybe they’ll be useful to you too.

It is a good idea to always keep a recent local back up copy of your Hostpapa website. You can use Hostpapa’s remote backup facility for convenience as well, but if you have a recent local copy sitting there on your hard drive you know exactly where you stand.

If you have just set up (say) a local Apache2 server and have a local wordpress install so you can debug your website locally you may find (like I did) that while the main webpage comes up fine, when you click through to anywhere else on the site it returns a 404 Not Found error. Even though you know the page/post is there and it shows up OK in the wp-admin section.

For me it turned out that I had not enabled an important plugin on Apache2 to allow permalinks to work. The missing module is called mod_rewrite. It is simple to fix.