WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 4 weeks ago

#48079 new enhancement

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

Reported by: gziolo Owned by:
Milestone: 5.5 Priority: normal
Severity: normal Version:
Component: REST API Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Related discussion on WordPress Slack:

https://wordpress.slack.com/archives/C02RQC26G/p1568902628031000

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 8 months ago.
REST API schema generated for registered blocks
Screen Shot 2019-09-19 at 15.46.30.png (392.6 KB) - added by gziolo 8 months ago.
Registered core blocks exposed from the server

Download all attachments as: .zip

Change History (10)

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


8 months ago

#2 @SergeyBiryukov
8 months ago

  • Description modified (diff)

#3 @gziolo
8 months ago

There is also ongoing discussion about whether to mark this collection of blocks as experimental:
https://github.com/WordPress/gutenberg/issues/17524

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

@gziolo
8 months ago

REST API schema generated for registered blocks

@gziolo
8 months ago

Registered core blocks exposed from the server

#4 @gziolo
8 months 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 8 months ago by gziolo (previous) (diff)

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


8 months ago

#6 @TimothyBlynJacobs
3 months ago

  • Milestone changed from Awaiting Review to 5.5

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


3 months ago

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


4 weeks ago

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

Trac ticket: https://core.trac.wordpress.org/ticket/48079

Note: See TracTickets for help on using tickets.