WordPress.org

Make WordPress Core

Opened 2 months ago

Closed 2 months ago

Last modified 7 weeks ago

#51018 closed defect (bug) (fixed)

PHP Notice thrown when searching for certain terms via the Gutenberg block directory

Reported by: TwentyZeroTwo Owned by: SergeyBiryukov
Milestone: 5.5.1 Priority: normal
Severity: normal Version: 5.5
Component: Editor Keywords: has-patch commit fixed-major
Focuses: Cc:

Description

PHP Version: 7.4.3

Steps to reproduce:
Open up the editor with Gutenberg enabled, search for the block "free".

Error thrown:

[15-Aug-2020 12:32:44 UTC] PHP Notice:  Trying to access array offset on value of type bool in C:\wamp64\www\snap\wp-includes\rest-api\endpoints\class-wp-rest-block-directory-controller.php on line 122
[15-Aug-2020 12:32:44 UTC] PHP Stack trace:
[15-Aug-2020 12:32:44 UTC] PHP   1. {main}() C:\wamp64\www\snap\index.php:0
[15-Aug-2020 12:32:44 UTC] PHP   2. require() C:\wamp64\www\snap\index.php:17
[15-Aug-2020 12:32:44 UTC] PHP   3. wp() C:\wamp64\www\snap\wp-blog-header.php:16
[15-Aug-2020 12:32:44 UTC] PHP   4. WP->main() C:\wamp64\www\snap\wp-includes\functions.php:1285
[15-Aug-2020 12:32:44 UTC] PHP   5. WP->parse_request() C:\wamp64\www\snap\wp-includes\class-wp.php:745
[15-Aug-2020 12:32:44 UTC] PHP   6. do_action_ref_array() C:\wamp64\www\snap\wp-includes\class-wp.php:388
[15-Aug-2020 12:32:44 UTC] PHP   7. WP_Hook->do_action() C:\wamp64\www\snap\wp-includes\plugin.php:544
[15-Aug-2020 12:32:44 UTC] PHP   8. WP_Hook->apply_filters() C:\wamp64\www\snap\wp-includes\class-wp-hook.php:311
[15-Aug-2020 12:32:44 UTC] PHP   9. rest_api_loaded() C:\wamp64\www\snap\wp-includes\class-wp-hook.php:287
[15-Aug-2020 12:32:44 UTC] PHP  10. WP_REST_Server->serve_request() C:\wamp64\www\snap\wp-includes\rest-api.php:338
[15-Aug-2020 12:32:44 UTC] PHP  11. WP_REST_Server->dispatch() C:\wamp64\www\snap\wp-includes\rest-api\class-wp-rest-server.php:376
[15-Aug-2020 12:32:44 UTC] PHP  12. WP_REST_Block_Directory_Controller->get_items() C:\wamp64\www\snap\wp-includes\rest-api\class-wp-rest-server.php:1050
[15-Aug-2020 12:32:44 UTC] PHP  13. WP_REST_Block_Directory_Controller->prepare_item_for_response() C:\wamp64\www\snap\wp-includes\rest-api\endpoints\class-wp-rest-block-directory-controller.php:98

Change History (19)

#1 @TwentyZeroTwo
2 months ago

After a little investigation, the offending block in the above instance is https://wordpress.org/plugins/map-block-gutenberg/.

It does not populate the $plugin['blocks'] array so it is empty, causing $block_data = reset( $plugin['blocks'] ); to return false.

While the plugin author should obviously fix this, WordPress core should handle such situations.

#2 @SergeyBiryukov
2 months ago

  • Component changed from General to Editor
  • Milestone changed from Awaiting Review to 5.5.1

#3 @justinahinon
2 months ago

  • Keywords reporter-feedback added

Hey @TwentyZeroTwo. Welcome to Trac, and thanks for opening this.

I've tried to reproduce the issue on a fresh WordPress 5.5 installation with Twenty Twenty default theme. I've also trie with the "Gutenberg Map Block for Google Maps" plugin activated.

In both cases I was not able to reproduce.

Are you noticing the issue with a particular setup/theme/plugins installed? Can you try on a fresh version and let us know what you get?

#4 follow-up: @TwentyZeroTwo
2 months ago

@justinahinon Yup completely fresh with Twenty Twenty default theme and no plugins enabled.

