WordPress.org

Make WordPress Core

Opened 9 months ago

Last modified 3 weeks ago

#49330 new enhancement

REST API: introduce block-editor context

Reported by: kadamwhite Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 5.4
Component: REST API Keywords: needs-patch
Focuses: rest-api Cc:

Description

The block editor does not make use of rendered content, and rendering content for complex posts with a large quantity of dynamic blocks can take a non-trivial amount of time. The REST API maintainers and Gutenberg developers have previously discussed the need to be able to "skip" rendering of the content if it is not required.

In [46184] we introduced the ability to provide an explicit list of nested fields to include. Specifying _fields=content.raw without mentioning rendered now causes the posts controller to skip computation of the rendered field, as it has not been requested. Unfortunately, this approach requires a developer to provide a comprehensive list of all fields they _do_ wish to include in the response, and cannot easily be used to specifically exclude one field. Because block editor developers may depend on registered rest fields or other additional properties, it is infeasible to have the block editor request "all but the rendered content" using this interface.

A slack conversation (https://wordpress.slack.com/archives/C02RQC26G/p1574361923322500) with @aduth and @timothyblynjacobs addressed this problem and discussed two separate options, either providing an _omit_fields parameter to complement _fields and permit specific exclusions, or alternatively to introduce a new block-editor context that does everything that edit does except render content.

This trac ticket is intended to move that discussion forward and aim towards introducing a solution that can be used to speed up response times within the block editor.

Change History (9)

#1 @kadamwhite
9 months ago

@TimothyBlynJacobs asked during an in-person working session whether this new context would also be an opportunity to introduce a different permissions model that has been previously requested by the Gutenberg leads, where the REST API would return as many properties of a response as it could given the current permissions, rather than failing an entire response because one field is inaccessible. At the moment @kadamwhite thinks it's best to treat that as a separate discussion.

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


9 months ago

#3 @davidbaumwald
9 months ago

@kadamwhite Is this still doable for 5.4 with Beta 1 approaching in a couple of days?

#4 @kadamwhite
8 months ago

  • Milestone changed from 5.4 to 5.5

@davidbaumwald I'm disappointed in myself that I haven't had time to go for this, but no, the deadline's too close to do this correctly. Punting to 5.5.

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


5 months ago

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


4 months ago

#7 @TimothyBlynJacobs
4 months ago

  • Milestone changed from 5.5 to 5.6

Punting to 5.6 This still needs coordination with the Gutenberg team to determine what fields are appropriate.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


4 weeks ago

#9 @TimothyBlynJacobs
3 weeks ago

  • Milestone changed from 5.6 to Future Release

Punting to future release. This hasn't garnered much interest from the Gutenberg team recently.

Note: See TracTickets for help on using tickets.