Hi @bboehm33 ,
Thanks for the detailed report. I’ve reviewed our REST code for v3.7.2 and it looks correct on both sides (the PUT route is registered properly, the admin permission check is standard
manage_options, and the editor sends the X-WP-Nonce header on save). The 401 rest_forbidden response means WordPress itself sees the request as not authenticated when processing the PUT — even
though GET from the same page works. That almost always points to something in the environment, not the plugin.
Could you run these checks for me so we can narrow it down?
Open DevTools → Network tab, reproduce the error, click the failed PUT request, and check the Request Headers:
- Is there a Cookie: header, and does it include a value starting with wordpress_logged_in_…?
- Is there an X-WP-Nonce: header with a value (not empty)?
Please send me a screenshot of the Request Headers section (you can redact the cookie values). This is the single most important piece of information.
Timing test:
- Open the email editor and immediately (within a few seconds) click Save. Does it still fail?
- If it only fails after the editor has been open for a while → expired nonce.
- If it fails immediately on a fresh load → something is stripping auth on PUT.
Check for MU-plugins / security plugins that stay active even when “all plugins are deactivated”:
- Look in wp-content/mu-plugins/ — is there anything in there?
- Are Wordfence, iThemes/Solid Security, NinjaFirewall, WP Cerber, or similar installed (even if deactivated in the plugin list)? Some register as must-use plugins and keep running.
Enable WP debug logging:
In wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reproduce the error once, then send me the last ~50 lines of wp-content/debug.log.
Host / WAF question (please ask your host specifically this, not just “do you block PUT”):
Does your WAF, ModSecurity, or reverse proxy strip or modify Cookie or X-WP-Nonce headers on PUT requests to /wp-json/*? And do preflight OPTIONS requests pass through with credentials?
“We don’t block PUT” is not the same as “we pass PUT headers through unchanged” — this wording forces a precise answer.
Are you behind Cloudflare or another CDN?
If yes, try temporarily pausing Cloudflare (Overview → Pause on Site) and retry. Bot Fight Mode and some security rules strip auth on non-GET requests.
Quick isolation test: open the editor in a private/incognito window, log in fresh as administrator, edit a template, save immediately. Does it still fail?
Once I have the answers (especially #1 and the debug log from #4), I can tell you exactly what’s happening. Based on what you’ve described so far, my best guesses are an expired nonce from a
long editor session, or a host-side WAF rule stripping cookies on PUT — but I need the headers to confirm.
Thanks,
Marc
