Make WordPress Core

Opened 9 years ago

Closed 8 years ago

#30232 closed enhancement (wontfix)

Allow $revisions to be passed explicitly to wp_prepare_revisions_for_js()

Reported by: ericlewis's profile ericlewis Owned by: adamsilverstein's profile 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)

Screenshot 2014-11-01 17.05.06.png (109.7 KB) - added by ericlewis 9 years ago.
Use case example: an Edit Revision page reusing Revisons JS components
30232.diff (4.8 KB) - added by ericlewis 9 years ago.
30232.2.diff (4.0 KB) - added by ericlewis 9 years ago.

Download all attachments as: .zip

Change History (15)

@ericlewis
9 years ago

Use case example: an Edit Revision page reusing Revisons JS components

@ericlewis
9 years ago

#1 @ericlewis
9 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.

@ericlewis
9 years ago

#2 @ericlewis
9 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 @wonderboymusic
9 years ago

Looks fine to me - I would like someone else to weigh in on what might get weird, if anything

#4 @ericlewis
9 years ago

  • Milestone changed from Awaiting Review to 4.1

#5 @DrewAPicture
9 years ago

  • Owner set to adamsilverstein
  • Status changed from new to reviewing

This ticket was mentioned in Slack in #core by adamsilverstein. View the logs.


9 years ago

#7 @johnbillion
9 years ago

  • Milestone changed from 4.1 to Future Release

This ticket was mentioned in Slack in #core by eric. View the logs.


9 years ago

#9 @chriscct7
8 years ago

Patch still applies

#10 @ericlewis
8 years ago

@adamsilverstein any feedback on this?

#11 @adamsilverstein
8 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 @ericlewis
8 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.

Note: See TracTickets for help on using tickets.