[wp-trac] [WordPress Trac] #56922: Template / Template parts revision / autosave REST API are broken
WordPress Trac
noreply at wordpress.org
Tue Oct 10 08:09:51 UTC 2023
#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 spacedmonkey):
Thank you for testing this @ironprogrammer. Great feedback and amazing
work!
Just wanted to reponse to your feedback at the end.
> 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.
I was unable to replicate this error. Can provide more context.
[[Image(https://core.trac.wordpress.org/raw-
attachment/ticket/56922/Screenshot%202023-10-10%20at%2008.56.12.png)]]
> ⚠️ 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 (see this example). EXPECT: The
passed revision ID is checked against the post type.
Basically these are the same issue. The parent id of the revision is not
compared original post. Sadly this is an issue with the revisions
controller as well. See screen, where I am requesting a revision for post
1 and I get the a revision for from a different post. This is completely
unrelated to this change. But it is a great find and I will create a bug
for this after beta has died down.
[[Image(https://core.trac.wordpress.org/raw-
attachment/ticket/56922/Screenshot%202023-10-10%20at%2008.59.49.png)]]
> ⚠️ 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.
This issue is an related to the change. This is how revisions are made,
using the revisions API ( functions ) in core. They are a little weird,
IMO and could do with some review. But this change should be considered,
will create a follow up ticket for this idea.
TDLR, all the documented bugs are upstream issues with revisions api or
the revisions / autosave controllers. These issues should be handled
elsewhere in a different ticket.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/56922#comment:35>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list