Opened 19 years ago
Closed 17 years ago
#2004 closed defect (bug) (fixed)
Pages page should page
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 2.6 | Priority: | normal |
Severity: | normal | Version: | 2.0 |
Component: | Administration | Keywords: | needs-patch |
Focuses: | 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.
Pull Requests
- Loading…
Change History (17)
#4
@
18 years ago
- Keywords needs-patch added; bg|needs-patch removed
- Milestone changed from 2.2 to 2.4
#5
@
18 years ago
There is a Search Pages plugin which seems to work just fine for searching, not paging though.
http://www.internetofficer.com/wordpress/search-pages/
#8
@
17 years ago
- Milestone 2.6 deleted
- Resolution set to wontfix
- Status changed from new to closed
No traction in almost 2 years, so closing as wontfix.
Feel free to re-open if you have additional information/patches/suggestions/...
#9
@
17 years ago
- Keywords old-inactive-9mos-ticket removed
- Milestone set to 2.6
- Resolution wontfix deleted
- Status changed from closed to reopened
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.
#11
in reply to:
↑ 10
@
17 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).
#13
@
17 years ago
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.
#14
@ Lead Tester
17 years ago
- Owner changed from anonymous to hailin
- Status changed from reopened to new
#15
@
17 years ago
- 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.
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?