Make WordPress Core

Opened 12 years ago

Closed 11 years ago

#24056 closed defect (bug) (invalid)

Revisions: UI a bit unusable when you have ALOT of revisions

Reported by: lancewillett's profile lancewillett Owned by:
Milestone: Priority: highest omg bbq
Severity: blocker Version: 3.6
Component: Revisions Keywords: has-patch
Focuses: Cc:

Description

It could be a good idea to limit to last 25 or 50 revisions in the new UI.

I came across an extreme example of this on a WordPress.com site today, where I have something like 130 revisions for the Custom CSS post type. But, this same issue could apply to core post types, though—posts and pages—if the number is high enough.

When I loaded the revisions page, the "calculating revision diffs" message rans for a few minutes, and then "arrow" to move with was moved way off the screen to the right, creating a horizontal scrollbar.

The next and previous buttons are obscured by the long scrubber timeline graphic.

Screenshot attached.

Attachments (8)

revisions-ui-css.png (144.9 KB) - added by lancewillett 12 years ago.
24056.patch (4.2 KB) - added by a.hoereth 12 years ago.
Rough pagination for revisions
24056.2.patch (3.9 KB) - added by a.hoereth 12 years ago.
Rough pagination implementation for revisions. Breaks stuff!
24056-prioritize.patch (2.0 KB) - added by a.hoereth 12 years ago.
Prioritize revision fetching according to temporal distance to the handle/handles
24056-pagination.patch (5.2 KB) - added by a.hoereth 12 years ago.
24056-pagination.2.patch (5.3 KB) - added by a.hoereth 12 years ago.
fixes missing last page
24056-combined.patch (16.8 KB) - added by a.hoereth 11 years ago.
24056-combined.2.patch (16.3 KB) - added by a.hoereth 11 years ago.

Download all attachments as: .zip

Change History (30)

#1 @SergeyBiryukov
12 years ago

  • Component changed from General to Revisions
  • Milestone changed from Awaiting Review to 3.6
  • Priority changed from normal to high
  • Version set to trunk

#2 @adamsilverstein
12 years ago

also noted in #23935. because the tick marks require a certain minimum amount of space, a given screen width can only accommodate a set number of tick marks. we might be able to make this minimum a bit smaller (currently 10 pixels).

should we set a maximum number of revisions to display, or limit the number based on screen size? what about the revision list meta box on the post page, same limit? i don't know why someone would want to store over a hundred revisions, but if we disabled that option i'm sure we would find out :)

#3 @ocean90
12 years ago

  • Keywords needs-patch added

IRC log from todays dev chat.

  • Limit revisions
  • Add a naviagtion under the slider older/newer or 1-50|51- 100
  • hard refresh, but two-handle not available on old screens
  • Exclude pagination in "compare two"
Last edited 12 years ago by ocean90 (previous) (diff)

#4 @adamsilverstein
12 years ago

  • Cc adamsilverstein@… added

@a.hoereth
12 years ago

Rough pagination for revisions

#5 @a.hoereth
12 years ago

  • Cc a.hoereth@… added

24056.patch adds rough functionality for pages. Waiting for dev feedback before investing more time in it.

At the moment this adds pages with 5 revisions each! Change 'pageSize' parameter of wpRevisionsSettings $settings. Furthermore this breaks "compare two revisions" functionality atm.

How should the pagination funtionality be designed? The current revision needs to be somehow highlighted and be sticky on all pages I guess. Further more this sucks for comparing two revision which are long time apart..? Maybe solvable by making the current revision AND the currently focused revision sticky.

Version 0, edited 12 years ago by a.hoereth (next)

@a.hoereth
12 years ago

Rough pagination implementation for revisions. Breaks stuff!

#6 @adamsilverstein
12 years ago

note: see - patch on #23901 to allow close to 100 revision tick marks

#7 follow-up: @ocean90
12 years ago

  • Priority changed from high to highest omg bbq
  • Severity changed from normal to blocker

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

