Opened 11 years ago
Closed 10 years ago
#25034 closed defect (bug) (fixed)
Searches reverts to previous search criteria
Reported by: | WebTechGlobal | Owned by: | nacin |
---|---|---|---|
Milestone: | 3.7 | Priority: | normal |
Severity: | normal | Version: | 3.1 |
Component: | Administration | Keywords: | has-patch needs-testing |
Focuses: | Cc: |
Description
I submitted a comments search. Then made a selection in the Bulk Actions menu but then changed my mind on that. I attempted to perform another search however the criteria for the new search reverted to the previous search in both URL and the text field itself.
I can confirm that it is the changing of the Bulk Actions menu causing this. Although minor, anyone who does happen to make a selection in the menu then attempt a search. May not notice and think their search results are valid.
Filter menu does not have the same effect.
Originally I thought the worst case scenario is a bad comments search and a rare set of motions to make that happen. Until I decided to try post search and the same thing happens there.
Attachments (7)
Change History (21)
#2
@
11 years ago
Sure...
- Enter search keyword/phrase in either post or comment search
- Submit the search
- Proceed to make a selection in Bulk Actions menu
- Now lets say we change our mind on doing that
- Attempt to execute a different search
I discovered this when I decided I needed to change my search just a little. So I changed one character, submitted and noticed the search value showing in address bar was the first search.
My guess here is on interacting with Bulk Actions menu the current URL becomes the form action.
#3
@
11 years ago
I can confirm this bug on trunk.
Steps to reproduce
- go to edit.php
- Entered he in the search form and pressed return
- Selected "Edit" in bulk actions
- Checked a few boxes on posts to edit
- Clicked Apply
- Clicked Cancel on inline bulk edit
- Changed search term to hello pressed return
Result: Search reverted back to he. I tried mulitple times with different search terms and same result.
Looks like a 302 redirect:
Request URL:http://local-server.dev/wp-admin/edit.php?s=post+world&post_status=all&post_type=post&_wpnonce=527aed7f16&_wp_http_referer=%2Fwp-admin%2Fedit.php%3Fs%3Dpos%26post_status%3Dall%26post_type%3Dpost%26action%3D-1%26m%3D0%26cat%3D0%26paged%3D1%26mode%3Dlist%26action2%3D-1&action=edit&m=0&cat=0&paged=1&mode=list&action2=-1 Request Method:GET Status Code:302 Found Request Headersview parsed GET /wp-admin/edit.php?s=post+world&post_status=all&post_type=post&_wpnonce=527aed7f16&_wp_http_referer=%2Fwp-admin%2Fedit.php%3Fs%3Dpos%26post_status%3Dall%26post_type%3Dpost%26action%3D-1%26m%3D0%26cat%3D0%26paged%3D1%26mode%3Dlist%26action2%3D-1&action=edit&m=0&cat=0&paged=1&mode=list&action2=-1 HTTP/1.1 Host: local-server.dev Connection: keep-alive Cache-Control: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Pragma: no-cache User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36 DNT: 1 Referer: http://local-server.dev/wp-admin/edit.php?s=pos&post_status=all&post_type=post&action=-1&m=0&cat=0&paged=1&mode=list&action2=-1 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8
Gets Redirected to previous search:
Request URL:http://local-server.dev/wp-admin/edit.php?s=pos&post_status=all&post_type=post&action=-1&m=0&cat=0&paged=1&mode=list&action2=-1 Request Method:GET Status Code:200 OK Request Headersview parsed GET /wp-admin/edit.php?s=pos&post_status=all&post_type=post&action=-1&m=0&cat=0&paged=1&mode=list&action2=-1 HTTP/1.1 Host: local-server.dev Connection: keep-alive Cache-Control: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Pragma: no-cache User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36 DNT: 1 Referer: http://local-server.dev/wp-admin/edit.php?s=pos&post_status=all&post_type=post&action=-1&m=0&cat=0&paged=1&mode=list&action2=-1 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8
#4
@
11 years ago
- Component changed from Comments to Administration
- Keywords needs-patch added; 2nd-opinion reporter-feedback removed
- Severity changed from trivial to normal
- Type changed from enhancement to defect (bug)
#5
@
11 years ago
- Milestone changed from Awaiting Review to 3.7
My steps to reproduce
- Comments screen
- Search for "foo"
- Change bulk action to something else then "Bulk Actions" (Don't click Apply)
- Search for "bar"
- Result: The old search value "foo" and bulk action was executed
#8
@
11 years ago
- Keywords has-patch added; needs-patch removed
- Version changed from 3.6 to 3.1
We broke this in [17006] inline-edit-post.js wasn't changed to reflect the new id attribute on the submit button.
#9
@
11 years ago
Same issue on comments list table and media list table. 25034.3 includes fixes for all 3 list table searches.
#10
@
11 years ago
25034.4.patch fixes the search form bug in posts, comments, users, plugins, and media list table search forms.
@
11 years ago
fixes the search form bug in posts if we search by pressing Enter button in search input field.
#11
follow-up:
↓ 12
@
11 years ago
"#post-query-submit" is for the "Filter" box. It seems like inline-edit-post.js handles this currently (as seen in 25034.4.patch) but is it needed? Original report says "Filter menu does not have the same effect."
#12
in reply to:
↑ 11
@
11 years ago
Replying to nacin:
"#post-query-submit" is for the "Filter" box. It seems like inline-edit-post.js handles this currently (as seen in 25034.4.patch) but is it needed? Original report says "Filter menu does not have the same effect."
It's not needed anymore since it's handled in common.js now. revert() was never needed since we are refreshing the page 25034.7.patch removes it.
This is about the Comments screen in the admin, right?
Could not reproduce on a clean install using your description. Could you please add more exact steps to reproduce?