Bear in mind that as it is a notice, the only place you will see it is in your PHP error log.

#5 in reply to: ↑ 4 @justinahinon
2 months ago

Replying to TwentyZeroTwo:

@justinahinon Yup completely fresh with Twenty Twenty default theme and no plugins enabled.

Bear in mind that as it is a notice, the only place you will see it is in your PHP error log.

Sure, I've looked at PHP errors logs, but not seeing anything related to blocks notices.

I'll raise the ticket during a Core triage or a devchat open floor. Then see if others can reproduce this.

#6 @khag7
2 months ago

I have no problem reproducing this. New install, default theme, no plugin install. Make sure PHP is set up to log notices. Start a new post, click the + button for a new block, search for "free". PHP error log shows same error mentioned in the issue description.

#7 @khag7
2 months ago

https://i.imgur.com/WkIEeDZ.png

Because the response from the WordPress API is missing block information for this plugin, you also can't add the block.

#8 @khag7
2 months ago

When a call is made to the WordPress.org Plugins API, the response is a list of plugins. Each plugin in that array has a property "blocks" which includes a 'name' and a 'title' for any blocks. In the offending plugin mentioned in this issue, no name and no title are returned. WordPress (the software here, not the API) can handle a missing title. But a missing name causes errors. In my opinion this is an issue with the response returned from the WordPress.org Plugins API and should be fixed there. If the API can't find any registered block names then should it really be returning the plugin in the response list?

To handle the case where the API returns a block without a name we need to handle a poor response:

// First, if blocks doesn't exist or is empty, let's skip it.
if( ! isset( $plugin['blocks'] ) || empty( $plugin['blocks'] ) ) continue;

// Second, we can do our reset here to get the first block only.
$plugin['block'] = reset( $plugin['blocks'] );

// Last, if the block doesn't have a name or name is empty, we can't show this plugin.
if( ! isset( $plugin['block']['name'] ) || empty( $plugin['block']['name'] ) ) continue;

This ticket was mentioned in PR #488 on WordPress/wordpress-develop by khag7.


2 months ago

  • Keywords has-patch added

#10 @TimothyBlynJacobs
2 months ago

Thanks for picking this up and working on a patch @khag7! Ideally it seems like this would be solved upstream by WordPress.org. Cc @dd32

#11 @dd32
2 months ago

Also mentioned over here: https://meta.trac.wordpress.org/ticket/5207#comment:16

If the array is empty, it's because WordPress.org can't detect any blocks in the block, there's some things we're working on that will hopefully fix this for the blocks though.

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


2 months ago

#13 @SergeyBiryukov
2 months ago

  • Keywords reporter-feedback removed
  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#14 follow-up: @SergeyBiryukov
2 months ago

It looks like the API issue has been resolved since the report, presumably in [meta10188].

Still, adding a check to ensure that $plugin['blocks'] is not empty probably wouldn't hurt.

#15 @SergeyBiryukov
2 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 48842:

REST API: In WP_REST_Block_Directory_Controller::get_items(), make sure the blocks data for a plugin is not empty before proceeding.

This avoids a PHP notice if the API returns a plugin with empty data for blocks key.

Props khag7, TwentyZeroTwo, justinahinon, TimothyBlynJacobs, dd32, SergeyBiryukov.
Fixes #51018.

#16 @SergeyBiryukov
2 months ago

  • Keywords commit fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for the 5.5 branch.

#17 in reply to: ↑ 14 @khag7
2 months ago

Replying to SergeyBiryukov:

It looks like the API issue has been resolved since the report, presumably in [meta10188].

Excellent! That was always the ideal solution.

#18 @SergeyBiryukov
2 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 48849:

REST API: In WP_REST_Block_Directory_Controller::get_items(), make sure the blocks data for a plugin is not empty before proceeding.

This avoids a PHP notice if the API returns a plugin with empty data for blocks key.

Props khag7, TwentyZeroTwo, justinahinon, TimothyBlynJacobs, dd32, SergeyBiryukov.
Merges [48842] to the 5.5 branch.
Fixes #51018.

#19 @prbot
7 weeks ago

TimothyBJacobs commented on PR #488:

Closing this PR out as the ticket has been committed.

Note: See TracTickets for help on using tickets.