Running into the “Updating failed” or “Publishing failed” errors when trying to update content on your WordPress site? You’ve come to the right place. Let’s take a look at how to identify the root cause of these issues, and how you can fix them.
What Causes the WordPress Updating and Publishing Failed Errors?
When your WordPress instance fails to communicate with the WordPress REST API (which the WordPress block editing experience relies on) – you are likely to run into the “Publishing failed” or “Updating failed” error in WordPress.
While there are several reasons why this might happen, the most obvious one is also the simplest: you’ve lost internet connectivity.
If you’ve lost connection, you may run into the Publishing Failed error. Another reason why this might happen include:
- A recent change to the site URL
- Any third-party service preventing API calls
- A malfunctioning plugin
In most cases, this is an easy fix.
Step 1 – Check Your Internet Connection & Save Your Permalink Settings
Arguably the most common reason why you get this error is when you lose your internet connection. If you unexpectedly lose connection while updating a blog post, WordPress can return this error. If you have ensured you are connected to the internet, open the post or page in edit view in a new tab (or ensure you copy/save the changes before navigating away from the page) and attempt to update the content again.
Another common resolution is simply re-saving your site’s permalink settings (normally lost by a change made to your hosting configuration). There are two super simple ways to do this, the first one we suggest is using WP CLI:
Refresh Your Permalink Settings With WP CLI
If you have access to your hosting environment via SSH, the easiest way to refresh your permalink settings is to:
1 – SSH into your server
2 – Navigate to the root directory for your WordPress installation
3 – Flush the existing permalink structure by running:
wp rewrite flush
4 – Update the permalink structure back to what you had been using previously, such as:
wp rewrite structure ‘/%postname%’
Note: If you are running these commands in a production environment, please proceed with caution as changing the permalink settings to a different structure (without then changing it back to the same structure you were using) will result in a loss in traffic.
Refresh Your Permalink Settings In Your WordPress Admin Area
Alternatively, you can also make this change directly in your WordPress admin area in the permalink settings accessible under Settings > Permalinks, as shown below:
Step 2 – Check If The REST API Is Being Blocked
As mentioned above, another common reason why you might get the WordPress Publishing Failed error is if the REST API is disabled, or blocked. Thankfully, WordPress has a nifty tool that you can use to check the REST API status.
Simply go to Tools, then select Site Health. Here, you’ll see a bunch of errors associated with your WP installation. If the REST API is not working properly, you’ll see the following error:
“The REST API encountered an unexpected result.”
In addition to which the Site Health report will also give you some tips on how to troubleshoot, such as when the REST API is being blocked by a particular plugin that you have installed & activated on your site.
That being said the best way to debug the specific cause on your site is to check your browser’s console log which could show something along the lines of:
In the above case, the exact error message was “ERROR Updating failed. Error message: The response is not a valid JSON response.” and the cause of the error was that Cloudflare’s firewall had blocked the user’s IP from accessing the WP JSON.
So if the issue appears to be that you’re getting a 403 (forbidden) status code from the WP JSON or a REST API error, ensure that security measures (such as a web application firewall, covered next) that you have in place are not unintentionally blacklisting access to these directories that would prevent users from being able to publish or update content on your WordPress website.
Step 3 – Check Your Web Application Firewall Service
Cloudflare is the world’s largest provider of content delivery network (CDN) services, DDoS protection, Internet security, and DNS services.
We’re big fans of Cloudflare here at Servebolt – as a Cloudflare Optimized Partner, that offers better networking connections between Servebolt and Cloudflare. We use Cloudflare Enterprise for various parts of our infrastructure, including the Servebolt CDN and our Accelerated Domains service.
If you’re using Cloudflare with your site, there is a chance that the service may block your REST API calls. If the firewall filters are triggered and Cloudflare deems your IP address suspicious, it’ll immediately block all REST API requests which can result in the “updating failed” or “publishing failed” error in the WordPress admin area.
In which case, before you go ahead and just whitelist your IP address as a quick fix, to identify why your IP ended up being blocked by your own WAF, check your web application firewall’s analytics to see which firewall rule was triggered.
Step 4 – Review PHP Error Logs & Enable Debugging Mode in WordPress
Before resorting to enabling WP Debug and using WordPress’s own debug system, those of you using Servebolt will be able to easily access your PHP error logs.
By default, all sites running on the Servebolt Cloud will generate two logs – ErrorLog & AccessLog. These can all be round in the root of your site in the /logs folder (i.e. at the same level as the /public directory).
The ErrorLog file will contain information about any code running on your site that generates runtime errors (this includes errors that won’t break your site and will continue silently failing in the background, but sometimes do).
And, in the event that this doesn’t provide any further information about what the origin of the error could be, you can enable debugging mode in WordPress. When you enter debugging mode, WordPress will automatically log any PHP responses received in a new file called debug.log.
This new file will appear in the wp-content directory, so you just have to take a look to determine any server-side responses that might be causing the problem.
To enter debugging mode, open up your wp-config.php file, and just before the last line, add the following lines:
// Enable WP_DEBUG mode define( ‘WP_DEBUG’, true ); // Enable Debug logging to the /wp-content/debug.log file define( ‘WP_DEBUG_LOG’, true ); // Avoid publicly showing errors on a production site (this defaults to true if not declared) define( 'WP_DEBUG_DISPLAY', false );
Once you review the debug.log file, you can then remove this code from your wp-config.php file to exit debugging mode.
With Servebolt, you will have access to your PHP error logs by default, including the ErrorLog and AccessLog. In addition to the Slow Query Log which is available on request by contacting our support team. However, WordPress’s own debugging system is great for identifying errors so that you can run a tight ship, keeping your codebase under control.
This really goes without saying, but when making changes to your wp-config.php file, do proceed with caution and it helps to back your site up. Websites running on the Servebolt Cloud are backed up twice a day – we run day-time backups (stored for 3 days) and nightly backs (stored for 30 days).
You can also back up your WordPress site yourself. To restore a backup, simply contact our support team and we’ll restore your most recent backup at no additional cost.
Step 5 – Disable All WordPress Plugins And Check Again
If you have a suspicion that the error is being caused by a WordPress plugin on your site, one option is to disable all the plugins and check whether that fixes the problem.
To do this, simply go to Plugins, then select Installed Plugins. Then, simply select all plugins, and deactivate them in one go using the Bulk actions dropdown.
Next, go back to your screen and see if the WordPress updating or publishing failed error still persists or not. If not, now you’ll know that a plugin running on your site is causing the error. The brute force method of identifying at this stage is to re-activate plugins one by one and check when you get the error again. And, by process of elimination, you’ll be able to identify the plugin at fault.
Once you find the issue, we strongly suggest that you contact the plugin author to let them know and offer to get them any information they’d need to debug as this helps them improve their products for you (and all their other users). This certainly wouldn’t be our first choice when it comes to debugging, given it’s evidently quite tedious and time-consuming.
Temporary Workaround: Install the Classic Editor plugin (not a solution)
The introduction of WordPress Version 5.0 marked the introduction of Gutenberg editor, i.e. the concept we all widely refer to today as blocks.
Although this is merely a temporary workaround, switching from the Gutenberg editor to the Classic Editor may allow you to save and update your posts.
Note: This evidently isn’t a solution so should only be used as a temporary workaround.
To switch from Gutenberg to the Classic Editor, simply download the Classic Editor plugin and activate it on your site. Once it’s activated, just go back to the post (or page) you were editing, and then you should be able to update or publish again as usual.
Step 7 – Reach Out To Our Support Team
If none of the above end up being the fix in your case and you’ve made the wise decision to host your WordPress sites on the Servebolt Cloud, feel free to reach out to our support team. We’re available via chat and email so just get in touch and our team would be more than happy to look into what could be causing this issue for you.
Running into any error, especially one that prevents you from saving work or hitting publish on that new piece of content you’ve been working on is not something anyone wants to happen. As such, while there are straightforward fixes and temporary solutions that you’ll often find are encouraged – we strongly recommend identifying the origin of the issue so that you can take measures to ensure that it doesn’t happen again.
Interested in managed hosting that’s empirically faster? Try the Servebolt way:
- Scalability: In the real user workload tests, Servebolt delivered average response times of 65ms, 4.9x faster response times than the second best.
- The fastest global load times: Average page load times of 1.26 seconds put us at the top of the list of global WebPageTest results.
- The fastest computing speed: Servebolt servers provide previously unheard-of database speed, processing 2.44 times more queries per second than the average, and running PHP 2.6 times faster than the second-best!
- Perfect security and uptime: With 100% uptime on all monitors, and an A+ rating on our SSL implementation, you can be assured your site is online and secure.
All backed by our expert team. Ready to take Servebolt for a spin on your free test Bolt today?