#60928 closed defect (bug) (invalid)
Interactivity API: Fatal error with empty image
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 6.5.4 |
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)
Change History (18)
#1
@
10 months 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
@
10 months 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?
This ticket was mentioned in Slack in #core by jorbin. View the logs.
10 months ago
#7
@
10 months 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
@
10 months 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.
10 months ago
#10
@
10 months 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.
#12
@
10 months 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.
10 months ago
#14
@
10 months 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.
#15
follow-up:
↓ 16
@
8 months ago
- Version changed from 6.5 to 6.5.4
Thsi closed issue happening with me too, after upgrade from 6.4.3 to 6.5.4, but in all post with the image block on content. like this...
<!-- wp:image {"id":226159,"sizeSlug":"full","linkDestination":"none"} --> <figure class="wp-block-image size-full"><img src="https://noataque.local/wp-content/uploads/2024/06/53782904335_2d2f19b211_c.jpg" alt="Gustavo Scarpa deve atuar novamente pelo lado esquerdo no Atlético" class="wp-image-226159"/><figcaption class="wp-element-caption">Gustavo Scarpa deve atuar novamente pelo lado esquerdo no Atlético</figcaption></figure> <!-- /wp:image -->
I made some tests removing the block and work withouth problemas.
I got back to old version (6.4.3) and works withouth problem.
Is a legacy code, and have several issues on them, the most relevant is full of custom post types and taxonomies.
I trying to figured out how to identify what is causing that in my own theme code.
[11-Jun-2024 22:39:52 UTC] PHP Fatal error: Uncaught TypeError: {closure}(): Argument #1 ($content) must be of type string, null given, called in /var/www/noataque/public_html/wp-includes/class-wp-hook.php on line 326 and defined in /var/www/noataque/public_html/wp-includes/interactivity-api/interactivity-api.php:46 Stack trace: #0 /var/www/noataque/public_html/wp-includes/class-wp-hook.php(326): {closure}() #1 /var/www/noataque/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters() #2 /var/www/noataque/public_html/wp-includes/class-wp-block.php(525): apply_filters() #3 /var/www/noataque/public_html/wp-includes/blocks.php(1705): WP_Block->render() #4 /var/www/noataque/public_html/wp-includes/blocks.php(1743): render_block() #5 /var/www/noataque/public_html/wp-includes/class-wp-hook.php(324): do_blocks() #6 /var/www/noataque/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters() #7 /var/www/noataque/public_html/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php(1865): apply_filters() #8 /var/www/noataque/public_html/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php(569): WP_REST_Posts_Controller->prepare_item_for_response() #9 /var/www/noataque/public_html/wp-includes/rest-api/class-wp-rest-server.php(1230): WP_REST_Posts_Controller->get_item() #10 /var/www/noataque/public_html/wp-includes/rest-api/class-wp-rest-server.php(1063): WP_REST_Server->respond_to_request() #11 /var/www/noataque/public_html/wp-includes/rest-api.php(555): WP_REST_Server->dispatch() #12 /var/www/noataque/public_html/wp-includes/rest-api.php(2922): rest_do_request() #13 [internal function]: rest_preload_api_request() #14 /var/www/noataque/public_html/wp-includes/block-editor.php(753): array_reduce() #15 /var/www/noataque/public_html/wp-admin/edit-form-blocks.php(77): block_editor_rest_api_preload() #16 /var/www/noataque/public_html/wp-admin/post.php(187): require('...') #17 {main} thrown in /var/www/noataque/public_html/wp-includes/interactivity-api/interactivity-api.php on line 46
#16
in reply to:
↑ 15
;
follow-up:
↓ 17
@
8 months ago
I Discovery the problem is in this function bellow, commenting the hook and resolve the error, my I'm losting my resource:
What WordPress change to cause this error?
How can I implement this better?
//Adicionado crédito as imagens inseridas no Gutenberg function change_image_block( $block_content, $block ) { if(!is_admin()){ if ($block['blockName'] === 'core/image') { if( str_contains( $block['innerHTML'], 'figure')){ if( str_contains( $block['innerHTML'], 'figcaption')){ $block_caption = true; }else{ $block_caption = false; } $imagem_id = $block['attrs']['id']; $imagem = get_post( $imagem_id ); $imagem_legenda = isset($imagem->post_excerpt) ? $imagem->post_excerpt : null; $imagem_credito = isset($imagem->post_content) ? $imagem->post_content : null; $imagem_full = isset(wp_get_attachment_image_src($imagem_id, 'normal-full')[0]) ? wp_get_attachment_image_src($imagem_id, 'normal-full')[0] : null; $imagem_desktop = isset(wp_get_attachment_image_src($imagem_id, 'normal-desktop')[0]) ? wp_get_attachment_image_src($imagem_id, 'normal-desktop')[0] : null; $imagem_mobile = isset(wp_get_attachment_image_src($imagem_id, 'normal-mobile')[0]) ? wp_get_attachment_image_src($imagem_id, 'normal-mobile')[0] : null; $imagem_alt = get_post_meta($imagem_id, '_wp_attachment_image_alt', true ); if($block_caption){ $search = "/(<figure(.*?)>)(.*?)(<figcaption(.*?)>)(.*?)(<\/figcaption>)(<\/figure>)/"; if($imagem_credito){ $figcaption = '<figcaption $5><small class="image-subtitle">$6</small><small class="image-credit">(foto: '.$imagem_credito.')</small></figcaption>'; $alt = $imagem_alt.' - (foto: '.$imagem_credito.')'; }else{ $figcaption = '<figcaption $5><small class="image-subtitle">$6</small></figcaption>'; $alt = $imagem_alt; } }else{ $search = "/(<figure(.*?)>)(.*?)(<\/figure>)/"; if($imagem_credito){ $figcaption = '<figcaption class="wp-element-caption"><small class="image-credit">(foto: '.$imagem_credito.')</small></figcaption>'; $alt = '(foto: '.$imagem_credito.')'; }else{ $figcaption = ''; $alt = ''; } } if(isset($block['attrs']['width'])){ $width = $block['attrs']['width']; }else{ $width = '100%'; } if(isset($block['attrs']['height'])){ $height = $block['attrs']['height']; }else{ $height = '100%'; } if( str_contains( $block['innerHTML'], 'is-resized')){ $replace = '<div class="wp-block-image"><figure $2> <picture> <source srcset="'.$imagem_mobile.'" media="(max-width: 1023px)"> <source srcset="'.$imagem_desktop.'" media="(min-width: 1024px) and (max-width: 1399px)"> <source srcset="'.$imagem_full.'" media="(min-width: 1400px)"> <img loading="eager" width="'.$width.'" height="'.$height.'" src="'.$imagem_full.'" title="'.$alt.'" alt="'.$alt.'"> </picture>'.$figcaption.'</figure></div>'; }else{ $replace = '<figure $2> <picture> <source srcset="'.$imagem_mobile.'" media="(max-width: 1023px)"> <source srcset="'.$imagem_desktop.'" media="(min-width: 1024px) and (max-width: 1399px)"> <source srcset="'.$imagem_full.'" media="(min-width: 1400px)"> <img loading="eager" width="'.$width.'" height="'.$height.'" src="'.$imagem_full.'" title="'.$alt.'" alt="'.$alt.'"> </picture>'.$figcaption.'</figure>'; } $new_content = preg_replace($search, $replace, $block_content); return $new_content; }else{ return $block_content; } }else{ return $block_content; } } } // add_filter( 'render_block', 'change_image_block', 10, 2 );
Replying to fnorte:
Thsi closed issue happening with me too, after upgrade from 6.4.3 to 6.5.4, but in all post with the image block on content. like this...
<!-- wp:image {"id":226159,"sizeSlug":"full","linkDestination":"none"} --> <figure class="wp-block-image size-full"><img src="https://noataque.local/wp-content/uploads/2024/06/53782904335_2d2f19b211_c.jpg" alt="Gustavo Scarpa deve atuar novamente pelo lado esquerdo no Atlético" class="wp-image-226159"/><figcaption class="wp-element-caption">Gustavo Scarpa deve atuar novamente pelo lado esquerdo no Atlético</figcaption></figure> <!-- /wp:image -->I made some tests removing the block and work withouth problemas.
I got back to old version (6.4.3) and works withouth problem.
Is a legacy code, and have several issues on them, the most relevant is full of custom post types and taxonomies.
I trying to figured out how to identify what is causing that in my own theme code.
[11-Jun-2024 22:39:52 UTC] PHP Fatal error: Uncaught TypeError: {closure}(): Argument #1 ($content) must be of type string, null given, called in /var/www/noataque/public_html/wp-includes/class-wp-hook.php on line 326 and defined in /var/www/noataque/public_html/wp-includes/interactivity-api/interactivity-api.php:46 Stack trace: #0 /var/www/noataque/public_html/wp-includes/class-wp-hook.php(326): {closure}() #1 /var/www/noataque/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters() #2 /var/www/noataque/public_html/wp-includes/class-wp-block.php(525): apply_filters() #3 /var/www/noataque/public_html/wp-includes/blocks.php(1705): WP_Block->render() #4 /var/www/noataque/public_html/wp-includes/blocks.php(1743): render_block() #5 /var/www/noataque/public_html/wp-includes/class-wp-hook.php(324): do_blocks() #6 /var/www/noataque/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters() #7 /var/www/noataque/public_html/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php(1865): apply_filters() #8 /var/www/noataque/public_html/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php(569): WP_REST_Posts_Controller->prepare_item_for_response() #9 /var/www/noataque/public_html/wp-includes/rest-api/class-wp-rest-server.php(1230): WP_REST_Posts_Controller->get_item() #10 /var/www/noataque/public_html/wp-includes/rest-api/class-wp-rest-server.php(1063): WP_REST_Server->respond_to_request() #11 /var/www/noataque/public_html/wp-includes/rest-api.php(555): WP_REST_Server->dispatch() #12 /var/www/noataque/public_html/wp-includes/rest-api.php(2922): rest_do_request() #13 [internal function]: rest_preload_api_request() #14 /var/www/noataque/public_html/wp-includes/block-editor.php(753): array_reduce() #15 /var/www/noataque/public_html/wp-admin/edit-form-blocks.php(77): block_editor_rest_api_preload() #16 /var/www/noataque/public_html/wp-admin/post.php(187): require('...') #17 {main} thrown in /var/www/noataque/public_html/wp-includes/interactivity-api/interactivity-api.php on line 46
#17
in reply to:
↑ 16
@
8 months ago
Oh sit I can't delete my supid post, goes to hall of shame...
IGNORE THIS PLEASE
I realized the stupid problem in my code (not mine, legacy), the WordPress fixed this issue..
If There is no return to the hook, there is null ...
change the final lines:
return $new_content; }else{ return $block_content; } }else{ return $block_content; } } } add_filter( 'render_block', 'change_image_block', 10, 2 );
FIXING:
return $new_content; } } } return $block_content; } add_filter( 'render_block', 'change_image_block', 10, 2 );
Replying to fnorte:
I Discovery the problem is in this function bellow, commenting the hook and resolve the error, my I'm losting my resource:
What WordPress change to cause this error?
How can I implement this better?
//Adicionado crédito as imagens inseridas no Gutenberg function change_image_block( $block_content, $block ) { if(!is_admin()){ if ($block['blockName'] === 'core/image') { if( str_contains( $block['innerHTML'], 'figure')){ if( str_contains( $block['innerHTML'], 'figcaption')){ $block_caption = true; }else{ $block_caption = false; } $imagem_id = $block['attrs']['id']; $imagem = get_post( $imagem_id ); $imagem_legenda = isset($imagem->post_excerpt) ? $imagem->post_excerpt : null; $imagem_credito = isset($imagem->post_content) ? $imagem->post_content : null; $imagem_full = isset(wp_get_attachment_image_src($imagem_id, 'normal-full')[0]) ? wp_get_attachment_image_src($imagem_id, 'normal-full')[0] : null; $imagem_desktop = isset(wp_get_attachment_image_src($imagem_id, 'normal-desktop')[0]) ? wp_get_attachment_image_src($imagem_id, 'normal-desktop')[0] : null; $imagem_mobile = isset(wp_get_attachment_image_src($imagem_id, 'normal-mobile')[0]) ? wp_get_attachment_image_src($imagem_id, 'normal-mobile')[0] : null; $imagem_alt = get_post_meta($imagem_id, '_wp_attachment_image_alt', true ); if($block_caption){ $search = "/(<figure(.*?)>)(.*?)(<figcaption(.*?)>)(.*?)(<\/figcaption>)(<\/figure>)/"; if($imagem_credito){ $figcaption = '<figcaption $5><small class="image-subtitle">$6</small><small class="image-credit">(foto: '.$imagem_credito.')</small></figcaption>'; $alt = $imagem_alt.' - (foto: '.$imagem_credito.')'; }else{ $figcaption = '<figcaption $5><small class="image-subtitle">$6</small></figcaption>'; $alt = $imagem_alt; } }else{ $search = "/(<figure(.*?)>)(.*?)(<\/figure>)/"; if($imagem_credito){ $figcaption = '<figcaption class="wp-element-caption"><small class="image-credit">(foto: '.$imagem_credito.')</small></figcaption>'; $alt = '(foto: '.$imagem_credito.')'; }else{ $figcaption = ''; $alt = ''; } } if(isset($block['attrs']['width'])){ $width = $block['attrs']['width']; }else{ $width = '100%'; } if(isset($block['attrs']['height'])){ $height = $block['attrs']['height']; }else{ $height = '100%'; } if( str_contains( $block['innerHTML'], 'is-resized')){ $replace = '<div class="wp-block-image"><figure $2> <picture> <source srcset="'.$imagem_mobile.'" media="(max-width: 1023px)"> <source srcset="'.$imagem_desktop.'" media="(min-width: 1024px) and (max-width: 1399px)"> <source srcset="'.$imagem_full.'" media="(min-width: 1400px)"> <img loading="eager" width="'.$width.'" height="'.$height.'" src="'.$imagem_full.'" title="'.$alt.'" alt="'.$alt.'"> </picture>'.$figcaption.'</figure></div>'; }else{ $replace = '<figure $2> <picture> <source srcset="'.$imagem_mobile.'" media="(max-width: 1023px)"> <source srcset="'.$imagem_desktop.'" media="(min-width: 1024px) and (max-width: 1399px)"> <source srcset="'.$imagem_full.'" media="(min-width: 1400px)"> <img loading="eager" width="'.$width.'" height="'.$height.'" src="'.$imagem_full.'" title="'.$alt.'" alt="'.$alt.'"> </picture>'.$figcaption.'</figure>'; } $new_content = preg_replace($search, $replace, $block_content); return $new_content; }else{ return $block_content; } }else{ return $block_content; } } } // add_filter( 'render_block', 'change_image_block', 10, 2 );Replying to fnorte:
Thsi closed issue happening with me too, after upgrade from 6.4.3 to 6.5.4, but in all post with the image block on content. like this...
<!-- wp:image {"id":226159,"sizeSlug":"full","linkDestination":"none"} --> <figure class="wp-block-image size-full"><img src="https://noataque.local/wp-content/uploads/2024/06/53782904335_2d2f19b211_c.jpg" alt="Gustavo Scarpa deve atuar novamente pelo lado esquerdo no Atlético" class="wp-image-226159"/><figcaption class="wp-element-caption">Gustavo Scarpa deve atuar novamente pelo lado esquerdo no Atlético</figcaption></figure> <!-- /wp:image -->I made some tests removing the block and work withouth problemas.
I got back to old version (6.4.3) and works withouth problem.
Is a legacy code, and have several issues on them, the most relevant is full of custom post types and taxonomies.
I trying to figured out how to identify what is causing that in my own theme code.
[11-Jun-2024 22:39:52 UTC] PHP Fatal error: Uncaught TypeError: {closure}(): Argument #1 ($content) must be of type string, null given, called in /var/www/noataque/public_html/wp-includes/class-wp-hook.php on line 326 and defined in /var/www/noataque/public_html/wp-includes/interactivity-api/interactivity-api.php:46 Stack trace: #0 /var/www/noataque/public_html/wp-includes/class-wp-hook.php(326): {closure}() #1 /var/www/noataque/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters() #2 /var/www/noataque/public_html/wp-includes/class-wp-block.php(525): apply_filters() #3 /var/www/noataque/public_html/wp-includes/blocks.php(1705): WP_Block->render() #4 /var/www/noataque/public_html/wp-includes/blocks.php(1743): render_block() #5 /var/www/noataque/public_html/wp-includes/class-wp-hook.php(324): do_blocks() #6 /var/www/noataque/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters() #7 /var/www/noataque/public_html/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php(1865): apply_filters() #8 /var/www/noataque/public_html/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php(569): WP_REST_Posts_Controller->prepare_item_for_response() #9 /var/www/noataque/public_html/wp-includes/rest-api/class-wp-rest-server.php(1230): WP_REST_Posts_Controller->get_item() #10 /var/www/noataque/public_html/wp-includes/rest-api/class-wp-rest-server.php(1063): WP_REST_Server->respond_to_request() #11 /var/www/noataque/public_html/wp-includes/rest-api.php(555): WP_REST_Server->dispatch() #12 /var/www/noataque/public_html/wp-includes/rest-api.php(2922): rest_do_request() #13 [internal function]: rest_preload_api_request() #14 /var/www/noataque/public_html/wp-includes/block-editor.php(753): array_reduce() #15 /var/www/noataque/public_html/wp-admin/edit-form-blocks.php(77): block_editor_rest_api_preload() #16 /var/www/noataque/public_html/wp-admin/post.php(187): require('...') #17 {main} thrown in /var/www/noataque/public_html/wp-includes/interactivity-api/interactivity-api.php on line 46
Screenshot of affected Post