Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

The WordPress Block Editor Says “The Response Is Not a Valid JSON Response”

The block editor saves through the WordPress REST API. The message means it received something other than the expected JSON: an HTML error page, redirect, login form, firewall block, PHP warning or malformed response.

Preserve the failing REST request before changing permalinks or disabling security.

Inspect the save request

Open Network, save a controlled draft once and find /wp-json/wp/v2/.... Record method, status, response headers/body and timing.

Interpret:
301/302 -> URL/HTTPS/login redirect
401/403 -> nonce/capability/firewall
404 -> REST/permalink/server routing
500 -> PHP/application fatal
200 HTML -> cache/warning/login response

Redact nonce, cookies and unpublished content.

Test REST discovery

Open /wp-json/ as an anonymous visitor and inspect the link discovery header/source on the site. Authentication-required post endpoints will behave differently.

Use Site Health and WP-CLI where available. A public REST index being visible is normal WordPress behaviour; do not block all REST routes as a generic security measure.

Check whether only one post type/plugin endpoint fails.

Align site URLs and HTTPS

home, siteurl and administrator URLs must use the canonical HTTPS host. Mixed www, ports or subdirectory paths can redirect REST requests and invalidate nonces.

Configure reverse-proxy HTTPS detection correctly. Do not trust public forwarded headers.

After migration, use serialisation-aware URL replacement rather than raw SQL.

Repair permalinks and web server rules

Save the current permalink structure to regenerate Apache .htaccess rules after backing it up. On Nginx, WordPress cannot write the server configuration; use the host/admin.

Test /wp-json/ and one standard post endpoint afterward.

Do not replace custom server rules wholesale; preserve language, security and subdirectory routing.

Check firewall and security events

Match the REST request timestamp/path with Cloudflare, ModSecurity, hosting firewall and WordPress security logs. Rule sets may block JSON bodies or certain words in content.

Create a narrow rule correction for authenticated WordPress REST traffic. Do not disable the firewall globally.

If one content string triggers the rule, retain a privacy-safe minimal reproduction for the host.

Remove PHP output contamination

Warnings/notices printed before JSON make the response invalid. Keep display_errors off and log errors privately.

Inspect plugin/theme REST callbacks for echo, debugging var_dump() or closing PHP tags with whitespace.

return rest_ensure_response( $data );

Return structured data/errors; never print around a REST response.

Check cache and optimisation

REST API and administrator save responses must not be publicly cached. Inspect proxy/host/cache headers.

Exclude authenticated REST routes and nonces from full-page cache. Purge after rule changes, then test after cache warm-up.

Avoid delaying core editor JavaScript in administrator screens.

Check application passwords and external editors

If only a mobile app or external editor fails, test its REST authentication separately. WordPress Application Passwords depend on HTTPS, the correct username and an active credential.

Revoke and recreate only the affected application password; do not share the main account password. Check Basic Authorization headers survive the proxy/web server. Treat those credentials as secrets and limit the account’s role.

Inspect post-type REST support and schema

Custom post types must register show_in_rest and a compatible controller/schema for block editor use. Custom meta exposed to REST needs proper registration, type, sanitisation and authorisation.

register_post_meta( 'example', 'example_key', array(
    'show_in_rest' => true,
    'single'       => true,
    'type'         => 'string',
) );

Add permission/sanitisation appropriate to the data; do not expose private metadata simply to silence the editor.

Verify editor operations

Test create, update, autosave, revision, media insertion and publishing for relevant post types and roles. Confirm REST responses remain JSON and no PHP warnings appear.

Recurring care should monitor REST 4xx/5xx and re-test after domain, SSL, firewall and permalink changes. The error is resolved when the editor can reliably read/write, not when the notice disappears once.