The publish button stops working. Or clicking Publish shows “Updating…” indefinitely without completing. Or the post saves as a draft when publish was clicked. Or a scheduled post never publishes. Or the editor throws “The response is not a valid JSON response” when saving. A WordPress publish error prevents content from reaching the site and can take several forms — each pointing to a different underlying cause that requires a targeted fix. For the bigger picture, our WordPress Errors Complete Guide pulls everything together.
WordPress Publish Error — REST API Failures
The most common WordPress publish error in the block editor is a REST API communication failure — the block editor uses the WordPress REST API to save posts, and when that API call fails, the editor cannot complete the publish action. The console message “The response is not a valid JSON response” or “Failed to save the post” points directly to a REST API issue.
Diagnose the REST API: WordPress admin → Tools → Site Health → check for “The REST API encountered an error” in the Status tab. If this test fails, it reports the specific error. Common REST API failures: a security plugin or server firewall blocking REST API requests, the WordPress home URL and site URL mismatch causing redirect loops in the REST API responses, or .htaccess rules interfering with the /wp-json/ endpoint. Fix a security plugin block: temporarily deactivate all security plugins → try publishing → if it succeeds, the security plugin is blocking the REST API. Re-enable the security plugin → find its REST API whitelist or allowlist settings → add /wp-json/ to the allowlist.
The WordPress publish error caused by a home URL / site URL mismatch produces a REST API endpoint that redirects rather than responds with JSON — the editor receives an HTML redirect response instead of the expected JSON, causing the “not a valid JSON response” error. Check Settings → General → WordPress Address (URL) and Site Address (URL) — these must match exactly (including https vs http prefix). If they differ, update the incorrect one. In wp-config.php, ensure WP_HOME and WP_SITEURL constants are not set to different values. After correcting URL mismatches, flush permalinks (Settings → Permalinks → Save Changes) to regenerate rewrite rules. According to the WordPress developer documentation, the REST API endpoint at /wp-json/ must be accessible without redirects for the block editor to function correctly — any redirect (HTTP to HTTPS, www to non-www, or domain to domain) in the REST API request path causes a JSON parse error that the editor reports as a publish failure.
Classic Editor and Metabox Publish Errors
The classic editor (or block editor with certain plugins) produces a different category of WordPress publish error — the post saves via a form submission rather than REST API, and failures appear as page reload errors, missing nonce errors, or silent saves to draft that ignore the Publish click.
Nonce expiration causes a WordPress publish error where the form submits but shows “Are you sure you want to do this?” instead of publishing. WordPress nonces expire after 24 hours by default — editing a post for more than 24 hours without page refresh produces this error on submit. Fix: click “Please try again” or reload the editor and save immediately. For teams that regularly leave posts in draft with the editor open overnight, increase the nonce lifetime: define('NONCE_LIFE', 86400 * 2); in wp-config.php (48-hour nonces). The “Are you sure?” message specifically indicates nonce expiry rather than any content or permission issue — it requires no other fix than refreshing the nonce by reloading the editor.
A metabox plugin causing a WordPress publish error produces a PHP error during the post save process that interrupts the save before WordPress can update the post status. The error may appear as a blank white screen after clicking Publish, a partial save where some fields update but not others, or an error message from the metabox plugin. Enable debug logging → try publishing → check /wp-content/debug.log for PHP errors timed to the save attempt → identify the metabox plugin from the file path in the error → update or deactivate that plugin. Our guide on fixing WordPress fatal errors covers the debug logging setup that captures the PHP errors during publish attempts, providing the specific file and line number needed to identify which plugin or theme code is causing the WordPress publish error during the post save hook execution.
Scheduled Post Publish Failures
Scheduled post failures are a distinct WordPress publish error — posts that were correctly scheduled but never automatically publish at the set time — is a WP-Cron reliability problem rather than a publish mechanism failure. The post sits in “Scheduled” status indefinitely even after the publish time passes.
WP-Cron runs on visitor-triggered page loads — if no visitors arrive during the scheduled publish window (overnight schedules on low-traffic sites), the cron job that publishes the post never fires. Fix this WordPress publish error by replacing WP-Cron with a real server cron: disable WP-Cron in wp-config.php (define('DISABLE_WP_CRON', true);) → add a server cron job that hits the WordPress cron URL every 5 minutes: */5 * * * * wget -q -O - https://yoursite.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1. With a real server cron, scheduled posts publish within 5 minutes of their scheduled time regardless of visitor traffic, eliminating the scheduled post WordPress publish error from WP-Cron unreliability. Our guide on fixing WordPress scheduled posts not publishing covers the complete WP-Cron configuration including the server cron setup and the monitoring approach that confirms scheduled publishing is working reliably after the fix.
Permission Errors and Capability Failures
A WordPress publish error where the Publish button is greyed out, clicking it does nothing, or the post status dropdown does not include “Published” as an option indicates a user capability problem — the current user does not have the “publish_posts” capability for the post type they are editing.
Check the current user’s capabilities: install User Role Editor plugin → Users → All Users → click the user → Edit → User Role Editor → the capabilities list shows all capabilities assigned to that user. Find “publish_posts” in the list — it must be checked for the user to publish standard posts. For custom post types, the required capability may be “publish_[post_type]” — a custom post type registered with 'capability_type' => 'product' requires “publish_products” rather than “publish_posts.” If the capability is missing, add it in User Role Editor or modify the user’s role to include it. For a user who has always been able to publish but suddenly cannot, check whether their role was changed — a user switched from Author to Contributor loses publish access because the Contributor role lacks the publish_posts capability by design.
Site-wide WordPress publish error affecting all users simultaneously (everyone lost the ability to publish) points to a global configuration change — a plugin that modified role capabilities across the site, a wp-config.php change that restricted access, or a corrupted wp_user_roles option in the database. Check wp_user_roles in phpMyAdmin → wp_options → search for option_name = wp_user_roles → the option_value contains the serialised array of all role capabilities. If this value is corrupted or missing the publish_posts capability for the author and editor roles, restore it from a pre-corruption backup of wp_options. For agencies managing multiple client sites, keeping a reference export of the wp_user_roles option from a known-good site provides a recovery baseline if role capabilities become corrupted. Reviews from the WordPress support community confirm that REST API blocks from security plugins and WP-Cron failures account for the majority of WordPress publish error reports — resolving both the security plugin REST API allowlist and the WP-Cron reliability covers the most commonly encountered publish failure scenarios across all WordPress site types and hosting environments. Our guide on managing WordPress user roles covers the role and capability system in depth, including the publish_posts capability assignment that determines which users can publish versus only save drafts.
Browser extensions cause an underreported category of WordPress publish error — ad blockers, privacy extensions, and content filters sometimes block the REST API requests that the block editor makes to publish posts, because the request URL or payload matches patterns those extensions flag. The symptom: publishing works in one browser but not another, or fails with no error message in the block editor. Test by publishing in an incognito window with all extensions disabled — if publishing succeeds in incognito, an extension is blocking the request. Disable extensions one at a time in the main browser to identify the culprit. Common offenders: uBlock Origin with aggressive settings, Privacy Badger, Ghostery, and some VPN browser extensions that intercept API calls. Whitelisting the site’s domain in the extension’s settings allows the REST API calls through while maintaining extension protection on other sites. This browser-side WordPress publish error cause is particularly common on development machines where developers run more aggressive browser privacy settings than typical visitors.
Database lock errors cause a WordPress publish error that is rare but highly disruptive when it occurs: the post save triggers a MySQL table lock that prevents the post status update from completing. Symptoms: publish appears to succeed (no error shown) but the post remains in “Draft” status on reload, or an error appears about the database being unavailable during the save. On shared hosting, MySQL table locks often result from another process (a backup, an import operation, or another plugin’s database query) holding an exclusive lock on the wp_posts table during the publish attempt. The fix: wait for the locking process to complete, then try publishing again. Persistent locking issues indicate a plugin making inefficient database operations — enable the MySQL slow query log to identify the problematic queries. On VPS hosting with root access, SHOW PROCESSLIST; in the MySQL console shows all active queries and identifies any that are blocking the publish save. Our guide on WordPress database maintenance covers the table optimisation and repair procedures that address the underlying database health issues that can contribute to lock contention during high-load publish operations.
The Gutenberg editor’s autosave mechanism creates a specific type of WordPress publish error: the autosave runs simultaneously with a manual publish click, and if the autosave has not completed when publish is clicked, the two operations conflict. The editor shows “Saving…” and “Publishing…” simultaneously, which resolves itself when the autosave completes — the publish then proceeds normally. If this conflict causes the publish to fail, wait for the autosave indicator (visible in the block editor toolbar) to show “Saved” before clicking Publish. To reduce autosave frequency: define('AUTOSAVE_INTERVAL', 300); in wp-config.php sets autosave to every 5 minutes instead of the default 60 seconds, reducing the chance of autosave-publish conflicts on slow hosting where autosave operations take several seconds to complete. This configuration change trades more frequent autosave safety (shorter content loss window) for fewer publish conflicts — appropriate for stable production environments and less appropriate for development environments where content crashes or refreshes are more common. The balance between autosave frequency and WordPress publish error risk from conflicts should be calibrated based on the site’s hosting performance and the editorial workflow’s tolerance for potential content loss between autosaves.
WooCommerce product publish errors have WooCommerce-specific causes alongside the general WordPress publish failures. A WordPress publish error on the product edit page often relates to product validation — WooCommerce validates product data before publishing (required SKU, valid price format, inventory settings) and returns validation errors that appear as publish failure notices rather than standard WordPress publish errors. The error message typically appears as a red notice at the top of the product edit page naming the specific validation failure (missing required field, invalid price, inconsistent variation settings). Fix the indicated validation error and re-attempt publishing. For WooCommerce product variations, a WordPress publish error related to max_input_vars can prevent complex variable products from saving — increasing the PHP max_input_vars limit (as described in our guide on fixing WordPress max input vars) resolves this for products with many variations. WooCommerce-specific product publish errors are always described in the admin notice that appears after the failed save attempt — reading the notice before attempting any technical fix is the fastest path to the correct solution.
Recovering unsaved content after a WordPress publish error that caused content loss uses WordPress’s post revision system. Every time the autosave or manual save succeeds, WordPress creates a revision. If the publish attempt fails and the browser is closed before the content is recovered, navigate to: Posts → All Posts → find the affected post (it may be in Draft status) → edit it → Screen Options → check “Revisions” → the Revisions meta box appears showing all saved versions. Click “Compare” for the most recent revision to see what content was saved before the publish failure. “Restore This Revision” rolls the post back to any saved version. The autosave (every 60 seconds by default) creates a separate entry from the explicit save — even if the explicit save failed, autosave revisions may contain the content up to 60 seconds before the failure. The WordPress revision system is the first recovery resource after any WordPress publish error that may have resulted in content loss — checking revisions before recreating lost content saves significant time when the content was autosaved even if the explicit publish failed.
