Ticket #2004 (closed defect (bug): fixed)

Opened 6 years ago

Last modified 4 years ago

Pages page should page

Reported by: matt Owned by: hailin
Priority: normal Milestone: 2.6
Component: Administration Version: 2.0
Severity: normal Keywords: needs-patch
Cc:

Description

For people that have > 100 pages listing them all doesn't make much sense. We should improve this by offering paging for more than 50 and also search.

Attachments

pages page should page proof.patch Download (13.1 KB) - added by Jairus 4 years ago.
dirty proof-of-concept for paging on wp 2.3

Change History

  • Keywords bg|needs-patch added

This would be pretty complex in terms of the hierarchy - wouldn't you end up having to generate the full hierarchy then chop the list down to the first X entries?

If the consideration is screen space, then perhaps some kind of tree view might be better?

comment:3   matt5 years ago

  • Milestone changed from 2.1 to 2.2
  • Keywords needs-patch added; bg|needs-patch removed
  • Milestone changed from 2.2 to 2.4

There is a Search Pages plugin which seems to work just fine for searching, not paging though.  http://www.internetofficer.com/wordpress/search-pages/

  • Keywords old-inactive-9mos-ticket added
  • Milestone changed from 2.5 to 2.6

Bumping milestone for feature freeze.

  • Status changed from new to closed
  • Resolution set to wontfix
  • Milestone 2.6 deleted

No traction in almost 2 years, so closing as wontfix.

Feel free to re-open if you have additional information/patches/suggestions/...

  • Keywords old-inactive-9mos-ticket removed
  • Status changed from closed to reopened
  • Resolution wontfix deleted
  • Milestone set to 2.6

Re-opening, this is a bad experience issue for people with a large number of pages, because the page can take a long time to load.

As more people adopt WP as a general purpose CMS, it will likely soon become more urgent.

I understand that pages having children pages makes this a potentially challenging problem.

+1 to the tree view idea

comment:11 in reply to: ↑ 10   Jairus4 years ago

A collapsible tree view (like  pageMash) doesn't necessarily address the scaling issue, even if it addresses usability concerns. (You could theoretically use something like an AJAX tree which only requests data about branches as they're opened, but that won't solve problems for installs with large numbers of pages at the root level.)

From a UI point of view, page hierarchy complicates things for the user, if they have a large number of pages paginated, and they're trying to find a specific item. I think the ideal solution would allow for both a flattened view (ie: sortable title/id/date columns) and a nested view that displays parent/child relationships (kind of like the current interface).

Relates to #6561

Jairus4 years ago

dirty proof-of-concept for paging on wp 2.3

A student here wrote up a quick-and-dirty proof of concept for paging the 'manage pages' page on 2.3. It's very rough around the edges and needs a lot of work (it doesn't display parent/child information), but it'll display 'manage pages' in 5-10 seconds with 4000 pages in the db, instead of it taking 5-10 minutes.

  • Owner changed from anonymous to hailin
  • Status changed from reopened to new
  • Status changed from new to assigned

It appears that the idea "demand load the category list to manage thousands of categories" can be applied here.

However, currently that needs some improvement (see #6677) Once we have some test mileages on that idea and like it, we will design a good, long-term solution for this issue.

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.