Templates API: return post modified datetime in response

[ramonjd]

What?

All these file changes are so that we can add modified to the template and template part objects in the rest response for WP_REST_Templates_Controller 😄

For theme templates, it will add the modified value when we have a post id (which is once the template is first save after user change)

The modified property will be returned when a template is created, updated and fetched.

Why?

So that we can display the modified date in the UI. See: #49597

How?

Grabbing the value of post_modified from the post object and adding it to the response object

Testing Instructions

npm run test:unit:php -- --filter Gutenberg_REST_Templates_Controller_Test

In the site editor, open a theme template and check the API response. There should be no modified field (because the template post record hasn't been created in the database yet.

Now make a few changes to the open theme template, and save. This will create a database record. Now refresh the page and inspect the API response (filter by template)

When creating a new custom templates, WordPress adds a database record immediately, and therefore the modified property is available.

[andrewserong]

Nice work on this one @ramonjd! Since this PR is quite large, you might have already explored this, but I was wondering if it'd be possible to add the modified field via a register_rest_field call in a rest_api_init action, using wp_template as the object type? From a quick skim of WP_REST_Templates_Controller it looks like it should (in theory) support additional fields being added via a hook, and I think it winds up being registered with the wp_template type?

Just thought I'd mention it in case it could avoid having to copy / paste more code from core to Gutenberg. No worries if that won't work, though, and we need to have the duplication!

[ramonjd]

Since this PR is quite large, you might have already explored this, but I was wondering if it'd be possible to add the modified field via a register_rest_field call in a rest_api_init action, using wp_template as the object type?

Thanks @andrewserong

Oh, no I didn't try that route!

Just for context: all the API methods I copied across call either get_block_template or get_block_templates or both, which, in turn call _gutenberg_build_block_template_result_from_post. It's the latter function that constructs the object from WP_Block_Template and adds the modified property.

So we need to have both the rest field + schema as well as the updated WP_Block_Template class.

Worth a shot though. I can try to confirm.

[github-actions]

Flaky tests detected in fd88de2.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5275344341
📝 Reported issues:

• [Flaky Test] Pick the additional variation in the inserted Columns block #47057 in specs/editor/plugins/block-variations.test.js

[ramonjd]

🤣

This will do it 😄

diff --git a/lib/compat/wordpress-6.3/class-gutenberg-rest-templates-controller-6-3.php b/lib/compat/wordpress-6.3/class-gutenberg-rest-templates-controller-6-3.php
index cbe9b5242a..08518c35a3 100644
--- a/lib/compat/wordpress-6.3/class-gutenberg-rest-templates-controller-6-3.php
+++ b/lib/compat/wordpress-6.3/class-gutenberg-rest-templates-controller-6-3.php
@@ -80,6 +80,13 @@ class Gutenberg_REST_Templates_Controller_6_3 extends WP_REST_Templates_Controll
 
 		$response = parent::prepare_item_for_response( $item, $request );
 
+		if ( rest_is_field_included( 'modified', $fields ) && ! empty( $response->data['wp_id'] ) ) {
+			$post = get_post( $response->data['wp_id'] );
+			if ( $post ) {
+				$response->data['modified'] = $post->post_modified;
+			}
+		}
+
 		if ( rest_is_field_included( '_links', $fields ) || rest_is_field_included( '_embedded', $fields ) ) {
 			$links = $this->prepare_revision_links( $template );
 			$response->add_links( $links );
diff --git a/lib/compat/wordpress-6.3/rest-api.php b/lib/compat/wordpress-6.3/rest-api.php
index 757bd317dc..992d24f187 100644
--- a/lib/compat/wordpress-6.3/rest-api.php
+++ b/lib/compat/wordpress-6.3/rest-api.php
@@ -76,3 +76,25 @@ function gutenberg_update_global_styles_rest_controller( $args, $post_type ) {
 	return $args;
 }
 add_filter( 'register_post_type_args', 'gutenberg_update_global_styles_rest_controller', 10, 2 );
+
+/**
+ * Add the `modified` value to the `wp_template` schema.
+ *
+ * @since 6.3.0 Added 'block_types' property.
+ */
+function add_modified_wp_template_schema() {
+	register_rest_field(
+		'wp_template',
+		'modified',
+		array(
+			'schema'       => array(
+				'description' => __( "The date the post was last modified, in the site's timezone.", 'gutenberg' ),
+				'type'        => 'string',
+				'format'      => 'date-time',
+				'context'     => array( 'view', 'edit' ),
+				'readonly'    => true,
+			),
+		)
+	);
+}
+add_filter( 'rest_api_init', 'add_modified_wp_template_schema' );

I'll update this branch.

The contents of the previous commit will be instructive when porting to Core at least 😄

Thanks for the nudge @andrewserong 🙇

[ntsekouras]

Thanks for the PR Ramon! This looks good.

[andrewserong]

LGTM, this is working nicely for me!

Just one note of difference in testing between the PR description and the current state: it appears that when accessing the endpoint for a template that hasn't been modified, the modified attribute is still returned by the API, but it has a null value:

That seems good to me (I think it's more predictable if the key is consistent, but the value is null), but just thought I'd mention it in case it wasn't intentional.

Thanks again for all the follow-up! ✨

[ramonjd]

That seems good to me (I think it's more predictable if the key is consistent, but the value is null), but just thought I'd mention it in case it wasn't intentional.

Thanks @andrewserong !

I'd forgotten to update the description 😢