Making WordPress.org

Opened 4 months ago

Closed 3 months ago

#5910 closed defect (fixed)

Block Directory: Plugins are suggested for missing core blocks

Reported by: ryelle Owned by: ryelle
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

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?

Change History (11)

This ticket was mentioned in Slack in #core-editor by ryelle. View the logs.


4 months ago

#2 @tellyworth
4 months ago

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.

#3 @dd32
4 months ago

  • 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.

Last edited 4 months ago by dd32 (previous) (diff)

This ticket was mentioned in Slack in #core-test by boniu91. View the logs.


4 months ago

#5 @ryelle
3 months ago

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.

#6 @ryelle
3 months ago

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.

#7 @ryelle
3 months ago

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

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).

#8 @Otto42
3 months ago

@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/

This ticket was mentioned in Slack in #forums by otto42. View the logs.


3 months ago

#10 @Otto42
3 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Yeah, this is definitely breaking something.

#11 @ryelle
3 months ago

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

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.

Note: See TracTickets for help on using tickets.