Opened 10 years ago
Closed 9 years ago
#30232 closed enhancement (wontfix)
Allow $revisions to be passed explicitly to wp_prepare_revisions_for_js()
Reported by: | ericlewis | Owned by: | adamsilverstein |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.6 |
Component: | Revisions | Keywords: | |
Focuses: | javascript | Cc: |
Description
wp_prepare_revisions_for_js() assembles data for the Revisions experience.
With some minor tweaking, we can open it up for alternative custom experiences.
I'm currently working on a post forking plugin, which uses revisions as forks. Default revisions set their post status to inherit. My forks use normal post statuses to take advantage of our native publishing workflow.
I'm reusing components of the revisions javascript stack where possible (see screenshot), but hitting a snag with wp_prepare_revisions_for_js().
wp_prepare_revisions_for_js() grabs all revisions for a post and stuffs them into the data object passed back utilizing wp_get_post_revisions(). This is problematic for me, because that function assumes all revisions have a post status of inherit.
I'd like to suggest allowing an abstract group of $revisions to be passed into wp_prepare_revisions_for_js() which, when present, will be used instead of the deault query.
Attachments (3)
Change History (15)
#1
@
10 years ago
- Keywords has-patch 2nd-opinion dev-feedback added
In attachment:30232.diff, move wp_prepare_revisions_for_js() to accept an array hash instead of a string of arguments with full back-compat.
Allow for revisions to be provided in the hash.
#2
@
10 years ago
attachment:30232.2.diff revised from feedback: @wonderboymusic suggested since my use case is the exception not the rule, the core invocation should remain as is, and not be considered deprecated.
#3
@
10 years ago
Looks fine to me - I would like someone else to weigh in on what might get weird, if anything
This ticket was mentioned in Slack in #core by adamsilverstein. View the logs.
10 years ago
This ticket was mentioned in Slack in #core by eric. View the logs.
10 years ago
#11
@
9 years ago
@ericlewis
Thanks for the detailed description: I looked at the patch and understand its goal. The code seems sound and I don't have a problem with the change...
Wondering however: could you achieve what you want with a filter on $revisions
right before the call to wp_get_post_revisions
? This might be a more flexible approach, allowing developers to readily alter the $revisions
object as they need, without calling the function directly. It would also be a relatively smaller change.
What would you think of a filter approach?
#12
@
9 years ago
- Keywords has-patch 2nd-opinion dev-feedback removed
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from reviewing to closed
What would you think of a filter approach?
It would offer similar functionality but the implementation might be awkward (adding filters before and after function invocations).
I'm going to close this ticket. There doesn't seem to be good traction here, and the forking plugin I wrote broke in 4.4.
Without being in the weeds of implementing post forking, I don't have confidence this is useful.
Use case example: an Edit Revision page reusing Revisons JS components