Move default template types and template part areas to REST API

[gigitux]

The default template types and template part areas are currently preloaded via the settings object when the site editor is loaded (see ​https://github.com/WordPress/wordpress-develop/blob/1aa41dea3345c57cffce9059bbad728c86d1471a/src/wp-admin/site-editor.php#L64-L65). To make these variables accessible to other components, even when the site editor isn’t loaded, they should be moved to the REST API.

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

[gigitux]

This work has already been merged in Gutenberg: ​https://github.com/WordPress/gutenberg/pull/66459

[gigitux]

This PR (​https://github.com/WordPress/wordpress-develop/pull/7895) introduces the following changes:

• Adds default template types and template part areas to the index REST endpoint (​https://github.com/WordPress/wordpress-develop/pull/7895/commits/b175fb545586a97ae9eb4145f85e3bd9af85e54f)
• Removes default template types and template part areas from the settings object (​https://github.com/WordPress/wordpress-develop/pull/7895/commits/d38449f624bd1efa08bf12220ceda6f5883f123c)

Note:
The second change might be a breaking change. Should we reconsider its inclusion?

How do you feel about adding some assertions to tests/phpunit/tests/rest-api/rest-server.php test_get_index test?

Sounds great! Thanks for the review, @youknowriad 🙇

This PR syncs changes from: ​https://github.com/WordPress/gutenberg/pull/66459

[peterwilsoncc]

The associated PR doesn't make the fields available to the endpoint by default which is a little counter intuitive. In order to access them, a developer must include the usually optional ?_fields parameter. /wp-json/?_fields=default_template_part_areas,default_template_types

By requiring the additional parameters, it seems like it's adding a new endpoint by other means.

I'm also not convinced the site index is the best place for these, even if loaded by default, template parts and areas are very theme orientated so the themes controller seems a better place for them.

[gigitux]

We discuss this topic on the Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/66459#issuecomment-2457097527

cc @Mamaduka

[peterwilsoncc]

I don't really think the discussion on the Gutenberg PR was resolved beyond let's move on to avoid blocking the ticket. As the Gutenberg plugin is bleeding edge WP, that's fine for the plugin as it doesn't have the same backward compatibility promises that come with code released in WordPress stable.

A concern I have with including this data on a public endpoint is that WP can't assume that the data is intended to be public, themes and plugins can use various filters to define custom templates for data that is intended to be private.

I'm also concerned about creating a faux endpoint, as explained above, as a shortcut to creating a new endpoint, using a more appropriate endpoint.

[Mamaduka]

The REST API index is the only option for read-only settings until #48885 is resolved.

The associated PR doesn't make the fields available to the endpoint by default which is a little counter intuitive. In order to access them, a developer must include the usually optional ?_fields parameter.

IIRC, if you request without fields, all fields are returned, including new fields proposed in this PR.

[peterwilsoncc]

Replying to Mamaduka:

The REST API index is the only option for read-only settings until #48885 is resolved.

I think it best to resolve this prior to moving these to the REST API, or to make the data available on the templates endpoint, theme endpoint or similar.

The associated PR doesn't make the fields available to the endpoint by default which is a little counter intuitive. In order to access them, a developer must include the usually optional ?_fields parameter.

IIRC, if you request without fields, all fields are returned, including new fields proposed in this PR.

I've double checked using the ​WP Playground for the attached PR and if you search for the relevant strings for the default rest endpoint, you'll see that they are missing.

[gigitux]

I think it best to resolve this prior to moving these to the REST API, or to make the data available on the templates endpoint, theme endpoint or similar.

Unfortunately, I don’t have the bandwidth to work on this refactor right now.

[joemcgill]

To help move this forward, I think tying this to the ongoing discussion in #48885 conflates two unrelated issues.

That ticket is specifically about how to expose read only access to registered settings (i.e. options). Given that the default template types and allowed template part areas are not stored as options, but are instead ​defined in code, the same concerns don't apply here, as these are not "settings" in the way the wp/v2/settings endpoint defines them.

That said, I think question that does still need to be answered is where is the appropriate place to expose this data since wp/v2/settings is inappropriate and wp/v2/templates and wp/v2/template-parts are meant to return a representation of a WP_Block_Template object.

I'd be more comfortable adding this to the index if were only exposed to logged in users given that these values can be modified by themes and plugins to include data that may not be meant to be public. If doing so, I would add this as a filter on the rest_index callback, similar to how the application passwords data is added via rest_add_application_passwords_to_index().

[Mamaduka]

Since the beta one date approaches fast, it would be nice to have final confirmation on this.

I'd be more comfortable adding this to the index if were only exposed to logged in users given that these values can be modified by themes and plugins to include data that may not be meant to be public. If doing so, I would add this as a filter on the rest_index callback, similar to how the application passwords data is added via rest_add_application_passwords_to_index().

@TimothyBlynJacobs, @spacedmonkey, what do you think going with this solution?

Alternative to #7895.

Limits access to the default_template_part_areas and default_template_types values. They are now only available to logged-in users viathe REST index.

Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/69346
Trac ticket: https://core.trac.wordpress.org/ticket/62574

[Mamaduka]

Created an alternative PR based on the latest discussions.

[Benjamin_Zekavica]

@Mamaduka I agree with Joe and support this suggestion: It's better to expose this data only to logged-in users since themes and plugins can modify these values, and they may not be meant to be public. If so, I would add it as a filter in the rest_index callback, like how application passwords are handled.

[Mamaduka]

@Benjamin_Zekavica, the new PR does exactly the same. See: ​https://github.com/WordPress/wordpress-develop/pull/8422

[Benjamin_Zekavica]

@Mamaduka Thank you :) For me it looks good.

[TimothyBlynJacobs]

I still really do not think this is the right place for the data for the reasons previously stated. So I guess my question is what is the pressure for moving this bit of data to the REST API for 6.8? It looks like there are a number of things that are still in the ​custom settings array, so it's not like we are getting away from it entirely.

[audrasjb]

As per today's bug scrub: just wanted to inform committers that we're still keeping this ticket open in the milestone until beta 1 tomorrow, then it will be moved to milestone 6.9 if needed.

[joemcgill]

@TimothyBlynJacobs my understanding is that the motivation for moving this data to the REST API was explained in ​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: ​#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.

[peterwilsoncc]

I'm happier with the approach of limiting the data to logged in users (I've made a caps suggestion on the PR but that is it).

I'm still unhappy about placing the data in the wp-json/ endpoint as a default because a better place can't be found. The data is strongly theme related and there aren't any significant ill-effects by waiting until an improved location can be found.

Behind a login is an improvement because there may be sensitive data in the output, depending on how a third party developer is using them. It's low but not no risk.

My big concern is that we can't use the REST index as a too hard basket when data doesn't quite belong anywhere else.

Update rest_add_templates_default_data_to_index to use edit_posts capability. The tests are now using the data provider with various roles.

[Mamaduka]

I've updated the PR based on the latest feedback. It should be ready for final review.

I understand that the REST index might not be the best place, but it's the best one we've got for now.

Historically, editor settings were used for the same reason, but they require coupling with those packages. Low-level packages like fields should not depend on high-level packages like editor or block-editor. This is one reason JS packages are trying to move away from editor settings bootstrapped from the server.

[TimothyBlynJacobs]

Thanks @joemcgill!

my understanding is that the motivation for moving this data to the REST API was explained in the related Gutenberg PR

This is helpful, and I get why we want to move things to the REST API long term, and I very much agree with that. I'm just not totally understanding the pressure for getting this to land in 6.8. Why can't the existing method of adding it to editor settings continue to work for this release?

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?

No worries at all. I have similar thoughts to Peter.

It seems like it would be fairly straightforward to drop this in to the Themes controller? We'd add it only to the active theme, similar to how we do Theme Supports for instance.

[joemcgill]

Thanks all. After discussing with @Mamaduka ​in Slack, we are not going to move forward with the current PR for 6.8 Beta 1.

My understanding is that this currently results in the current @wordpress/fields package synced to trunk being broken when used outside an editor where this data is being bootstrapped by editor settings, so some follow-up will be needed during this release regardless. I'm going to convert this to a task ticket in the meantime, so this stays visible.

@peterwilsoncc opened ​this related issue where we can follow-up on how to handle the package updates. If we are able to resolve the situation by including this data in the REST API, I think that would be preferable, so this could be resolved in this release.

[Mamaduka]

Thanks for the summary, @joemcgill!

I'm going to prepare PRs for the following solutions:

1. Expose/consume this data via themes endpoint for the current active theme, as suggested by @TimothyBlynJacobs.
2. Revert data consumption to editor settings by reverting all client-side changes from ​https://github.com/WordPress/gutenberg/pull/68781. The plugin will experiment with different solutions for consuming data via REST API (for future WP releases). This is just in case plan A is rejected, and we need something 100% functional for WP 6.8.

[Mamaduka]

Here's the Gutenberg PR for exposing this data via themes endpoint - ​https://github.com/WordPress/gutenberg/pull/69417.

[peterwilsoncc]

I've approved the PR on the GB repo, thanks folks for working through the decision of where the data was best placed.

Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/69417
Trac ticket: https://core.trac.wordpress.org/ticket/62574

Closing in favor of #8480.

Closing in favor of #8480.

Refreshed this PR to include the package updates synced to trunk for better testing.

[Mamaduka]

In 59965:

REST API: Add additional default template data fields for the active theme.

The active theme(s) now return two additional properties, default_template_types and default_template_part_areas, in the REST response.

Props mamaduka, joemcgill, timothyblynjacobs, audrasjb, gigitux, peterwilsoncc, youknowriad, jorbin.
Fixes #62574.