Fixes for Update Failed Not Valid JSON Response in WordPress

See what causes errors when you attempt to update a post or insert JavaScript and how to fix it.

The Error Messages

Have you seen any of these errors while working in WordPress?

• Update failed
• Publishing failed
• The response is not a valid JSON response
• updraft_send_command: error: error (Forbidden)
• can’t add Google Analytics tracking code via Insert Header/Footer plugin

They have a few root causes and this tutorial will help you determine the cause and show you how to get around the error.

ModSecurity Protection

The most likely cause of an update failed or invalid JSON response is likely due to tripping a security wire at your hosting provider or WAF (Web Application Firewall) via OWASP rules.

OWASP rules are controlled by Imunify360, which is a company that supplies cyber security solutions for hosts and individuals.

Many popular hosts that use the cPanel interface use ModSecurity as one of their protection services.

ModSecurity has about 10 of the most common OWASP rules.

Popular WAFs, like the one in the Cloudflare Pro plan, have 25+ OWASP rules.

READ: What is ModSecurity and Should You Turn it Off? for more details.

JavaScript Security Trigger

So, why are we suddenly seeing so many update failed and other such errors on our sites?

In a word – Gutenberg.

WordPress has been steadily moving its core code away from PHP and toward JavaScript.

Gutenberg runs primarily on JavaScript.

And now many plugins have also recoded from PHP to JavaScript too.

JavaScript is executable code. It’s literally a code script that performs a function.

Malicious executable files are called malware and can harm your site, computer, and anything you have connected to the internet.

When you try to update or publish a post or page, any JavaScript in it can be considered a threat.

If so, then ModSecurity thinks you are trying to inject malicious code onto your site.

It gets triggered and stops the execution of the code.

And you see an update failed or one of the other warnings listed previously.

How to Fix ModSecurity Issues

There are several options for fixing the issue, depending on what is triggering the errors.

FYI: Individual support for these issues is reserved for my BB Hub site audit clients. Support will not be offered via comments on this post. And any fixes that I believe are unsafe for DIY site owners will be commented on as such. Please use all fixes suggested at your discretion.

Whitelist Your IP

You will want to let the WAF at your host and your WAF on Cloudflare or other CDN know that you are authorized to inject JavaScript on your site.

For Cloudflare, see this tutorial for how to find and whitelist your IP address.

NOTE: Select Allow in the drop-down (they changed it from Whitelist).

Some hosts are now gathering your IP address when you purchase your hosting account. And that is the IP address they whitelist for your site.

Contact your host to verify that they have your IP whitelisted.

NOTE: Your IP may change periodically, and you will need to update it in your whitelist if:

• You’re connected to the internet via wifi – the router may rotate IP addresses
• You travel

Temporarily Turn Off ModSecurity

Yes, I get that update failed and similar errors are a pain to deal with.

Do not permanently turn off ModSecurity!!!!!

You would not believe how many malicious attempts on your site it stops a day.

You need ModSecurity to help protect your site.

To temporarily turn it off and do your update or such:

• Navigate away from the post/page/plugin setting where you saw the error, maybe just return to your WP Dashboard.
• Log in to your hosting cPanel.
• In the search field (usually at the top) type in ModSecurity, then click on that tool.
• Turn it off.
• Return to WP and navigate to the post/page/plugin setting you were working on.
• Do your save.
• Return to your hosting cPanel.
• Turn ModSecurity back on.

The reason why you need to first navigate away from what you were working on when you saw the error is due to browser caching. It will likely fail on your next attempt to save, even with ModSecurity off, if it isn’t allowed to fully refresh first – and no – refreshing the browser tab is not the same thing as totally leaving the post and then opening it again.

Use Shortcode Instead of Inserting JavaScript

Many 3^rd party vendors, such as email list service providers, like ConvertKit, provide several methods for placing an optin on your site.

Some 3^rd party affiliate links or badges are also provided as JavaScript.

ModSecurity will likely see these as malicious injections when you first add them.

And it may continue to see them as malicious if they are actively updating from the 3^rd party.

To avoid constant issues with it every time you want to update the page/post, check to see if the vendor has a shortcode option and use it instead of the JavaScript.

FYI: Some vendors list their JavaScript as HTML code because they also provide you with inline styling, and not just the JavaScript. Check the full code to see if anything starts with <script. That is the JavaScript part of it, and likely the culprit.

Temporarily Turn of the WAF

If you are using the Cloudflare Pro plan, it has more than double the OWASP settings of ModSecurity at your host.

And it may be the security tripwire that is triggering.

FYI: Always try ModSecurity at the host and only use this method if that doesn’t work.

NOTE: There is a risk of attack when turning off the WAF in Cloudflare.

• Navigate away from the post/page/plugin setting where you saw the error, maybe just return to your WP Dashboard.
• Go to Cloudflare and click on your site’s domain.
• At the top, click on the Firewall tool.
• Then click the tab for Managed Rules.
• Click the toggle to turn off the Web Application Firewall.
• Return to WP and navigate to the post/page/plugin setting you were working on.
• Do your save.
• Return to Cloudflare.
• Turn the WAF back on.

Disable the Block Editor

This is a “last resort” type of solution, but when all else fails, it may be an alternative that works for you.

• Install the Classic Editor plugin and activate.
• In the WP admin sidebar, go to Settings > Writing.
• Select Classic Editor as the “default editor for all users”.
• Return to WP and navigate to the post/page/plugin setting you were working on.
• Do your save.
• Then return to Settings > Writing.
• Select Block Editor as the “default editor for all users”.

You may want to try editing an existing post, or creating a new one, and saving it to test that you don’t get a new error message.

Manual Save Override

Some site owners have reported that doing a keyboard shortcut save helps them avoid the errors.

• While in your post/page editor, on your keyboard, press Ctrl + S (for Mac users, that is Cmd + S).

This keyboard command should make the post/page save and is considered a manual override to the auto save feature.

Miscellaneous Causes and Fixes

These error have been increasing since 2020 as more site owners switch to the Gutenberg editor that is run on JavaScript.

You will find all manner of other “fixes” listed online – but I believe them to be either sketchy, or just a temp fix and they do not actually address the root issue.

The pseudo fixes are:

• Missing SSL certificate
• Mixed media warnings due to missing HTTPS security headers
• Temporary change of permalink
• Plugin conflict – this one may be true, and is often security related plugins
• Ask host to whitelist some ModSecurity rules – this one is the most dangerous of the pseudo fixes because no one can guarantee that a hacker won’t exploit that loophole

Getting to the Root Issue

All of these update related errors are likely caused by the REST API that WordPress now uses that issues the following in the header anytime the site is communicating back and forth with the logged in site owner, which is a Request URL of /wp-json/.

There are multiple tickets open for it in the WordPress TRAC support system – and not a single one of them has a long-term fix that all hosts and WAFs can implement.

As cyber security worsen’s I expect Imunify360 to continue creating more and more trigger rules.

And the reason they may be tightening the current rules to the point that we can’t work on our sites is because so many hosts are whitelisting the rules, or just turning off ModSecurity for that site owner.

In effect, they are shooting themselves and the site owner in the foot with this practice by essentially removing an important security measure.

And Imunify360 is thinking the rules we have don’t work, so they make them tighter.

I have even seen some hosts completely remove ModSecurity and they are no relying on who knows what for server-side security that may or may not work well with cPanel to protect site owners from as many threats.

Share Your Experience

Let us know what issues you are seeing when doing updates on your site. Please do include the exact error message and what you were doing when it popped up. You’re also welcome to include what measures you took to fix it and please let us know if they work consistently for you.