WordPress “Updating failed” or “Publishing failed”: how to fix it

You write a post in the WordPress block editor, click Publish or Update, and instead of saving, the editor shows a red notice: “Updating failed” or “Publishing failed.” The post is not saved. You may also see variations like “Updating failed. Error message: The response is not a valid JSON response” or “Publishing failed. The response is not a valid JSON response.”

This error is specific to the block editor (Gutenberg), which was introduced in WordPress 5.0. The classic editor does not have this problem because it submits forms via traditional POST requests. The block editor saves content through the WordPress REST API using JavaScript fetch requests, and anything that disrupts those API calls causes the save to fail.

Understanding why the block editor depends on the REST API – and what can break it – makes this error straightforward to diagnose.

How the block editor saves content#

When you click Publish or Update in the block editor, the editor does not submit a form. Instead, it sends a JavaScript request to the WordPress REST API:

POST /wp-json/wp/v2/posts/123

The request body contains the post content, title, status, and metadata as JSON. WordPress processes the request server-side, saves the data to the database, and returns a JSON response confirming the save. The editor reads this response and updates the UI.

If any step in this chain fails – the request does not reach WordPress, WordPress cannot process it, or the response is not valid JSON – the editor shows “Updating failed” or “Publishing failed.”

The “not a valid JSON response” variant is particularly telling. It means the editor sent the request, received something back, but what it received was not JSON. This usually means something injected HTML, a PHP warning, or an error page into the response before WordPress could return its JSON output.

Cause 1: REST API blocked by a security plugin#

The most common cause. Security plugins (Wordfence, iThemes Security, Sucuri, All In One WP Security) can block or restrict REST API access to prevent unauthenticated data exposure. Some configurations block the REST API for all users, including logged-in administrators.

How to confirm

Open your browser’s developer tools (F12), go to the Network tab, and click Update/Publish. Look for the request to /wp-json/wp/v2/posts/ and check its response:

• 403 Forbidden – a security plugin or server rule is blocking the request
• 401 Unauthorized – authentication is failing on the REST API request
• 200 OK but HTML content – the request succeeded but something injected non-JSON content

You can also test the REST API directly. Visit this URL while logged in:

https://yourdomain.com/wp-json/wp/v2/posts?per_page=1

If you see JSON data, the REST API is working. If you see a blank page, an error, or a redirect, something is blocking it.

How to fix

Check your security plugin’s settings for REST API restrictions. Common settings to look for:

• “Disable REST API” or “Restrict REST API” – this must allow authenticated users. Completely disabling the REST API breaks the block editor.
• “Disable XML-RPC and REST API” – some plugins bundle these together. You can disable XML-RPC (which is rarely needed) while keeping the REST API active.
• Firewall rules – security plugin firewalls may flag REST API requests as suspicious if the request body contains certain patterns (like HTML tags in post content).

If you are unsure which plugin is causing it, temporarily deactivate security plugins one at a time and test saving after each deactivation.

Cause 2: ModSecurity or server-level WAF#

Web application firewalls (WAF) running at the server level inspect request bodies for patterns that look like attacks – SQL injection, XSS payloads, path traversal. A WordPress post that contains HTML, JavaScript examples, code blocks, or certain character sequences can trigger WAF rules.

How to confirm

The developer tools Network tab shows a 403 or 406 response to the REST API request. The response body may contain a generic error page rather than JSON. Check the server error log for ModSecurity entries:

grep "ModSecurity" /var/log/nginx/error.log

Or check your hosting provider’s ModSecurity logs. The log entry will show which rule was triggered and which part of the request body matched.

How to fix

If you manage the server, you can whitelist specific ModSecurity rules that trigger on legitimate WordPress content. The rule ID is in the log entry.

If you are on managed hosting, contact support with the specific error. Most hosts can whitelist rules for the REST API path or adjust WAF sensitivity for WordPress admin operations. On Hostney, ModSecurity rules are tuned for WordPress compatibility – this is rarely an issue, but if it occurs, support can adjust the ruleset for your domain.

Cause 3: SSL or mixed content issues#

The REST API request uses the same protocol as the page. If your WordPress Address is set to https:// but some component of the page loads over http:// , the browser may block the REST API request as a mixed content violation. Or if SSL is misconfigured and the REST API endpoint redirects between HTTP and HTTPS, the request fails.

How to confirm

The browser console shows mixed content warnings or CORS errors. The Network tab shows the REST API request being blocked or redirected.

How to fix

