Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#48079 closed enhancement (fixed)

REST API: optimize how the schema API is generated for block-renderer endpoints

Reported by: gziolo's profile gziolo Owned by: timothyblynjacobs's profile TimothyBlynJacobs
Milestone: 5.5 Priority: normal
Severity: normal Version:
Component: REST API Keywords: has-dev-note
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Related discussion on WordPress Slack:

It looks like we might rethink how block-renderer is handled on the server. When we start registering all core blocks on the server this will grow further, but with the recent changes introduced for the Social Link blocks, we can observer growing overhead causes by the schema API. See: [46190]

Attachments (2)

Screen Shot 2019-09-19 at 15.40.48.png (1.3 MB) - added by gziolo 5 years ago.
REST API schema generated for registered blocks
Screen Shot 2019-09-19 at 15.46.30.png (392.6 KB) - added by gziolo 5 years ago.
Registered core blocks exposed from the server

Download all attachments as: .zip

Change History (17)

This ticket was mentioned in Slack in #core-restapi by gziolo. View the logs.

5 years ago

#2 @SergeyBiryukov
5 years ago

  • Description modified (diff)

#3 @gziolo
5 years ago

There is also ongoing discussion about whether to mark this collection of blocks as experimental:

It means that they would stay exposed in Gutenberg plugin but they would be removed from WordPress 5.3 release.

5 years ago

REST API schema generated for registered blocks

5 years ago

Registered core blocks exposed from the server

#4 @gziolo
5 years ago

This is a more broad issue as presented on screenshots shared. It's not only about the overhead that REST API schema creates. It's also about the size of HTML output we produce to be served when the edit post page loads. There are two factors involved:

  • all REST API endpoints created for every block registered on the server
  • block definitions exposed for every block registered on the server

I personally could argue whether Social Link block should have 37 instances registered on the server. However, I'm aware that in WordPress 5.4 we all hope to see all core blocks to be registered on the server. Moreover, in the future, we want to have a proper REST API endpoint which returns all definitions for blocks registered on the server as described in #47620.

Last edited 5 years ago by gziolo (previous) (diff)

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

5 years ago

#6 @TimothyBlynJacobs
4 years ago

  • Milestone changed from Awaiting Review to 5.5

This ticket was mentioned in Slack in #core-restapi by timothybjacobs. View the logs.

4 years ago

This ticket was mentioned in PR #239 on WordPress/wordpress-develop by TimothyBJacobs.

4 years ago

This switches to rendering one block renderer route, and then validating the attributes dynamically with a validate_callback.

Trac ticket:

#9 @TimothyBlynJacobs
4 years ago

@gziolo this is ready for review. Could you see if this would pose any issues for Gutenberg? The only issue I think could happen would be if Gutenberg was looking specifically for the "rest_no_route" code directly instead of a 404.

#10 @gziolo
4 years ago

I can't find any reference for rest_no_route in Gutenberg. I'm not familiar with the specifics of REST API (yet) but overall the proposed patch looks exactly how I imagined it. Great work, thank you!

#11 @TimothyBlynJacobs
4 years ago

Thanks @gziolo! I'll give this a commit later today.

This ticket was mentioned in Slack in #core-restapi by timothybjacobs. View the logs.

4 years ago

#13 @TimothyBlynJacobs
4 years ago

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

In 48069:

REST API: Only register one block renderer route.

Every block has a different set of attributes. These attributes are specified as a JSON Schema object. Previously, every block registered its own block renderer route using its attributes for the schema. This allowed for the attributes to be validated using the built in endpoint validation rules. It had the unfortunate side effect, however, of creating a large number of nearly identical REST API routes, one for each dynamic block. Each registered route has a performance impact. As the number of server side blocks goes up, this becomes more and more of an issue.

Now, we register a single block renderer route and dynamically validate the attributes based on the selected block.

Fixes #48079.
Props gziolo, TimothyBlynJacobs.

#14 @TimothyBlynJacobs
4 years ago

In 48437:

REST API: Sanitize block renderer attributes.

In [48069] the Block Renderer was changed to register a single route for all dynamic blocks. Validation was dynamically applied based on the requested block, but sanitization was not. This commit adds the same sanitization back to the block attributes.

Props manooweb.
Fixes #50620. See #48079.

Note: See TracTickets for help on using tickets.