Making WordPress.org

Opened 2 years ago

Closed 21 months ago

Last modified 19 months ago

#6465 closed defect (bug) (fixed)

Add support for `ancestor` block.json property

Reported by: dd32's profile dd32 Owned by: tellyworth's profile tellyworth
Milestone: Priority: high
Component: Plugin Directory Keywords: has-patch
Cc:

Description

As reported in Slack, the block directory validator is rejecting plugins which use the new WordPress 6.0+ ancestor property instead of the more limiting parent property.

This results in plugins that may be eligible for the block directory being rejected as containing multiple blocks.

This also appears to cause the plugins listing to list all of the blocks, rather than just the parent blocks.

Here's an example block.json for a block that was detected as being a non-child block from the Slack thread: https://plugins.trac.wordpress.org/browser/gutena-forms/trunk/build/form-field/block.json?rev=2777775

Attachments (1)

6465.diff (1.4 KB) - added by tellyworth 21 months ago.
Add is_top_level_block function with parent/ancestor logic

Download all attachments as: .zip

Change History (9)

@tellyworth
21 months ago

Add is_top_level_block function with parent/ancestor logic

#1 @tellyworth
21 months ago

  • Owner set to tellyworth
  • Status changed from new to accepted

The patch attachment:6465.diff seems to do the trick. It essentially treats parent and ancestor as the same. It's a bit stricter than the old check though, requiring that the parent/ancestor block exists within the same plugin. That's so that a block with a parent like core/column is correctly treated as top-level for validation purposes.

It works ok for me at a quick test; do I have the logic right?

#2 @dd32
21 months ago

It works ok for me at a quick test; do I have the logic right?

I think the logic is right. For the list below, parent means ancestor or parent.

  • If the block has no parent it's top-level
  • If the block has a parent that's not provided by the plugin, it's top-level.
  • If the block has a parent that's provided by the plugin, it's child.

A plugin with a block that requires a parent element that's provided by another plugin will be treated as a top-level block here (ie. A plugin provides "File Upload Block" for "Form Builder Plugin") that'll be treated as top-level here, which seems somewhat appropriate.

#3 @randhirexpresstech
21 months ago

Thanks! @dd32 and @tellyworth for fixing this issue. May I test this fix on live block-plugin-validator https://wordpress.org/plugins/developers/block-plugin-validator/.

#4 @dd32
21 months ago

@randhirexpresstech This patch still needs to be deployed to production, you'll see a followup here when that happens and you can then test it in the Block validator.

#5 @dd32
21 months ago

  • Keywords has-patch added; needs-patch removed

#6 @tellyworth
21 months ago

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

In 12356:

Plugin Directory: better child block handling in validator.

Fixes #6465.

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


20 months ago

#8 @randhirexpresstech
19 months ago

  • Priority changed from normal to high

Hi! @dd32 and @tellyworth . There are some issue with on-page block plugin search, and insertion. Will you please look into this ticket: https://meta.trac.wordpress.org/ticket/6735.
Thanks

Note: See TracTickets for help on using tickets.