#8 in reply to: ↑ 7 ; follow-up: @adamsilverstein
12 years ago

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

@a.hoereth
12 years ago

Prioritize revision fetching according to temporal distance to the handle/handles

#9 in reply to: ↑ 8 ; follow-up: @a.hoereth
12 years ago

Replying to adamsilverstein:

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

demo for 24056-prioritize.patch: http://www.screenr.com/gpI7

#10 in reply to: ↑ 9 ; follow-up: @adamsilverstein
12 years ago

Replying to a.hoereth:

Replying to adamsilverstein:

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

demo for 24056-prioritize.patch: http://www.screenr.com/gpI7

very nice work, this will really help with a large number of revisions... i like your approach to the load prioritizing. the screencast show its working perfectly in one handle mode.

in two handle mode it is very close, still slightly off: when the left handle stops, only the comparisons for dragging the right handle are reloaded - the left handle comparisons haven't changed because the right handle hadn't moved, so they aren't reloaded.

therefore, i would expect ticks around the right handle position to load when stopping the left handle and conversely the ticks around the left handle to load when the right handle stops; in your patch, comparisons around _both_ handles are loaded, it should be the left or right depending on which handle just stopped.

hope that makes sense!

#11 in reply to: ↑ 10 ; follow-up: @a.hoereth
12 years ago

Replying to adamsilverstein:

Replying to a.hoereth:

Replying to adamsilverstein:

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

demo for 24056-prioritize.patch: http://www.screenr.com/gpI7

[...]

therefore, i would expect ticks around the right handle position to load when stopping the left handle and conversely the ticks around the left handle to load when the right handle stops; in your patch, comparisons around _both_ handles are loaded, it should be the left or right depending on which handle just stopped.

I can't really see the difference in loading behavior. For me it reloads all tickmarks without my patch as well: http://www.screenr.com/vAI7 (gets interesting at 1:40+)
No matter which handle is dragged, all tickmarks are (visually) reloaded.

Edit: My patch does not change anything about data loading, just about the order in which the data is loaded.

Last edited 12 years ago by a.hoereth (previous) (diff)

#12 in reply to: ↑ 11 ; follow-up: @adamsilverstein
12 years ago

Replying to a.hoereth:

Replying to adamsilverstein:

Replying to a.hoereth:

Replying to adamsilverstein:

Replying to ocean90:

This definitely needs to be done. It's currently unusable for > 50 revisions. a.hoereth is working on a new patch.

why is it unusable, because of time for page to load? prioritizing the load for the selected revision would be very helpful, still not sure how paging will work.

demo for 24056-prioritize.patch: http://www.screenr.com/gpI7

[...]

therefore, i would expect ticks around the right handle position to load when stopping the left handle and conversely the ticks around the left handle to load when the right handle stops; in your patch, comparisons around _both_ handles are loaded, it should be the left or right depending on which handle just stopped.

I can't really see the difference in loading behavior. For me it reloads all tickmarks without my patch as well: http://www.screenr.com/vAI7 (gets interesting at 1:40+)
No matter which handle is dragged, all tickmarks are (visually) reloaded.

Edit: My patch does not change anything about data loading, just about the order in which the data is loaded.

corrected this issue in #24346

still need to prioritize loads on opposite handle when stopping in two handle mode instead of both handles.

#13 in reply to: ↑ 12 @a.hoereth
12 years ago

Replying to adamsilverstein:

Replying to a.hoereth:

[...]

I can't really see the difference in loading behavior. For me it reloads all tickmarks without my patch as well: http://www.screenr.com/vAI7 (gets interesting at 1:40+)
No matter which handle is dragged, all tickmarks are (visually) reloaded.

Edit: My patch does not change anything about data loading, just about the order in which the data is loaded.

corrected this issue in #24346

still need to prioritize loads on opposite handle when stopping in two handle mode instead of both handles.

Okay, I will work on this.

#14 follow-up: @a.hoereth
12 years ago

