[wp-trac] [WordPress Trac] #60928: Interactivity API: Fatal error with empty image

[WordPress Trac]

#60928: Interactivity API: Fatal error with empty image
-------------------------------+---------------------
 Reporter:  donohoe            |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  6.5.3
Component:  Editor             |     Version:  6.5
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+---------------------

Comment (by rasshivkina):

 Hello, and apologies for the delayed reply. I'm a developer on @donohoe's
 team. I believe we may have found the source of the issue: our render
 filter on the image block would return null if the image ID wasn't set;
 when this is changed to return an empty string, the post once again works
 as expected (a post with an empty image block is able to be saved, shows a
 grey rectangle in the CMS, and doesn't display at all on the front-end).
 Previous to a recent update (somewhere between 6.2 and 6.5?), returning
 null produced the same behavior as returning an empty string does now.

 For the sake of thoroughness, in answer to your questions:

 - Server: nginx
 - PHP: 8.1.28
 - We tried to reproduce the error both on a fresh blank site using a
 classic theme (Twenty Twenty-Four) and also within our usual environment.
 On the blank site, we saw the expected behavior. Within our usual
 environment, since the recent update, we were unable to save the post at
 all, receiving the "updating failed, not a valid JSON response" error.

 We also had a new 500 error appear on multiple pre-existing articles more
 recently:


 {{{
 Fatal error: Uncaught Error: {closure}(): Argument #1 ($content) must be
 of type string, null given, called in
 /wordpress/core/6.5.2/wp-includes/class-wp-hook.php on line 326
 in /wordpress/core/6.5.2/wp-includes/interactivity-api/interactivity-
 api.php on line 46
 Call stack:
 {closure}()
 wp-includes/class-wp-hook.php:326 WP_Hook::apply_filters()
 wp-includes/plugin.php:205 apply_filters()
 wp-includes/class-wp-block.php:525 WP_Block::render()
 wp-includes/blocks.php:1705 render_block()
 wp-includes/blocks.php:1743 do_blocks()
 wp-includes/class-wp-hook.php:324 WP_Hook::apply_filters()
 wp-includes/plugin.php:205 apply_filters()
 wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php:632
 WP_REST_Revisions_Controller::prepare_item_for_response()
 wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php:451
 WP_REST_Autosaves_Controller::prepare_item_for_response()
 wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php:314
 WP_REST_Autosaves_Controller::get_items()
 wp-includes/rest-api/class-wp-rest-server.php:1230
 WP_REST_Server::respond_to_request()
 wp-includes/rest-api/class-wp-rest-server.php:1063
 WP_REST_Server::dispatch()
 wp-includes/rest-api.php:555 rest do request()
 }}}

 A few curious things about this error:
 - Fairly more widespread, we found it on at least a handful of articles,
 but, as far as we can tell, only in our staging environment
 - If we cloned the post producing the error, the identical cloned post
 worked just fine. If we exported the post and imported it into our local
 dev environments, the imported post worked just fine.
 - There were no empty image blocks in the broken posts--nevertheless, the
 above fix (returning an empty string rather than null) fixed the error

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60928#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform