[wp-trac] [WordPress Trac] #48953: Improved revision control related to posts and the numerous auxiliary benefits

[WordPress Trac]

#48953: Improved revision control related to posts and the numerous auxiliary
benefits
-------------------------+-----------------------------
 Reporter:  carike       |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Revisions    |    Version:  trunk
 Severity:  major        |   Keywords:
  Focuses:  performance  |
-------------------------+-----------------------------
 Imagine for a moment, the Gutenberg full-site editing capability is in
 full swing:
 - How does a user restore defaults?
 - How does a user easily undo actions?
 - How does a user easily go back to a previous theme?
 - If the user deletes a theme, how can all the associated custom post
 versions for that theme be deleted as well?

 That (and more) could be easily achieved if posts revisions worked in a
 different way.
 In the Gutenberg full-site editor example above, each theme could create a
 "branch" of revisions.
 There would then be major and minor versions.
 I propose that the default should be to keep all major versions (unless
 the user manually deletes them of course), as well as all minor versions
 since the last major version up to the current version.
 This would allow for the user to "back space" in the full site editor, but
 in a way that is actually meaningful.

 It has been suggested that a user could simply set the revisions constant.
 However, particularly in an environment that encourages "tinkering" like
 the Gutenberg full site editor would be, it is entirely possible that a
 user could create a thousand revisions in a very short period of time.
 Since there is no way to know which revision is which / search revisions,
 allowing users to "backspace" isn't meaningful.
 Having "branches" would also allow plugin authors to create simple
 mechanisms to do A/B split testing on appearance (not content, that should
 still be possible).

 Moreover, this has a huge implication on the size of the mySQL database,
 particularly in shared hosting environments and particularly when site
 content is exported and imported using the core Tools.

 While it is not feasible to keep 35 trivial changes to the background
 colour, every semi-colon change to a Terms of Service may very well be
 crucial.
 The core infrastructure should allow (whether inside core or via plugin)
 for different treatment of different post types in regards to revisions.

 This ticket is related to https://core.trac.wordpress.org/ticket/21666,
 but is not a duplicate.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48953>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform