#48079 closed enhancement (fixed)
REST API: optimize how the schema API is generated for block-renderer endpoints
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | REST API | Keywords: | has-dev-note |
Focuses: | Cc: |
Description (last modified by )
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)
Change History (17)
This ticket was mentioned in Slack in #core-restapi by gziolo. View the logs.
5 years ago
#4
@
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.
This ticket was mentioned in Slack in #core-editor by kadamwhite. View the logs.
5 years ago
This ticket was mentioned in Slack in #core-restapi by timothybjacobs. View the logs.
5 years ago
This ticket was mentioned in PR #239 on WordPress/wordpress-develop by TimothyBJacobs.
5 years ago
#8
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
#9
@
5 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
@
5 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!
This ticket was mentioned in Slack in #core-restapi by timothybjacobs. View the logs.
5 years ago
#13
@
5 years ago
- Owner set to TimothyBlynJacobs
- Resolution set to fixed
- Status changed from new to closed
In 48069:
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.