Revisions Update, Jan 22nd
This week the revisions team had our first in-person meeting and we started by setting out office hours for this cycle which are 4pm UTC on Mondays and Thursdays. We then went through and reviewed a large number of open trac tickets related to revisions to get a feel for the existing bugs and enhancement requests as well as to set down a line as to what we feel is and isn’t in scope.
We ended our review with 8 “in-scope” existing tickets:
Bugs:
- #16215 – Post Revision history displays the incorrect author
- #20982 – Attribution of changes via edit_last after restore
- #16847 – Capability check fails for custom post type revision edit (& map_meta_cap no good)
- #9843 – Duplicate autosave/revisions clutter the database
Enhancements:
- #/22289 – Filter to override WP_POST_REVISIONS (or define it later)
- #19932 – More context when display revision info for plugins
- #18733 – Show revision number for post/pages in Revision list
- #7237 – Multiple clean_post_cache() calls when saving a post due to post revisions
We explicitly left the following out of scope:
- #9681 – Add hooks to allow a plugin to support the deletion of unneeded revisions
- #20564 – Post Meta Revisions
- #20299 – Preview changes on a published post makes all post meta “live”
- #11049 – Page Preview does not autosave page template
After the trac ticket discussion we then talked about UI ideas and set ourselves some goals for this week:
- More UI mockups – to come in the comment thread here
- Start investigating and addressing some of the bugs
Full logs of our IRC Chat are here
John Saddington 12:19 pm on January 23, 2013 Permalink
I wonder how many people have had mega issues with post meta revisions and wanting that. Hmm.
Helen Hou-Sandi 2:05 pm on January 23, 2013 Permalink
Plenty of people. Doesn’t make it in-scope, though.
Travis Northcutt 2:24 pm on January 23, 2013 Permalink
Given that Alex King volunteered (albeit 9 months ago, so I don’t know if he has the time right now) to clean up what they built for inclusion in core, would it be feasible to get it in scope if the work is done by people other than Westi et al.? (Serious question – I’m not familiar with how much work a committer has to do once a good patch is presented for inclusion).
Bryan Petty 8:24 pm on January 23, 2013 Permalink
Maybe, but it wouldn’t hurt to start patch reviews, testing, discussion and revising on the ticket either way. If it’s ready in time and there’s someone with the time to commit it, great, but otherwise, there will be that much less work involved with getting it included in 3.7.
Helen Hou-Sandi 9:09 pm on January 23, 2013 Permalink
Indeed, there is nothing wrong with working on it, anyway.
Stephanie Leary 4:07 pm on January 25, 2013 Permalink
For the diff UI: what if we had Visual and HTML options just like we do in the editor? The HTML view would show the markup, as we do now. The Visual would show only the content changes. Here’s a very old example using del and ins tags to emulate Word’s track changes feature (this was before Word switched to the bubble style it uses now).
adamsilverstein 5:30 pm on January 31, 2013 Permalink
there was some discussion today that #20564 and #20299 are going to block progress on the workflow changes, we may need to reconsider those tickets if possible.