Opened 13 years ago
Closed 13 years ago
#17685 closed defect (bug) (fixed)
Posts Administration Pagination/Search Bug
Reported by: | JohnONolan | Owned by: | azaozz |
---|---|---|---|
Milestone: | 3.2 | Priority: | normal |
Severity: | minor | Version: | 3.1.4 |
Component: | Administration | Keywords: | has-patch dev-feedback |
Focuses: | Cc: |
Description
When searching through posts in the administration area, pagination is not reset when a new search term is entered.
Steps to reproduce:
- Go to the main posts overview screen
- Enter a search term and press enter
- Navigate to page 3 of search results
- Enter a new search term and press enter
Expected behaviour: You are taken to page 1 of search results for the new term
Actual behaviour: You are taken to page 3 of search results for the new term
Note: Search terms must both have sufficient results to reproduce this bug. If the first term has 3 pages of results and the 2nd term has 1 page of results then this bug doesn't appear.
Attachments (5)
Change History (20)
#2
@
13 years ago
The problem is caused by the <input class="current-page" name="paged">
which is submitted along with the search query, and therefore forces the page number to be retained. This is an issue with the list-table class and so affects all list tables.
#3
follow-up:
↓ 4
@
13 years ago
- Keywords has-patch added; needs-patch removed
17685.diff - a bit hacky
#4
in reply to:
↑ 3
@
13 years ago
Replying to greuben:
17685.diff - a bit hacky
Patch doesn't appear to resolve the issue.
I'm still seeing it.
- Add 10 posts
- Set post view to 5 per page
- Move to page 2
- Search for term
- Stays on page 2
#5
@
13 years ago
This needs to be fixed for more than just search - it affects all filters. For example:
- Filter posts by category and go to page 3 of the results
- Now filter posts by another category - you will be taken to page 3 again (assuming both categories have enough posts)
I think this needs some overhaul of how wp-list-table
handles filters and paging - and probably something that will have to wait till 3.3.
#6
@
13 years ago
- Milestone changed from 3.2 to Future Release
Agree with @solarissmoke, we would need to fix this for all filters and probably add some more logic to handle all possible combinations of filters and search results.
#8
@
13 years ago
I have an idea for a patch.
This is a pretty bad regression and usability issue. Let's move this back to 3.2 for now.
#9
@
13 years ago
What if we printed the query string on the page, and on submit (via JS), we detect to see if the query string -- other than paged -- changed? At which point we then detach the paged inputs and let the submit continue.
#10
@
13 years ago
- Keywords has-patch dev-feedback added; needs-patch removed
@nacin I had a similar idea, based on using JS alone. See patch.
#11
@
13 years ago
- Milestone changed from Future Release to 3.2
I didn't consider that if the page wasn't changing, then it should be reset. That's a brilliant solution.
#12
@
13 years ago
First pass only worked for wp-admin/edit.php
, have updated it to work with any form that uses the list-table class.
#14
@
13 years ago
Would have preferred backend/PHP solution. Perhaps force paged=1
when submitting new filter or new search?
Also we are adding another script file, queueing it, checking dependencies, etc. just for 4-5 lines of JS? Perhaps better to add it to common.js as it's used on several admin pages if we have to use JS there.
Confirmed as a 3.0 to 3.1 regression. Moving to 3.2. If not a simple patch, it'll need a punt.