You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a PHP request throws a request error (e.g. PHP Fatal) the Website only prints the error to the browser console and the user sees a white screen (see screenshot).
We could help the user understand what happened if Playground showed an error message or opened the Logs modal instead of displaying a white screen.
PHP.wasm errors (internal to Playground) already do that by showing the Report error modal that contains logs.
Good point, it would be useful to send the same output as server-side PHP would. Let's figure out if that's ever stderr or is it always stdout and make sure it's sent with the response. Or are we already doing that, but there's nothing in stdout because WP_DEBUG is false ?
I did some quick testing and both hosted WP and Playground behave the same.
What I'm suggesting would be an improvement that Playground can offer because it controls the full stack.
Testing details
I used a hosted WP site and Playground, both had the same WP_DEBUG options.
But now when I think about it, a 255 error is internal to PHP and that means it's internal to Playground.
We should show the Error report modal for all 255 errors even if they are request errors.
When a PHP request throws a request error (e.g. PHP Fatal) the Website only prints the error to the browser console and the user sees a white screen (see screenshot).
We could help the user understand what happened if Playground showed an error message or opened the Logs modal instead of displaying a white screen.
PHP.wasm errors (internal to Playground) already do that by showing the Report error modal that contains logs.
Steps to recreate
Screenshots
The text was updated successfully, but these errors were encountered: