[wp-trac] [WordPress Trac] #56922: Template / Template parts revision / autosave REST API are broken

[WordPress Trac]

#56922: Template / Template parts revision / autosave REST API are broken
-------------------------------------------------+-------------------------
 Reporter:  spacedmonkey                         |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  6.4
Component:  REST API                             |     Version:  4.7
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:  rest-api
  testing changes-requested                      |
-------------------------------------------------+-------------------------

Comment (by ironprogrammer):

 It's great to see this PR moved forward! Thanks for all the effort! 🙌🏻

 == Test Report
 PR tested: https://github.com/WordPress/wordpress-develop/pull/3533

 === Steps to Reproduce and Test Patch
 ''These steps are adapted from the test report provided in comment:16.
 Items marked with a green check ✅ indicate expected results.''

 1. Activate Twenty Twenty-Four and navigate to ''Appearance > Editor >
 Patterns > Manage all template parts'' and click the **Add New Template
 Part** button. Give it a name, "My Template Part", and Save. **DO NOT YET
 MODIFY OR SAVE ADDITIONAL CHANGES TO THIS TEMPLATE PART.**
 2. Using an HTTP request tool, such as Postman, or the basic auth plugin
 noted in comment:16, observe the GET response for the parent template part
 post, and take note of the `wp_id` value (this is the post `ID`):
 {{{#!php
 /wp-json/wp/v2/template-parts/twentytwentyfour/my-template-part
 }}}

 ''REPRODUCE''
 3. 🐛 Observe the GET response for the **revisions** endpoint:
 {{{#!php
 /wp-json/wp/v2/template-parts/twentytwentyfour/my-template-part/revisions
 }}}
 4. 🐛 Observe the GET response for the **autosaves** endpoint:
 {{{#!php
 /wp-json/wp/v2/template-parts/twentytwentyfour/my-template-part/autosaves
 }}}
 5. 🩹 Apply PR/patch.

 ''REVISIONS''
 6. Observe the GET response for the revisions endpoint again (Step 3).
 7. Modify the new template part (any trivial change should work) and click
 **Save** to persist the changes, creating a new revision.
 8. Observe the GET response for revisions endpoint again (Step 3).
 9. Modify the template part again and save the changes, creating another
 revision.
 10. Observe the GET response for revisions endpoint again (Step 3).
 11. Append each of the unique `wp_id` values from the previous response
 into separate requests, and observe the responses, e.g.
 {{{#!php
 /wp-json/wp/v2/template-parts/twentytwentyfour/my-template-
 part/revisions/1310
 }}}

 ''AUTOSAVES''
 12. Observe the GET response for the autosaves endpoint again (Step 4).
 13. To mimic an autosave in the database, start with one of the `wp_id`
 values from Step 11 and locate its record in the `wp_posts` table. Modify
 its `post_name` by changing "revision" to "autosave", e.g.
 `1309-revision-v1` => `1309-autosave-v1`, and commit the change.
 14. Observe the GET response for the autosaves endpoint again (Step 4).

 The same steps above can be performed with the `wp_template` post type by
 creating or modifying a template (''Appearance > Editor > Templates'').

 === Environment
 - Hardware: MacBook Pro Apple M1 Pro
 - OS: macOS 13.6
 - Browser: Safari 16.6, Postman 10.18.11
 - Server: nginx/1.25.2
 - PHP: 7.4.33
 - WordPress: 6.4-beta2-56769-src
 - Theme: twentytwentyfour v1.0, twentytwentythree v1.2
 - Active Plugins: none

 === Actual Results
 ''REPRODUCE''
 - 3. ✅ Reproduced 404 result for **revisions** endpoint, response code
 `rest_template_not_found`.
 - 4. ✅ Reproduced 404 result for **autosaves** endpoint, response code
 `rest_template_not_found`.

 ''REVISIONS''
 - 6. ✅ Endpoint returns `[]`, an empty response (i.e. "no revisions").
 - 8. ✅ Endpoint returns a JSON response with `"slug": "1309-revision-v1"`
 (i.e. "there is one revision").
 - 10. ✅ Endpoint returns a JSON response with two revisions in the
 response (each with a unique `wp_id` value).
 - 11. ✅ Requests for each unique `wp_id` value returns the individual
 revision.

 ''AUTOSAVES''
 - 12. ✅ Endpoint returns `[]`, an empty response (i.e. "no autosaves").
 - 14. ✅ Endpoint returns a JSON response with `"slug":
 "1309-autosave-v1"`.

 === Additional Information
 - In Step 13 I mimicked an autosave because I'm not sure if this is
 supported by template/template parts at this time.
 These observations are probably not blockers, but seem they should be
 documented or addressed in subsequent patches:
 - ⚠️ Any numeric ID added to the autosaves endpoint results in the same
 response as without specifying an ID (e.g. `/autosaves` = `/autosaves/1`),
 even if the post ID does not exist. Unsure if this is the expected
 behavior.
 - ⚠️ Note that requesting a revision ID from ''a different template part''
 (e.g. using the `my-template-part` endpoint to request a `footer`
 revision) returns the revision belonging to a different template part.
 **EXPECT: The passed revision ID is checked against the template part.**
 - ⚠️ The above also occurred when requesting a `wp_template` revision ID
 using the `wp_template_part` endpoint (also tested revisions from
 `wp_global_styles` post type). **EXPECT: The passed revision ID is checked
 against the post type.**
 - ⚠️ When requesting a revision ID of a `page` post type, a response was
 returned, but it was largely nulled out ([https://cloudup.com/cC1C98fa5fd
 see this example]). **EXPECT: The passed revision ID is checked against
 the post type.**
 - ⚠️ At this time it appears that `slug` values for revisions do not
 increment, e.g. for post ID 1309, each revision's slug is
 `1309-revision-v1` regardless of iteration. **EXPECT: The `-vX` suffix
 should increment with each subsequent revision.**

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