--- title: "Fix \"Updating failed\" and \"Publishing failed\" in WordPress" url: https://wpministry.co/errors/updating-failed/ description: "The block editor saves through the REST API, and the answer was not the JSON it expects. Nothing already saved is lost. What came back instead shows the fix." lang: en-US --- Skip to content # How to fix "Updating failed" and "Publishing failed" in the WordPress editor The block editor saves through the site's REST API. "Updating failed" means the answer to that request was not the JSON the editor expects. Nothing already saved is lost. Look at what came back instead of JSON, and the fix follows from it. By WP Ministry Published October 7, 2026 Tested on WordPress 7.1.4, PHP 8.3.36 ## In short - Nothing already saved is lost. The change on your screen is not saved yet, so copy it before you reload. - The editor saves through the REST API, at /wp-json/. The message means the answer was not JSON. - Open /wp-json/ in a browser tab. A 404 there means the rewrite rules are missing. - The browser's Network panel shows the failed request's status and what came back. That tells the causes apart. - A 403 comes from a security plugin or a firewall, and the rule is theirs to change. The block editor saves by sending your changes to the site's REST API, at an address that begins `/wp-json/`, and it expects the answer in a data format called JSON. "Updating failed." or "Publishing failed." means the save did not go through. When the notice ends "The response is not a valid JSON response.", something did answer, but not with JSON: a 404 page, a firewall's block page, or the right answer with a PHP message printed in front of it. Nothing that was already saved is lost. The change on your screen is not saved yet, and it exists only in that browser tab. ## Keep what you wrote Do not reload the page or close the tab. Click the three dots in the editor's top toolbar, then choose "Copy all blocks". The editor answers "All content copied." Paste it into a text file on your computer, and paste it back into the post once saving works. ## Find out what came back Three checks, quickest first. **Open the REST API yourself.** In a new tab, go to `https://example.com/wp-json/`, with your own domain. A screen of text that begins with `{` is JSON, and the address works. A 404 page means the first fix. If your permalinks are set to Plain, the address is `https://example.com/?rest_route=/` instead. **Ask Site Health.** Go to Tools, then Site Health. "The REST API is available" among the passed tests means the server reached its own API. "The REST API encountered an error" or "The REST API encountered an unexpected result" opens to show the address it tried and the response it got. The server makes this test on itself, so it can pass while requests from your browser still fail. **Read the failed request.** Open your browser's developer tools and click the Network tab. It records only while it is open, so save again. Click the request that failed, read its status, then open its Response tab. | What the request shows | Use | | --- | --- | | Status 404 and a "not found" page | The first fix | | Text ahead of the first `{` that names a `.php` file and a line | The second fix | | An address that differs from the one in your address bar | The third fix | | Status 403, or a page that says the request was blocked | The fourth fix | | Anything else | The fifth fix | If the notice ends "Could not get a valid response from the server." instead, the browser got no answer at all. Start with the third fix. ## Where it goes wrong A page request passes through each of these in turn. This one comes from **WordPress itself**. 1. Browser 2. DNS 3. HTTPS 4. CDN or firewall 5. Web server 6. PHP 7. WordPress (this error comes from here) 8. Database and files ## What causes it - ### The REST API address answers 404 Common With pretty permalinks the editor saves to an address that begins /wp-json/. That address exists only inside WordPress, so it depends on the rewrite rules in .htaccess. When they are missing, the web server answers with its own 404 page. Fix: Get /wp-json/ answering again - ### A PHP message is printed in front of the answer Sometimes A warning or notice printed into the response comes out ahead of the JSON, and the two together are not JSON. WordPress hides such messages from the editor's requests, so one that gets through was printed before WordPress had loaded or by code that turns display back on. Fix: Stop PHP printing messages into the answer, or Switch off the plugin that breaks the answer - ### The site's address settings do not match the address in your browser Sometimes The editor sends its requests to an address built from the Site Address setting. When that is not the address you are working at, http in place of https or another form of the domain, the request goes somewhere other than the page it came from. A browser blocks an http request made from an https page. Fix: Make the site's address match the one you work at - ### A security plugin or a firewall refuses the request Sometimes A firewall compares each request with general patterns of attack. A post that contains HTML or code can match one by mistake, and the request is refused before WordPress can answer it. Fix: Find what refused the request and have the rule changed - ### A plugin or the theme breaks the answer Sometimes A plugin or theme that prints anything of its own while WordPress is answering leaves the editor with something other than the JSON it asked for. Fix: Switch off the plugin that breaks the answer ## How to fix it ### Get /wp-json/ answering again - Easy - Low risk - About 5 minutes - Steps tested on WordPress 7.1.4 These steps are for Apache, which reads `.htaccess`. 1. #### Step 1: Open Settings, then Permalinks Change nothing on the screen. 2. #### Step 2: Press Save Changes WordPress writes its rules into `.htaccess` again. "Permalink structure updated." means it could. If it tells you to update `.htaccess` yourself, it could not write to the file. 3. #### Step 3: Open /wp-json/ again Text that begins with `{` means the address is back. Return to the editor and save. With WP-CLI, a hard flush does the same, but only once WP-CLI has been told the server has `mod_rewrite`. Put this in `wp-cli.yml`, in the folder you run WP-CLI from: wp-cli.yml ``` apache_modules: - mod_rewrite ``` Then run: bash ``` wp rewrite flush --hard ``` Without that file, the command rebuilds WordPress's list of addresses and leaves `.htaccess` alone. A hard flush works on a single site only, not on a multisite network. If WordPress cannot write the file, or the 404 stays, 404 errors on posts and pages that exist (https://wpministry.co/errors/404-not-found/) has the rules to paste in by hand and what to ask of a server that ignores them. It is the same fault: posts answer 404 there for the reason `/wp-json/` does here. ### Stop PHP printing messages into the answer - Takes care - Back up first - About 10 minutes - Steps tested on WordPress 7.1.4 WordPress never displays PHP errors on REST API requests, whatever `WP_DEBUG_DISPLAY` is set to. A message that reaches the editor anyway was printed before WordPress had loaded, from `wp-config.php` on a server whose PHP is set to display errors, or by code that turns display back on. 1. #### Step 1: Read the message It is the text ahead of the first `{` in the Response tab. It says what PHP objected to, and names a file and a line. Write both down. If the file is inside `wp-content/plugins/` or `wp-content/themes/`, use the fifth fix. If it is `wp-config.php`, carry on. 2. #### Step 2: Turn display off at the top of wp-config.php Put this on a line of its own, directly under the opening `