WordPress.org

Making WordPress.org

Opened 4 weeks ago

Last modified 4 weeks ago

#5910 new defect

Block Directory: Plugins are suggested for missing core blocks

Reported by: ryelle Owned by:
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 (4)

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


4 weeks ago

#2 @tellyworth
4 weeks 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 weeks 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 weeks ago by dd32 (previous) (diff)

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


4 weeks ago

Note: See TracTickets for help on using tickets.