Make WordPress Core

Opened 8 weeks ago

Closed 4 weeks ago

#60928 closed defect (bug) (invalid)

Interactivity API: Fatal error with empty image

Reported by: donohoe's profile donohoe Owned by:
Milestone: Priority: normal
Severity: normal Version: 6.5
Component: Editor Keywords: reporter-feedback close
Focuses: Cc:

Description

My team was investigating a 500 internal server error. We are not clear on if this bug relates to specific issue (as it affected the homepage, and this relates to a Post) but it surfaced other problems.

We have a published post from 2023 and one more from 2022.

When accessing the published URL there was an issue rendering the page as soon as it got to the core content of the story. See screenshot.

Example from log files:

PHP Fatal error: Uncaught TypeError: {closure}(): 
Argument #1 ($content) must be of type string, null given, 
called in /wordpress/core/6.5/wp-includes/class-wp-hook.php on line 326 
and defined in /wordpress/core/6.5/wp-includes/interactivity-api/interactivity-api.php:46 

Stack trace: 
#0 /wordpress/core/6.5/wp-includes/class-wp-hook.php(326): {closure}(NULL, Array) 
#1 /wordpress/core/6.5/wp-includes/plugin.php(205): WP_Hook->apply_filters(NULL, Array) 
#2 /wordpress/core/6.5/wp-includes/class-wp-block.php(525): apply_filters('render_block_co...', NULL, Array, Object(WP_Block)) 
#3 /wordpress/core/6.5/wp-includes/blocks.php(1705): WP_Block->render() 
#4 /wordpress/core/6.5/wp-includes/blocks.php(1743): render_block(Array) 
#5 /wordpress/core/6.5/wp-includes/class-wp-hook.php(324): do_blocks('<!-- wp:paragra...') 
#6 /wordpress/core/6.5/wp-includes/plugin.php(205): WP_Hook->apply_filters('<!-- wp:paragra...', Array) 
#7 /wordpress/core/6.5/wp-includes/post-template.php(256): apply_filters('the_content', '<!-- wp:paragra...') 
#8 /srv/htdocs/wp-content/themes/orbis/template/content.php(169): the_content('Continue readin...') 
#9 /wordpress/core/6.5/wp-includes/template.php(812): require('/srv/htdocs/wp-...') 
#10 /wordpress/core/6.5/wp-includes/template.php(745): load_template('/srv/htdocs/wp-...', false, Array) 
#11 /wordpress/core/6.5/wp-includes/general-template.php(206): locate_template(Array, true, false, Array) 
#12 /srv/htdocs/wp-content/themes/orbis/single-post.php(20): get_template_part('template/conten...', 'post') 
#13 /wordpress/core/6.5/wp-includes/template-loader.php(106): include('/srv/htdocs/wp-...') 
#14 /wordpress/core/6.5/wp-blog-header.php(19): require_once('/wordpress/core...') 
#15 /wordpress/core/6.5/index.php(17): require('/wordpress/core...') 
#16 {main} thrown in /wordpress/core/6.5/wp-includes/interactivity-api/interactivity-api.php on line 46

We were also unable to open the Post in the WP Admin. Error screen with text:

There has been a critical error on this website. Please check your site admin email inbox for instructions.

We exported the Post using the Export tool to review the contents. The only anomaly was this empty image markup:

<!-- wp:image -->
<figure class="wp-block-image"><img alt=""/></figure>
<!-- /wp:image -->

When we used this in the Code Editor on a local environment running earlier version of WordPress (perhaps 6.2?) and it worked fine. We upgraded it to 6.5 and were seeing the same problems.

We searched the exported XML for this and found one other Post with this same markup. In testing the Post web page it also had the same problem.

Attachments (1)

image-error.png (3.1 MB) - added by donohoe 8 weeks ago.
Screenshot of affected Post

Change History (15)

@donohoe
8 weeks ago

Screenshot of affected Post

#1 @swissspidy
8 weeks ago

  • Component changed from Upgrade/Install to Editor
  • Milestone changed from Awaiting Review to 6.5.1
  • Severity changed from major to normal
  • Summary changed from 500 Error on Posts with empty image to Interactivity API: Fatal error with empty image

#2 @poena
8 weeks ago

Hi @donohoe and welcome to WordPress Trac

I am not able to reproduce this only by adding the code for the blank image to a post or page in the block editor.

Can you please provide more information, including server type and PHP version?
Is there a render filter applied on the image block?
Are you able to test if this still occurs if you disable all plugins and use a bundled block theme like Twenty Twenty-Four or a bundled classic theme like Twenty Twenty-One?

#3 @poena
8 weeks ago

  • Keywords reporter-feedback added

#4 @davidbaumwald
7 weeks ago

  • Milestone changed from 6.5.1 to 6.5.2

Milestone renamed

#5 @jorbin
7 weeks ago

  • Milestone changed from 6.5.2 to 6.5.3

This ticket was mentioned in Slack in #core by jorbin. View the logs.


6 weeks ago

#7 @grantmkin
6 weeks ago

@donohoe Do you have any other details that might help us reproduce this error? @poena 's list is a good starting point:

  • Can you please provide more information, including server type and PHP version?
  • Is there a render filter applied on the image block?
  • Are you able to test if this still occurs if you disable all plugins and use a bundled block theme like Twenty Twenty-Four or a bundled classic theme like Twenty Twenty-One?

#8 @rasshivkina
5 weeks ago

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

This ticket was mentioned in Slack in #core by jorbin. View the logs.


5 weeks ago

#10 @grantmkin
5 weeks ago

@rasshivkina Thanks for following up with details, and I'm glad you found a fix for your issue!

I'm not sure what filter you were using on the image block. If it was render_block_core/image, and the callback was returning null for block content, I think it's expected that could cause issues.

The $block_content value returned by the filter is expected to be a string (see the filter documentation here: https://developer.wordpress.org/reference/hooks/render_block_this-name/)

From the error shared in the ticket description, the type hinting added to the static closure within wp_interactivity_process_directives_of_interactive_blocks seems to be what's triggering the error, and this code is new since WP 6.5. But since the render_block_{$this->name} filter is expected to return a string, I don't think there's anything to fix within the WordPress code. Block render output is generally always expected to be a string.

#11 @poena
4 weeks ago

  • Keywords close added

Based on the replies here, I suggest closing this ticket.

#12 @rasshivkina
4 weeks ago

Thanks for following up! I do think the new type hinting and our incorrect returning of null was the cause of the original issue.
I'm still confused by the second issue mentioned though. As far as we could tell, the broken articles didn't contain any empty image blocks, but were still surfacing a similar error that was also resolved by the same fix. Any thoughts?

This ticket was mentioned in Slack in #core by jorbin. View the logs.


4 weeks ago

#14 @jorbin
4 weeks ago

  • Milestone 6.5.3 deleted
  • Resolution set to invalid
  • Status changed from new to closed

Depending on how the callback was implemented, if it returned null even when the image wasn't empty it would still cause this problem. Are you able to share what the function looked like before you fixed it? If it's too sensitive of code, perhaps a stripped-down version?

I'm marking this as closed for now but the discussion should continue and it should be reopened if there is a change to core that would help.

Note: See TracTickets for help on using tickets.