Allow published posts to be revised without being updated immediately

[kovshenin]

Two things. Let's allow contributors to submit changes for review to their published posts. Let's also allow users to make changes to their posts and pages and save those changes, without updating the published post or page.

[kovshenin]

Will be working on a patch in the next few days. More info ​here and some mockups ​here.

[nacin]

I think this is blocked by #20299 and #20564.

[kovshenin]

23314.diff​ is more of a proof-of-concept than an actual patch.

• Odd metabox behaviour, probably because some metaboxes try to dig up info based on the current post ID and type, which is a revision.
• "Save as Draft" needs better language. Any suggestions?
• Users unable to edit the original post without discarding the draft changes.
• Edit screen and Quick Edit were not touched.

Questions/problems:

• Should we be able to edit taxonomy and meta-data in a revision without altering the published post? How does this affect plugins?
• Should we be able to change the status of a draft change? Like set it as pending, or private.
• Since the edit screen sees a revision post, it'll probably upload attachments to the revision, and not the post. Plugins and shortcodes that sometimes rely on post children (like [gallery]) might break. Any ideas how to solve this?
• Should we introduce a new post type for this, or should we keep using revisions?
• How does this fit into the revisions workflow?

Feedback welcome :)

[kovshenin]

In 23314.2.diff​:

• Updated the previous patch, uses post_type_supports to check for advanced-revisions
• Better routine for previewing draft revisions
• Works with the revision post type rather than hi-jacking edit-form-advanced to think it's a different post type
• Title, content and excerpt are the only versioned fields, others are not rendered
• Does not yet work for contributors, did not test compatibility with post locking
• You can still edit the original post in Quick Edit while a draft version is available, even change the status

[WraithKenny]

I put some working patches up on those blocking tickets if you'd like to check them out.

[kovshenin]

Let's revisit this in 3.7.

[knutsp]

I think this could be implemented this way:

Copy the published post to a new post with the original as ancestor, not as a revision, but as a copy (a new status?). Such post are seen as posts and can be edited separately, with revisions, except for the slug.

When a copied post is published, the original post and all its revisions are merged into revisions of this. The new, published post takes the same slug/name as the original.

The post_id will be different. Maybe only expose this feature when pretty permalinks are used.

[husobj]

The post_id of a published post should never change - that could lead to all sorts of issues.

When the copy is publish I think it would need to first create a revision of the ancestor, then move the copy's data (and meta data?) to the ancestor?

[wonderboymusic]

these are all marked 3.7-early

[nacin]

This shouldn't have been moved to 3.7 (was done during a bulk edit).

[SergeyBiryukov]

Related: #10834

[adamsilverstein]

Related: #27244

[adamsilverstein]

refresh against trunk

[adamsilverstein]

Refreshed 23314.2.diff against trunk in 23314.3.diff​

[adamsilverstein]

refresh against trunk

[adamsilverstein]

Refresh against trunk in 23314.4.diff​

[adamsilverstein]

23314.5.diff​: refresh against trunk, slight cleanup

this works pretty well as is, could use some polish :) I'll add some screenshots soon.

[SergeyBiryukov]

#35059 was marked as a duplicate.

[Robert Hickman]

Is there any ETA on getting this implemented?

[zorrobyte]

Just chiming in that this functionality would be greatly appreciated for many types of "App" like sites. I build sites using Toolset and many directory type WordPress sites would benefit from not having listings disappear from the main site during the edit->pending approval flow.

[Robert Hickman]

This functionality was absolutely critical for the major update and continued maintenance one of my sites is going through. Because of which I ended up implementing this functionality on a CMS I had written a number of years ago, and moved my site onto that. This was easier than maintaining a fork of wordpress/ merging updates.

[ericlewis]

There are plugins that have tackled this problem. ​Post Forking by @jorbin @danielbachhuber and @benbalter. I ​gave it a go about a year ago.

This should be developed as a feature plugin. Trac is a good place for quick iteration on a small piece of functionality to add to WordPress, but large functionality like this would do well in a working group.

[Robert Hickman]

Wordpress already has content revisions, once that function exists implementing this should not be difficult. I believe it should be in the core as it would make said content versioning considerably more useful.

[steevithak]

+1 for needing this feature in Wordpress core. This is basic CMS functionality, not something we should have to rely on a third party to add to WP via a plugin. When training clients to use a new WP site, one of the things they always ask us is along the lines of "how do save modified articles/posts without publishing them so they can be approved before going live?"...

[ericlewis]

To be clear, I'm not saying we shouldn't do this in core. Just that we should ​develop it as a feature plugin before considering it for core.

[Robert Hickman]

How I implemented UI for content versioning in my own CMS, as a point of reference for the discussion.

[Robert Hickman]

To further describe the above image, content_revisions.png​, this is how I implemented this functionality in the UI of my own CMS. As a point of referance for how it could be implemented in WP.

All revisions of a content item are first class citizens. When a new revision is created, the previously published revision retains it's published flag and the latest can be changed without changing the previous content items at all. Previous content items can be viewed by clicking on them in the sidebar, which simply displays there content in the edit form.

When the updated content is published it simply clears the 'published' flag of the previously published item, and sets this flag to true for the item which was chosen to be published. Because of this arrangement, it is also easy to republish a previous version, should it be required.

The data schema of this system is quite different from what wordpress uses. As mentioned all 'revisions' are first class, it does not distinguish between 'post'/'page' and 'revision' like wordpress does. As a side effect of this the DB ID field of the published item will change if a different version is published. Doing such would break things under wordpress's schema if a plug-in referenced the ID rather than the item marked as published.

This functionality could be implemented on the data schema that Wordpress uses if the 'published' revision where copied over the data in the 'post'/'page' etc record.