[wp-trac] [WordPress Trac] #62574: Move default template types and template part areas to REST API

[WordPress Trac]

#62574: Move default template types and template part areas to REST API
-------------------------------------------------+-------------------------
 Reporter:  gigitux                              |       Owner:  Mamaduka
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.8
Component:  Editor                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch gutenberg-merge has-unit-  |     Focuses:
  tests 2nd-opinion                              |
-------------------------------------------------+-------------------------
Changes (by joemcgill):

 * keywords:  has-patch gutenberg-merge has-unit-tests => has-patch
     gutenberg-merge has-unit-tests 2nd-opinion
 * owner:  gigitux => Mamaduka


Comment:

 @TimothyBlynJacobs my understanding is that the motivation for moving this
 data to the REST API was explained in
 [https://github.com/WordPress/gutenberg/pull/66459 the related Gutenberg
 PR]

 > This PR is necessary to remove the core/editor dependency across the
 application. In the specific, this refactor is needed to allow the package
 fields to have access to the `defaultTemplateTypes`,
 `defaultTemplatePartAreas` without that editor settings are initialized.
 More details here:
 [https://github.com/WordPress/gutenberg/pull/65390#discussion_r1814724405
 #65390 (comment)]

 The idea being that the fields package should not be dependent on whether
 a block editor currently rendered in order to access this data.

 @Mamaduka do you have any insight into whether continuing to rely on the
 settings array would break the expected behavior of any features shipping
 in 6.8?

 @TimothyBlynJacobs apologies for asking you to repeat yourself, but could
 you reiterate why you don't think the index is the right place for this
 data? It was clear why this data didn't belong on the `/settings`
 endpoint, but not why exposing it on the index should be avoided. As I
 read the code, this data is part of the default configuration of the
 WordPress application that is common to all block themes and not specific
 to any particular theme, so finding an appropriate place to expose this
 data is proving challenging.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62574#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform