Opened 12 years ago
Last modified 5 years ago
#23314 new enhancement
Allow published posts to be revised without being updated immediately
Reported by: | kovshenin | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Revisions | Keywords: | editorial-flow needs-screenshots has-patch |
Focuses: | Cc: |
Description
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.
Attachments (6)
Change History (40)
#5
@
12 years ago
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 :)
#7
@
12 years ago
In 23314.2.diff:
- Updated the previous patch, uses
post_type_supports
to check foradvanced-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
#8
@
12 years ago
I put some working patches up on those blocking tickets if you'd like to check them out.
#9
@
12 years ago
- Keywords 3.7-early added
- Milestone changed from 3.6 to Future Release
Let's revisit this in 3.7.
#10
@
12 years ago
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.
#11
@
12 years ago
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?
#14
@
11 years ago
- Milestone changed from 3.7 to Future Release
This shouldn't have been moved to 3.7 (was done during a bulk edit).
This ticket was mentioned in IRC in #wordpress-dev by danielbachhuber. View the logs.
11 years ago
#18
@
10 years ago
Refreshed 23314.2.diff against trunk in 23314.3.diff
#19
@
10 years ago
Refresh against trunk in 23314.4.diff
This ticket was mentioned in Slack in #core by dd32. View the logs.
9 years ago
#21
@
9 years ago
23314.5.diff: refresh against trunk, slight cleanup
this works pretty well as is, could use some polish :) I'll add some screenshots soon.
#22
@
9 years ago
- Keywords needs-screenshots has-patch added; needs-patch removed
- Type changed from feature request to enhancement
This ticket was mentioned in Slack in #core by phikai. View the logs.
9 years ago
#26
@
9 years ago
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.
#27
@
9 years ago
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.
#28
@
9 years ago
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.
#29
@
9 years ago
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.
#30
@
9 years ago
+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?"...
#31
@
9 years ago
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.
@
9 years ago
How I implemented UI for content versioning in my own CMS, as a point of reference for the discussion.
#32
@
9 years ago
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.
The post forking plug-in mentioned above looks like a good starting point to addressing this problem in WP.
Will be working on a patch in the next few days. More info here and some mockups here.