Ensure both WordPress Address and Site Address in Settings > General use https:// . If you recently migrated to HTTPS, run a search-replace to update all URLs in the database:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables

If you are behind a reverse proxy or CDN that terminates SSL, WordPress may not detect HTTPS correctly. Add this to wp-config.php :

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

For a deeper walkthrough of HTTPS migration issues, see How to migrate WordPress to another hosting provider – the URL replacement and SSL sections cover the same mechanics.

Cause 4: PHP errors injected into the response#

If a plugin or theme outputs a PHP warning, notice, or error during the REST API request, the warning text is prepended to the JSON response. The editor receives something like:

<br />
<b>Warning</b>: Undefined variable $foo in /path/to/plugin/file.php on line 42
{"id":123,"title":{"rendered":"My Post"},...}

This is technically valid HTTP but not valid JSON. The editor cannot parse it and shows “not a valid JSON response.”

How to confirm

In the Network tab, click on the failed REST API request and look at the Response tab. If you see PHP warnings or notices before the JSON data, this is the cause.

How to fix

The PHP warnings need to be suppressed from output. In wp-config.php :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

The critical line is WP_DEBUG_DISPLAY set to false . This writes errors to the log file instead of injecting them into the response. The warnings still exist (and you should fix them – they indicate a plugin or theme bug), but they no longer break the REST API response.

If WP_DEBUG_DISPLAY is already false but warnings still appear in the response, a plugin may be calling ini_set('display_errors', 1) or error_reporting(E_ALL) directly. Check the response body for the specific warning and trace it to the plugin. For more on controlling PHP error output, see How to display PHP errors and enable error reporting.

Cause 5: Permalink structure issues#

The REST API uses pretty permalink URLs ( /wp-json/wp/v2/... ). If pretty permalinks are not working, the REST API may be inaccessible or may redirect in a way the editor does not handle.

How to confirm

Visit https://yourdomain.com/wp-json/ directly. If you see a JSON response listing available endpoints, permalinks are fine. If you get a 404 or the URL does not resolve, permalink routing is broken.

How to fix

Go to Settings > Permalinks and click Save Changes without modifying anything. This regenerates the rewrite rules.

On Nginx, ensure the server block includes the try_files directive:

try_files $uri $uri/ /index.php?$args;

Without this, Nginx returns 404 for any URL that does not correspond to an actual file, including the REST API URLs. On Hostney, this is configured automatically for all WordPress sites. For a deeper explanation of how Nginx handles WordPress URLs, see How to fix 404 errors in Nginx.

If pretty permalinks cannot be made to work (some unusual hosting configurations do not support them), you can use the plain REST API format by adding this to wp-config.php :

// Force REST API to use query string format
// Only use this as a last resort
add_filter('rest_url_prefix', function() { return 'wp-json'; });

Cause 6: Caching returning stale nonces#

WordPress uses nonces (number used once) to verify that REST API requests come from a legitimate session. Nonces are time-limited and tied to the user’s session. If a caching plugin caches the editor page including the nonce, and a different user loads the cached page, the nonce is invalid for that user’s session. The REST API rejects the request.

How to confirm

The REST API request returns a 403 with a response body containing {"code":"rest_cookie_invalid_nonce"} .

How to fix

Ensure your caching plugin excludes wp-admin and all logged-in user pages from caching. Most caching plugins do this by default, but misconfigurations happen:

• WP Super Cache / W3 Total Cache: Check that “Don’t cache pages for logged-in users” is enabled.
• Server-level caching (FastCGI, Varnish): Ensure caching is bypassed when WordPress login cookies are present.
• CDN caching: If using Cloudflare or another CDN, ensure the WordPress admin area is excluded from caching via a page rule.

On Hostney, the Nginx FastCGI cache automatically excludes logged-in users and admin pages. The Hostney Cache plugin manages cache exclusions for WordPress cookies, so this issue does not occur with the default configuration.

Clear all caches after fixing the configuration. The stale cached page with the invalid nonce needs to be purged before the fix takes effect.

Cause 7: Plugin conflict with the REST API#

Some plugins hook into the REST API response and inadvertently break it. This can happen when a plugin:

• Adds output buffering that captures and modifies the REST API response
• Registers a  rest_pre_serve_request  filter that does not return properly
• Uses  wp_die()  or  exit()  during REST API processing
• Outputs HTML (like admin notices) during REST API requests

How to confirm

The REST API works when all plugins are deactivated but fails with plugins active. Use the developer tools Network tab to compare the response with and without plugins.

How to fix