24056-pagination.2.patch enhances my previously implemented pagination feature. Pages are by default set to 50 now.

  • On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state.
  • works in compare two mode
  • linking to a specific revision now brings you to the correct page

Further stuff to consider:

  • Consider making revisions currently selected in two handle mode sticky when the page changes so they can be compared to revisions on other pages.
  • The current and sticky revisions (most right and most left) need to be highlighted / separated somehow. Maybe give this thing more of a "chronological timeline" look and feel, add a clickable separator which brings you to the page in between or something.
Last edited 12 years ago by a.hoereth (previous) (diff)

@a.hoereth
12 years ago

fixes missing last page

#15 in reply to: ↑ 14 ; follow-up: @adamsilverstein
12 years ago

Replying to a.hoereth:

24056-pagination.2.patch enhances my previously implemented pagination feature. Pages are by default set to 50 now.

  • On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state.
  • works in compare two mode
  • linking to a specific revision now brings you to the correct page

Further stuff to consider:

  • Consider making revisions currently selected in two handle mode sticky when the page changes so they can be compared to revisions on other pages.
  • The current and sticky revisions (most right and most left) need to be highlighted / separated somehow. Maybe give this thing more of a "chronological timeline" look and feel, add a clickable separator which brings you to the page in between or something.

looking much better... a few comments/questions

  • when clicking on a revision from the list thats on page 2 the correct page is displayed, but the revision is not selected (handle not in correct position)
  • what do you mean by this: " On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state." ?
  • hitting Next at the end of of a page should take you to the next page if there is one (currently its disabled); same for previous button

#16 in reply to: ↑ 15 @adamsilverstein
12 years ago

Replying to adamsilverstein:

Replying to a.hoereth:

24056-pagination.2.patch enhances my previously implemented pagination feature. Pages are by default set to 50 now.

  • On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state.
  • works in compare two mode
  • linking to a specific revision now brings you to the correct page

Further stuff to consider:

  • Consider making revisions currently selected in two handle mode sticky when the page changes so they can be compared to revisions on other pages.
  • The current and sticky revisions (most right and most left) need to be highlighted / separated somehow. Maybe give this thing more of a "chronological timeline" look and feel, add a clickable separator which brings you to the page in between or something.

looking much better... a few comments/questions

  • when clicking on a revision from the list thats on page 2 the correct page is displayed, but the revision is not selected (handle not in correct position)
  • what do you mean by this: " On all pages you now get the current live revision at the most right of the slider. This way it is possible to compare posts on other pages to the current post state." ?
  • hitting Next at the end of of a page should take you to the next page if there is one (currently its disabled); same for previous button

also - don't show paging button when only one page

#17 follow-up: @a.hoereth
11 years ago

24056-combined.patch does the following:

  • Pagination for single mode (compare two mode only shows page 1, should be fine with 100 revisions per page)
  • Prioritization for diff loading
  • Refresh slider width on window resize

#18 in reply to: ↑ 17 @a.hoereth
11 years ago

Replying to a.hoereth:

24056-combined.patch does the following:

  • Pagination for single mode (compare two mode only shows page 1, should be fine with 100 revisions per page)
  • Prioritization for diff loading
  • Refresh slider width on window resize

Also worth noticing: The most left revision on all but the last page is compared with the newest revision on the next page.

#19 @a.hoereth
11 years ago

  • Keywords needs-testing has-patch ui-feedback added; needs-patch removed

#20 @ocean90
11 years ago

Patch looks good so far. Waiting for some feedback from Mark.

#21 @a.hoereth
11 years ago

Looks like this got lowered in priority behind #24425
Therefore: A screencast demonstrating this patch for later integration considerations: http://screenr.com/8ssH

#22 @ocean90
11 years ago

  • Keywords needs-testing ui-feedback removed
  • Milestone 3.6 deleted
  • Resolution set to invalid
  • Status changed from new to closed

Generated a post with 200 revisions. It's fast. No issues.

[24520] / #24425

Note: See TracTickets for help on using tickets.