I'm using WP JSON to return JSON for certain routes.

Prior to WordPress 5, WP JSON would return PHP errors in the response, e.g. Notice:xxx or Warning:xxx when a PHP error was encountered. Since I upgraded to WordPress 5, such errors are supressed/ skipped and JSON is returned. Fatal errors return a 500 as expected.

I cannot find any documentation identifying why these errors are not being returned. And Google doesn't seem to be shedding any light. Does anybody know what's going on? Also, if it's "toggleable", does anyone know how to "turn errors on"?

PHP outputs errors to screen as usual elsewhere in WordPress.

  • Do they not appear in your servers PHP error log file? Keep in mind that warnings would mean invalid json gets output which would break many sites – Tom J Nowell Jan 20 at 3:15
  • You probably had WP_DEBUG enabled, hence you got those PHP notices and warnings? So you could enable it back and see if the notices/warnings come up. But about why it was suddenly disabled, I don't know for sure. – Sally CJ Jan 20 at 6:20
  • @TomJNowell yes they appear in the PHP log. Fatal errors produce invalid JSON. Whilst in development, it would be very useful if Notices, and Warnings did too. – dewd Jan 20 at 19:54
  • @SallyCJ WP_DEBUG is enabled and errors show for WordPress generally, just not via calls to the JSON API. – dewd Jan 20 at 19:55
  • Rather than trying to undo the fix to show the errors in the browser, consider alternatives that give far more options, such as debuggers, error handlers, etc – Tom J Nowell Jan 20 at 20:07

REST API should always return JSON, so it’s output can be parsed as such. If it’ll return something that is not correct JSON, then your JS scripts may stop working.

This is why there should be no errors printed in these requests - such messages break JSON response and make it hard to parse.

And there was some code that was trying to prevent such messages from occurring, but it wasn’t working properly.

This was fixed in 5.0 in bug #44534.

You can always add this code to your method, id you're really (really really really) sure, what you're doing:

if ( true === WP_DEBUG ) @ini_set( 'display_errors', 1 );

PS. You should never display errors on production server - it’s compromising security of your site. Always use files as logging method. (It’s also easier)

  • You are right about messages breaking JSON. That's exactly what I want to happen in a development environment, and it has been happening. Instead I'm getting back JSON which hasn't been processed properly and is showing incorrect results. Far worse than broken JSON. And yes, this is very much a development environment. I have dev, dev stage, test stage, test, pre prod and prod, so we're a way off from switching errors off yet. – dewd Jan 20 at 19:59
  • ....and thx for the link to the bug fix - which I thought was a feature rather than a bug! – dewd Jan 20 at 20:02
  • 1
    You shouldn't rely on printing out errors in development either, there's much better alternatives, such as XDebug, XHProf, error logs, etc. You can hook up a debugger so that when an error occurs it shows up in your editor with execution paused so that you can inspect the variables and see the stack trace, or with xdebug have it log the strack trace and URL. Having them show up in the browser is unnecessary and suboptimal. Also, consider using QueryMonitor, which tries to bundle that information in the JSON itself – Tom J Nowell Jan 20 at 20:06
  • @TomJNowell That may be the case, and what you say is best practice, however, in my opinion, suppressing errors in an environment which has debugging switched on is counter intuitive. Also, in the spirit of stack exchange, whilst very much appreciated, this question has not asked for best practice. This particular answer points to the ticket from which can be derived a method in switching WP JSON errors back on, ie if(WP_DEBUG === true) @ini_set( 'display_errors', 1 ); – dewd Jan 20 at 20:26
  • 1
    @dewd it's not a problem, I've added your suggestion. – Krzysiek Dróżdż Jan 20 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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