Fixing "Updating failed" and "Publishing failed" in the editor

"Updating failed" and "Publishing failed" both mean the same thing: your browser sent the save request, but something between wp-admin and the database rejected it. Three of the most common causes on our stack are a file permission problem, a PHP limit, or a plugin blocking the REST API. Work through them in that order and you'll usually find it in a few minutes.

Start by opening your browser's developer console (F12 or right-click → Inspect → Console) and retrying the save. If you see a 403 or 500 error next to a request to wp-json, jump straight to the REST API section below.

Cause 1: file and folder permissions

WordPress writes to disk every time you save a post (revisions, autosave, sometimes media). If the ownership or permissions on wp-content got changed, usually by a plugin that touched files as the wrong user, WordPress can't write and the save fails silently or with a vague error.

• Connect via FTP or the portal's File Manager (Services → your hosting → File Manager).
• Check wp-content and its subfolders. Folders should be 755, files 644.
• If anything is off, select the folder and use "Change Permissions" (recursive) in File Manager, or chmod if you're on SSH.

If permissions look fine but you still suspect a write problem, check disk usage. A full disk behaves the same as a permissions error: WordPress can't write anything, including the post you're trying to save. Disk usage is visible in cPanel's Disk Usage tool.

Cause 2: PHP limits

Large posts, big pasted content, or a lot of embedded blocks can hit PHP's post_max_size or max_execution_time. The save request times out or gets truncated, and the editor reports a generic failure.

• Go to cPanel → Software → MultiPHP INI Editor.
• Switch to Editor mode and check post_max_size, upload_max_filesize, and max_execution_time for the domain.
• Raise them if they're near default values (defaults are often too low for image-heavy posts).

The portal's PHP Version tile only switches the PHP version itself, not these limits, so you do need to be in MultiPHP INI Editor for this one. If you recently changed PHP version and the failures started right after, also check whether a plugin is incompatible with the new version, using the same general approach as the white screen of death article: disable plugins one at a time and retest.

Cause 3: a plugin is blocking the REST API

The block editor saves posts through the WordPress REST API (/wp-json/wp/v2/posts), not a classic form post. Security plugins, firewall rules, or caching plugins that are too aggressive about blocking wp-json will break every save, even though the rest of the site looks fine.

• Check the browser console for a 403 or 500 on a wp-json request, as mentioned above.
• If you're running a security plugin (Wordfence, iThemes Security, etc.), check its firewall or REST API restriction settings and temporarily disable the rule.
• If disabling your security plugins doesn't fix it, open a ticket so we can check the server-side logs.
• Rule out a plugin conflict the same way you would for a white screen: rename /wp-content/plugins/ to test, then re-enable one at a time.

If the failures started right after an update, treat it as a compatibility problem first. Roll back the specific plugin or theme, confirm the save works again, then update it separately from everything else. The safe-update pattern in updating WordPress safely is worth following going forward so you're never updating five things at once when something breaks.

If none of this fixes it

Occasionally the underlying issue is a corrupted database table or a connection problem rather than the save request itself. If pages generally feel broken, not just the editor, check fixing WordPress database connection errors.

When to open a ticket

If you've checked permissions, raised PHP limits, and ruled out a plugin conflict but saves still fail, open a ticket from the portal (Support → New ticket). Include the exact error from the browser console and which of the steps above you've already tried. It's a real person on the other end, not a bot, and having the console error ready saves a round trip.