[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