The binary search approach is fastest: deactivate half your plugins, test, then narrow down. Once you identify the plugin, check for updates, check the plugin’s support forum for known REST API issues, or find an alternative.

Common offenders include:

• Plugins that add JavaScript tracking to every page (including admin)
• Plugins that modify HTTP headers globally
• Plugins that register shutdown functions that output HTML
• Poorly coded custom plugins that do not check  wp_doing_rest()  before outputting content

Cause 8: Server timeout during save#

If a post is very long, contains many blocks, or has complex metadata, the REST API request may take longer than the server allows. The server terminates the connection before WordPress can return a response.

How to confirm

The Network tab shows the request taking a long time (10+ seconds) before failing. The response may be empty or contain a generic timeout error.

How to fix

This is more common with complex posts (page builder layouts with dozens of blocks, WooCommerce products with hundreds of variations). The fix depends on which timeout is being hit:

• PHP  max_execution_time : Increase in PHP configuration. On Hostney, change this in Hosting > PHP Manager > Variables.
• Nginx  proxy_read_timeout : If Nginx times out waiting for PHP-FPM, the default is usually 60 seconds. Contact your host to increase it for the admin area.
• Cloudflare or CDN timeout: CDN proxies have their own timeouts (Cloudflare’s default is 100 seconds on free plans). If using a CDN, check its timeout settings.

If the save consistently times out on a specific post, the post’s content may be triggering a performance issue in a plugin that processes post content on save (SEO plugins analyzing content, caching plugins purging URLs, etc.).

Diagnosing with browser developer tools#

The developer tools Network tab is the single most useful diagnostic tool for this error. Here is what to look for:

1. Open developer tools (F12 or Cmd+Opt+I)
2. Go to the Network tab
3. Click Update or Publish in the editor
4. Find the request to  /wp-json/wp/v2/posts/  (or  /wp-json/wp/v2/pages/ )

Check the status code:

• 200 = success (if still showing error, check response body for non-JSON content)
• 401 = authentication failure
• 403 = blocked by security plugin, WAF, or invalid nonce
• 404 = REST API URL not found (permalink issue)
• 405 = method not allowed (server configuration blocking POST requests)
• 500 = PHP fatal error during save
• 502/503/504 = server/PHP-FPM issue

Check the response body:

• Valid JSON starting with  {  = request succeeded, error might be in the JSON error message
• HTML before JSON = PHP error output contaminating the response
• Full HTML page = redirect happened, security plugin injected a page, or wrong URL
• Empty response = timeout or connection dropped

Check the request headers:

• Look for  X-WP-Nonce  header. If missing, the nonce was not properly embedded in the page
• Look for  Cookie  header. WordPress authentication cookies must be present

When the editor works but REST API errors persist#

If saving works most of the time but occasionally fails, the issue is likely intermittent:

• Database connection limits. If the database server is under heavy load, the REST API request may fail to get a connection. This is more common on shared hosting where many sites share a single MySQL server. For a full discussion of database connection issues, see Error establishing a database connection in WordPress: how to fix it.
• PHP-FPM worker exhaustion. If all PHP workers are busy, new requests queue and may timeout. This often correlates with traffic spikes or bot attacks. See 503 service temporarily unavailable in Nginx: what it means and how to fix it for the mechanics of worker pool exhaustion.
• Rate limiting. If your server applies rate limiting to POST requests, rapid saves (clicking Update multiple times quickly) may trigger the limit.

The classic editor as a temporary workaround#

If you need to publish content immediately and cannot diagnose the REST API issue right now, the Classic Editor plugin bypasses the REST API entirely. Install and activate it, and WordPress saves posts via traditional form submission. This is a workaround, not a fix – the underlying REST API issue should still be resolved because other features depend on it (the block editor, the new widgets editor, the site editor, and third-party plugins that use the REST API).

wp plugin install classic-editor --activate

Summary#

“Updating failed” and “Publishing failed” mean the block editor’s REST API save request did not complete successfully. The cause is almost always one of: a security plugin blocking the REST API, a WAF flagging the request body, PHP errors contaminating the JSON response, a permalink configuration issue preventing REST API URL routing, or a caching plugin serving stale nonces.

Diagnose by opening browser developer tools, checking the Network tab for the REST API request, and reading the status code and response body. The response tells you exactly what went wrong – whether it is a 403 from a security plugin, a PHP warning before the JSON, or a timeout. For a complete reference of WordPress errors and their quick fixes, see How to fix the most common WordPress errors.