Gutenberg: Post Save, Block Previews No Longer Work ( not a valid JSON response) Because of 3rd party Plugin PHP notice

[hubertnguyen]

Post save (and possibly other JS-admin functions) fails when PHP notice happens in unrelated code which gets executed. This could block core functionalities, even though there isn't a real issue and can be caused by any plugin that has PHP notice or warnings.

At the top of the Post Edit screen, we get this message: "Updating failed. Error message: The response is not a valid JSON response."

Some of our custom Gutenberg blocks also refuse to display for the same reason: "The response is not a valid JSON response". Default WP Gutenberg Blocks seem to work, but I haven't checked all of them.

In my case, the WP Minify (1.2.0) is causing the problem
https://wordpress.org/plugins/wp-minify/

When the plugin, is in use, we have this PHP notice, as seen in the Query Monitor "PHP Errors" tab:

"is_feed was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see Debugging in WordPress for more information. (This message was added in version 3.1.0.)"

The same message is found in the HTTP Response Header (X-QM-php-errors-error-1) when GutenBerg tries to display our custom blocks in the editor. Same response header error when we try to save a post.

Note that this PHP notice doesn't cause any error in the live view. Our custom block works and the page displays fine. This issue apparently breaks the WP-Rest functionality for Saving, previewing blocks, and possibly other things that we haven't seen yet.

It doesn't seem like such a PHP Notice in any plugin should take down the ability to save posts. It's not clear why that particular piece of code is executed when we try to save, or preview blocks as well.

If we disable WP-Minify, everything works again.

To reproduce
Steps to reproduce the behavior:

1. Install & Activate WP Minify 1.2.0
2. Create a new Gutenberg-powered post
3. Try to save
4. See error

Expected behavior
I don't expect Gutenberg of any other core functions to be affected by this type of PHP issue in a plugin.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome 80.0.3987.116
• Version [e.g. 22]

Note: this is happening on a localhost Wordpress install we use for development, so
/wp-admin/site-health.php eventually redirects us to the main page.

"The REST API is one way WordPress, and other applications, communicate with the server. One example is the block editor screen, which relies on this to display, and save, your posts and pages.
The REST API call gave the following unexpected result: (404)
404"

We use the REST API, for other things, and it works.

Additional context

• Wordpress 5.3.2
• Our custom blocks are created with Block Lab

• Please add the version of Gutenberg you are using in the description.
• To report a security issue, please visit the WordPress HackerOne program: https://hackerone.com/wordpress.

[johnstonphilip]

If PHP is throwing notices for any reason, I would expect that to show (and thus break) almost any page where that notice is shown, including REST API endpoints. This doesn't seem like a job that Gutenberg should fix, as a PHP warning is intentionally thrown by the thrower, and Gutenberg shouldn't get in the way of that.

The only way I can see to avoid this would be to mute PHP warnings, which is what the WP_DEBUG constant is intended to be used for.

[hubertnguyen]

@johnstonphilip , thanks for chiming in. I commented out define('WP_DEBUG', true);
and define('WP_DEBUG_LOG', true );

But the issue is still there, although the "X-QM-php-errors-error-1" HTTP header is now gone because WP_DEBUG is set to false.

To your point, the issue may be in WP Core or the WP Rest API.

[johnstonphilip]

@hubertnguyen This warning breaking the output of the Rest API is not really a problem, it's actually a solution. The warning is there to make sure developers know something is broken, and that it needs to be fixed. If WP core, Gutenberg, or anything else (even another plugin) were to "mute" those in some way, it defeats the purpose of a PHP warning, allowing a bug/issue to go unnoticed, when it needs attention.

I would probably advise deactivating the plugin in question here, or fixing the call to is_feed.

[hubertnguyen]

@johnstonphilip , I don't mind if it breaks the REST API if WE DEBUG is on, but the same behavior happens with WP DEBUG off. PHP isn't crashing and this can happen with any plugin whose code is getting executed (I suspect WP Minify plugs itself into the_content filter.

So, after any plugin update in production, Post Save or Block Preview (and more) could stop working, even though there's no real/actual problem.

[johnstonphilip]

If it's crashing something, it likely means there's invalid JSON coming back from the REST API, which can happen if invalid code is output at any point during the page load. The warning is likely trying to help you find the source of that problem.

I would check your browser console to see if there's any relevant JS messages there, and also check the response of calls to the REST API that failed (on the Network tab of the inspector in Chrome) and paste it into a JSON validator to see which parts are invalid. This will help to narrow that down for you.

When you mentioned this error, it points to that being true:
The response is not a valid JSON response

[hubertnguyen]

100% agree. I suspect it may be a JSON encoding issue. Just to confirm what is the expected text output for a Gutenberg Block?

[johnstonphilip]

I do not think it is a JSON encoding issue. I think you have invalid output, crammed up with the proper JSON.

[hubertnguyen]

As an example, if my block outputs:

echo('

Some text

');

The response is below, which is Invalid JSON.

{
"rendered": " style = 'font-size: 25px; color: #f47121;'
class = 'has-text-align-center' > \"SOME TEXT\"

"
}

A filter force the text to be upper-case and adds the CSS style (and yes, it should really be a class).

[johnstonphilip]

It looks like you might be creating a dynamic block. A block should never use echo. It needs to return the desired output.

https://developer.wordpress.org/block-editor/tutorials/block-tutorial/creating-dynamic-blocks/

[johnstonphilip]

Since this is not a bug with Gutenberg, I am going to suggest that this issue be closed.

[hubertnguyen]

Thanks @johnstonphilip .
Just in case someone else bumps into this issue, here are more details and a solution.

Since we use Block Lab, the "echo()" is the normal way to output the HTML code, since Block Lab uses PHP output buffering to capture the HTML, before re-wrapping it as WP expects it for a dynamic Block.

The problem was that WP-Minify was writtern in a pre-Gutenberg Era, and as such it discarded XMLRPC_REQUEST queries, but not WP-Rest queries. It was basically trying to minify JSON code as it would HTML code.

The solution is to make it discard /wp-json/ queries so I made a small modification to wp-minify.php from line 66 to 73. And since I will upload the modified version anyway, I'll go correct that is_feed() notice too ^^

Thanks for your quick reply on this. Very appreciated!

`
//added this as a simple way to detect a wp-rest request
$is_rest = false;
if (strpos($_SERVER[ 'REQUEST_URI' ], '/wp-json/') !== false) {
$is_rest = true;
}

// No need to minify admin stuff
if (!is_admin() && !is_feed() && !defined('XMLRPC_REQUEST') && !$is_rest) {
  // Don't minify if if user passes wp-minify-off=1 in GET parameter
  if (!(isset($_GET['wp-minify-off']) && $_GET['wp-minify-off'])) {
    add_action('init', array($this, 'pre_content'), 99999);
    add_action('wp_footer', array($this, 'post_content'));
  }
  // advertise hook
  add_action('wp_footer', array($this, 'advertise'));
}

}`