WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#11324 closed enhancement (duplicate)

Are Revisions Always Necessary?

Reported by: miqrogroove Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8.4
Component: Revisions Keywords: needs-patch
Focuses: Cc:

Description

I find myself going to phpMyAdmin more and more often for post edits. Not because I don't like revisions, but because most of my edits are administrative and do not affect the title or content.

Why does a new revision appear for every post when I bulk edit from wp-admin? Does adding tags or changing the ping status really do anything to the posts table other than change the time stamp? :S

Change History (13)

comment:1 follow-up: scribu4 years ago

  • Keywords needs-patch added

I suppose something like below would do the trick:

if ( $old_content == $new_content && $old_title == $new_title )
  // skip adding a new revision

comment:2 lloydbudd4 years ago

  • Milestone changed from 3.0 to Future Release

comment:3 in reply to: ↑ 1 ; follow-up: caesarsgrunt4 years ago

Replying to scribu:

I suppose something like below would do the trick:

if ( $old_content == $new_content && $old_title == $new_title )
  // skip adding a new revision

+1 to the general idea of not saving revisions for metadata changes.

In fact, I don't think a new revision is needed for a title change either... just for actual content changes.

comment:4 in reply to: ↑ 3 ; follow-up: nacin4 years ago

Replying to caesarsgrunt:

In fact, I don't think a new revision is needed for a title change either... just for actual content changes.

Disagree. Revisions should cover changes to the title, the content, and the excerpt. For that matter, it should also cover any changes stored in wpdb->posts, no? Such as a change in status and such.

comment:5 in reply to: ↑ 4 ; follow-up: caesarsgrunt4 years ago

Replying to nacin:

Replying to caesarsgrunt:

In fact, I don't think a new revision is needed for a title change either... just for actual content changes.

Disagree. Revisions should cover changes to the title, the content, and the excerpt. For that matter, it should also cover any changes stored in wpdb->posts, no? Such as a change in status and such.

Excerpt; yes, I agree.

Title - well, it's easy enough to revert a change there without revisions, but I'm not really fussed either way.

Status - Why??? I mean, it's easy enough to change the status back - easier than restoring a previous revision - and it's not as if you could not know what status to change it back to.

comment:6 nacin4 years ago

Let's say in a multi-editor site, I wanted to know who actually hit publish on a post that went through many revisions and multiple statuses. The current admin won't show that information for a revision, but it is stored in wp_posts.

Taking it further, that's a good way to manage an editing workflow. Same thing with title. Sure, it's easy enough to figure out what it used to be, but who made the change?

Another example: Even if post information is identical from row to row*, the revision should still be saved on form submit, as it happens now. Let's say, again in an editing workflow, that an editor goes into a post to edit it. He doesn't need to change anything, but as part of their workflow, he submits the form and saves an unchanged revision. Why? Because now there is a record of exactly what he read and approved.

(*I'm excluding the revision author here.)

I think here is what I am suggesting:

We save the revision as we do now, but only display it in admin as a revision if content, title, or excerpt differ from the revision before it. Then, any plugin that exposes additional wp_posts revision information can set it so all revisions are displayed. This also prevents any backwards compatability issues that may arise by no longer saving all revisions.

comment:8 in reply to: ↑ 5 Denis-de-Bernardy4 years ago

Replying to caesarsgrunt:

Status - Why??? I mean, it's easy enough to change the status back - easier than restoring a previous revision - and it's not as if you could not know what status to change it back to.

morover... status is set to inherit if memory serves.

comment:9 Denis-de-Bernardy4 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

closing as dup of #9843, since there isn't anything more in here than in that older one. there even is some code in #9843 if someone feels like writing a patch.

comment:10 miqrogroove4 years ago

Seems like trac wasn't sending out e-mails yesterday. I voted up #9843, thanks for the link.

comment:11 caesarsgrunt4 years ago

Trac doesn't always send emails. I got some yesterday, but I often don't get them. Don't know why; it's very annoying...

comment:12 Denis-de-Bernardy4 years ago

trac doesn't send emails when you open a ticket without adding a comment. if you comment to change the slightest thing, you'll get emails.

comment:13 caesarsgrunt4 years ago

Yeah; but I often don't get emails when people comment on my tickets or on tickets on which I have commented.

Also, I do get emails when I open a ticket!

Note: See TracTickets for help on using tickets.