id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,focuses 49532,"Clicking ""preview"" multiple times on a post causes an identical autosave revision to be created and destroyed repeatedly",inwerpsel,adamsilverstein,"How to reproduce: Click the preview button multiple times in a row, without making any changes to the post in between. This will result with the autosave revision being created and destroyed repeatedly (check the response of the api request that does the autosave, it alternates between 200 and 400). Detailed explanation: Suppose the post has no autosave revision yet. Clicking preview the first time results in a request being sent to ""/wp-json/wp/v2/post_type/{id}/autosaves?_locale=user"". In that request the autosave revision is looked up for the post. https://github.com/WordPress/WordPress/blob/master/wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php#L360 Then, because there is no record, it will create a new one ""as a special post revision"" at https://github.com/WordPress/WordPress/blob/master/wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php#L393 After creating the request returns 200 and the autosave revision record is in the database. Pressing the second time it will again look up the autosave revision and this time find it. Then an object is created with the $_POST data, but which has the old autosave revision's ID. That object is then compared to the current post, and if it's not different, wp_delete_post_meta is called with the old autosave ID and the record is deleted. Notice how now we're back in the same state as at the start (a post with no autosave revision). So we can keep on pressing the preview button and the record will keep on getting created and deleted, even though it contains the exact same data as the post of which it is an autosave. Why is this an issue: This creates and deletes records in the wp_posts table with no real use, causing unwanted load and exhausting the ids of the wp_posts table. Proposed solution: Either no record should be created in the first place if there is no difference, or the existing record shouldn't be deleted, even if it doesn't have any changes.",defect (bug),closed,normal,6.2,Revisions,5.4,normal,fixed,has-patch needs-testing dev-feedback has-unit-tests reporter-feedback,,"rest-api, performance"