[wp-trac] [WordPress Trac] #38221: Incorrect page id/name search blocks future searches
WordPress Trac
noreply at wordpress.org
Wed May 27 21:46:06 UTC 2020
#38221: Incorrect page id/name search blocks future searches
----------------------------------+----------------------------------------
Reporter: bencroskery | Owner: tomdude
Type: defect (bug) | Status: assigned
Priority: normal | Milestone: 5.5
Component: Media | Version: 4.4.2
Severity: normal | Resolution:
Keywords: has-patch 2nd- | Focuses: accessibility, javascript
opinion |
----------------------------------+----------------------------------------
Changes (by afercia):
* keywords: good-first-bug has-patch commit => has-patch 2nd-opinion
Comment:
Thanks for the patches. Looking a bit into this, I'm not sure I understand
what is the scenario where, using the admin interface, parameters like
`?p=123` or `?name=noexist` get added to the query string. Maybe I'm
missing something but I couldn't find such a case.
Appending manually random parameters may break many other admin screens as
well. Clarifying whether there are actual cases where these parameters are
added while using the UI may help. Otherwise I'm not sure this can be
considered an real bug.
Regardless, I'm not sure it should be fixed on the JavaScript side. The
root cause of this odd behavior is that there are multiple "submit"
buttons in the same form element, e.g.:
- the "Filter" button
- the "Select" button inside the "Attach to existing content" modal
dialog: though it's visually hidden and appears only when clicking the
"attach" link, it's in the same form and brings some JavaScript into play
When manually appending `?p=123` or `?name=noexist`, the "Filter" button
is not printed out. Thus, the "Select" button is the one that browsers
consider the form submit button and triggers a click event when submitting
a search by pressing Enter in the search field. The "Select" button has
some JavaScript that prevents the default action when none of the radio
buttons representing the posts within the modal is checked so the search
submission is prevented.
A more proper fix would be making sure the "Filter" button is always
printed out. It isn't because the `! is_singular()` check originally
introduced in [7251] fails: this is very old code and I'm not sure I
understand whether it still needs to be there.
Worth noting this may happen also on other list tables where the same `!
is_singular()` check is used, it would just need a URL parameter that
makes WP_Query consider the page as `singular`.
I'd like to ask for a second opinion from some experienced contributor
with some historical knowledge of this `! is_singular()` conditional
implementation.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/38221#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list