Block Directory: Plugins are suggested for missing core blocks

[ryelle]

See ​https://core.trac.wordpress.org/ticket/54113. When a core block is unregistered, but still used in the content, the missing block search can turn up unexpected results.

In the core ticket, the core/gallery block is unregistered. On a post with an existing gallery block, the missing block suggests they install ​THRON. This is because the THRON plugin re-registers a few core/* blocks, and these are picked up as "blocks provided by THRON". This plugin doesn't actually provide the gallery block, though, it's just a method of overriding the render function.

Usually, when a block is missing, the editor searches the block directory for suggestions. In this case, the editor searches for any block-plugins or plugins that provide the core/gallery block… and returns THRON. Installing this plugin won't fix the block error, though.

I think we have a few possibilities here, and can do any number of them:

• In the editor (gutenberg), don't run the block suggestion code if the block is core/*
• In the wporg API, always return an empty result for core/* blocks
• When processing block-directory blocks, skip core/*, so they aren't added as block_name meta values (and thus won't be returned in the API)

We already have a validation rule that prevents block-plugins from using the core namespace, but the API falls back to any plugin with blocks. Maybe it shouldn't do that?

[tellyworth]

When processing block-directory blocks, skip core/*, so they aren't added as block_name meta values (and thus won't be returned in the API)

This makes a lot of sense to me. It seems like a bad idea to allow plugins to claim those blocks in the plugin directory. There are only 5 plugins that do it currently, including THRON. I think that's in part because the block validator rejects any that use non-unique namespaces including core.

The first suggestion of special handling for core blocks might make sense also but I'd see that as a defensive thing in addition to the directory meta fix above. From the user's POV it might be nice to tell them "this core block was disabled by plugin xyz", though that's probably tricky to determine in code.

[dd32]

• In the wporg API, always return an empty result for core/* blocks
• When processing block-directory blocks, skip core/*, so they aren't added as block_name meta values (and thus won't be returned in the API)

I think we should do both of these in some form, for completeness and safety.

It might still make sense to record the blocks that it re-registers (and mark it as, "extends" these blocks?) in some way.. which could even be to add an additional namespace on our end like hello-dolly:core/gallery so that it's still stored/recorded but makes it clear it does not provide core/gallery.

[ryelle]

In 11291:

Plugin Directory: Skip core/* blocks when detecting the blocks a plugin provides.

This prevents block directory plugins from indicating that they offer core blocks, which can incorrectly be returned by the block directory API when trying to find "missing blocks".

See #5910.

[ryelle]

In 11292:

Plugin Directory: Bypass the block plugin search when searching for core blocks.

If a core block (core/*) is disabled or missing from the editor, the missing block handler will try to look for it on WordPress.org, but no plugin should provide core blocks. This will short-circuit out of the block search and return zero results, to avoid issues if a plugin claims to provide the core block.

See #5910.

[ryelle]

With [11291] and [11292] I've made it so block-plugins can't identify that they support core/* blocks, and API requests for core/* blocks will short-circuit and return no results. I didn't add anything to flag blocks that re-register core/* blocks, because I don't think that's the recommended way to extend core blocks (plugins should be using filters instead).

[Otto42]

@ryelle getting some reports that plugin search doesn't work anymore. Any chance of a connection here?

​https://wordpress.org/support/topic/plugin-search-doesnt-work-3/

[Otto42]

Yeah, this is definitely breaking something.

[ryelle]

In 11295:

Plugin Directory: Only unset the search query when bypassing the general search.

In [11292], the search term was always unset, causing general plugin search to break. Instead, the search term should only be unset when alternate queries are set up (slug matches or block search).

Fixes #5910.