WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 11 days ago

#49330 new enhancement

REST API: introduce block-editor context

Reported by: kadamwhite Owned by:
Milestone: 5.5 Priority: normal
Severity: normal Version: trunk
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 (4)

#1 @kadamwhite
3 weeks 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.


3 weeks ago

#3 @davidbaumwald
12 days ago

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

#4 @kadamwhite
11 days 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.

Note: See TracTickets for help on using tickets.