I'm experiencing a werid issue I never ran into before. I'm on WordPress 6.3.1 and each time I try to publish a post on my blog I get the "Updating failed. The response is not a valid JSON response." notice and POST {my_site}/wp-json/wp/v2/posts/{post_ID}?_locale=user 403 (Forbidden)' related to api-fetch.min.js on the browser's console.

Here's a few more info and an overview of what I already tried without success.

  • No matter if I write a post from scratch or copy-paste the content: as soon as I add a non-text block (which can be a separator, an image or a YouTube embed) between two blocks, it doesn't publish.

  • I'm using the default editor (Block Editor, aka Gutenberg). No page editor plugins installed.

  • I temporarily deactivated all plugins and themes and cleared the browser's cache.

  • I tried with different WP site accounts and roles (admin, editor, author).

  • I used different browsers with all extensions disabled, from different devices and networks / locations as well.

  • I sanitized all paragraphs and strings.

  • User is still logged in, session didn't expire.

  • If I save the post as a draft, no errors are returned.

  • If I place an image block or a non-text block to the very end of the post, I'm able to publish it successfully with no errors. If I move that block between two paragraph blocks, I get 403 when trying to publish.

  • I'm able to successfully publish posts containing text and heading blocks only.

  • If I leave the editor open without saving, the browser's console returns POST {my_site}/wp-admin/admin-ajax.php 415 (Unsupported Media Type) referring to jquery.min.js?ver=3.7.0:2 as well. Not sure if it's related.

  • In the 403 call details, HTML returned in the Content key of the request payload is valid and doesn't contain weird char or tags. Response returns an HTML page that doesn't seem to be related to WordPress (but not sure), showing "Error — You do not have permission to access this document".

  • There's no firewall app or security measure at server / hosting level.

  • This issue appeared recently but I have no clue about when precisely and what may have caused it.

Any idea what else I can check? I'm running out of options.

  • is the user still logged in? This can happen if you leave the block editor open for a long time and you're logged out or your session expires behind the scenes, you can also look at the request in the dev tools and see what the response was, not just its HTTP header code but the HTML it returned, this can tell you if it's a plugin or host level firewall/security software/etc. Additionally, the block editor uses the REST API but your question mentions the old admin-ajax.php, and doesn't include the action and other parameters it was called with that might give clues, can you edit that in?
    – Tom J Nowell
    Oct 3, 2023 at 11:01
  • @TomJNowell Thanks for your suggestions. Yes, user is still logged in and session is active. On the Request Payload, the Content key has valid HTML and the response returns Server Error — You do not have permission to access this document.. Regarding admin-ajax.php, I can't find any additional info apart from what I reported above, but that's likely unrelated to the 403 issue and it randomly occurs. I updated the thread with additional details, BTW.
    – Css14
    Oct 3, 2023 at 12:58
  • It's very likely that admin-ajax.php is super critical to this, requests to that file always have an action parameter that tells it which AJAX handler to call, a critical clue to which code is responsible and where to look next. I guarantee the information is in your browser dev tools, look at the network tab. Also when you say "You do not have permission to access this document" can you be more specific? e.g. is it in a WP Die box with a gray background? An Nginx message? An Apache message? Does it list server or software names and versions? CDNs? Domains/URLs? Are parts in H2/H3's?
    – Tom J Nowell
    Oct 3, 2023 at 13:16
  • Also it would be helpful to isolate testing to a specific block that you can name, ideally one that's a part of core. It's also unlikely that the message about unsupported media type is the full message, a stack trace would be helpful, as well as an explanation of what you meant by "I sanitized all paragraphs and strings.". Avoid describing things in favor of screenshots and direct copy pastes, avoid stripping out parts that look unnecessary ( unhelpfully helpful ) such as informational messages before/after that don't look relevant.
    – Tom J Nowell
    Oct 3, 2023 at 13:18
  • also err on the side of specificity, e.g. instead of non-text block, put a code block and copy paste an example of raw block markup that has the issue
    – Tom J Nowell
    Oct 3, 2023 at 13:21

1 Answer 1


After carefully checking the hosting settings again, I found out that Plesk's firewall was too restrictive. Each API call was going through it and — in most cases — any non-text block was mistakenly detected as WordPress Unauthenticated Content Injection vulnerability, for some reason. I noticed it in the firewall's log.

Whitelisting Gutenberg in the rules set and changing the firewall mode to "Detection only" fixed the issue.

Firewall settings in Plesk

Not sure if a Plesk's update caused it. Nobody changed the firewall rules recently and the 403 issue appeared only a few days ago. I'll report it to Plesk, in case it's a bug.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.