Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#54386 closed defect (bug) (reported-upstream)

SSR blocks with enum attribute thows notice

Reported by: walbo's profile walbo Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: REST API Keywords: has-unit-tests
Focuses: Cc:


Server side rendering a block that has a enum attribute without a type throws an notice that says type in undefined in the rest api.

The rest api should require either a type or an enum.

Ex on block that will fail:

        'attributes'      => array(
            'value'    => array(
                'enum' => [ 'ok', false ],
        'render_callback' => function( $block_attributes ) {
            return $block_attributes['value'];

Change History (6)

This ticket was mentioned in PR #1820 on WordPress/wordpress-develop by walbo.

2 years ago

  • Keywords has-patch has-unit-tests added

#2 @walbo
2 years ago

  • Keywords has-patch removed

Added a quick unit test to show the failure.

#3 @TimothyBlynJacobs
2 years ago

  • Keywords reporter-feedback added

Can you clarify what you would like to see changed here? The REST API requires a type argument. If you want to use an enum that crosses types, you should specify each of the types as a list.

#4 @walbo
2 years ago

Yes, that will solve it.

The block attributes documentation clearly states either a type or an enum is required:

The attribute definition will contain, at a minimum, either a type or an enum. There may be additional fields.

So the question is: Should the REST API support having enum without a required type?

If not I quess this ticket can be closed and I'll create an issue in the Gutenberg repo to update the docs and examples.

#5 @walbo
2 years ago

  • Keywords reporter-feedback removed

#6 @TimothyBlynJacobs
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to reported-upstream
  • Status changed from new to closed

Yeah, this should be reported upstream as a docs issue. The WordPress REST API supports loose typing which mostly necessitates us to have types defined even where the core JSON Schema spec wouldn't require them.

Note: See TracTickets for help on using tickets.