Restore This Autosave does not work for custom post types that don't support 'revisions'

[bobbingwide]

If you have a custom post type that doesn't support revisions but you manage to create an autosave which is more recent than the current version then you get offered the opportunity to restore it, but the restore action doesn't complete. You end up in an annoying(*) loop.

Expected result: CPT restored to the autosave.
Actual result: Redirected to edit.php for the CPT

Steps to create the problem.

1. Ensure your CPT doesn't support 'revisions'
2. Create a new post and publish it
3. Create an update but don't publish it... just let it autosave
4. When you see the "Draft saved" message just quit
5. Edit the post again.
6. You will be shown the message:

There is an autosave of this post that is more recent than the version below.

7. Click on the View the autosave link
8. Click on Restore This Autosave button
9. End up at the list of posts for this CPT.
10. go to step 5.

Introduced by: #23497, change [23769]

Note:
Fixing this bug by simply reinstating the test on !wp_is_post_autosave( $revision ) leads to #27244 being applicable.
In my opinion, this follow on problem is preferable to the current behaviour.

Workaround for developers:
Define 'revisions' support for your CPTs... especially those which support 'editor'.

(*) What's annoying is that you get to see the autosaved version but it's not just a simple case of copying and pasting the text since the two versions get merged.

[bobbingwide]

Patch to reinstate test for autosave when post type doesn't support revisions

[adamsilverstein]

This looks reasonable, I don't recall why the autosave check was removed.

[adamsilverstein]

Indeed, autosaves are a special type of revision and currently you cannot correctly restore them if you have a CPT that doesn't support revisions - even if they are saved. And despite the fact that the message indicates you can. Wrong!

Your solution seems reasonable, another approach would be not doing autosaves for CPTs with revisions disabled;

Maybe the most robust solution would be to introduce an option supports->'autosaves' for custom post types and enable/disable based on that - that way autosaves gains a little autonomy, even if it is still a special type of revision in the back end.

[wonderboymusic]

not new, shall punt

[adamsilverstein]

Leaving closed. I believe this is resolved in Gutenberg, if not we will work on a new issue there.