[wp-trac] [WordPress Trac] #48556: Query for multiple post types not considering user permission to retrieve private posts

WordPress Trac noreply at wordpress.org
Tue Dec 15 16:48:31 UTC 2020


#48556: Query for multiple post types not considering user permission to retrieve
private posts
--------------------------------------+-----------------------------
 Reporter:  leogermani                |       Owner:  SergeyBiryukov
     Type:  defect (bug)              |      Status:  reviewing
 Priority:  normal                    |   Milestone:  5.7
Component:  Query                     |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-----------------------------

Comment (by boonebgorges):

 @leogermani Thanks for your patience as I reviewed your PR.

 I stumbled upon this problem separately, when a client reported a problem
 with private posts in certain directories. I tracked it down to a check
 for the (non-existent) `'read_private_anys'` capability, which led me to
 #13509 and #46968. I believe that these bugs have the same root cause as
 the current one, and the proposed approach will fix them all.

 I've attached a new patch [attachment:"48556.2.diff"] which makes a few
 changes:
 - Fixes a bug where certain combinations of query parameters could cause
 the list of 'where' clauses to be empty, resulting in invalid SQL syntax
 of the form `AND ()`.
 - Updates code formatting and variable names. I know you were matching
 existing variable names in other clauses, but they're really difficult to
 understand, so I've tried to make them clearer.
 - Rewritten and relocated the tests, to make them a bit more independent
 of built-in post types and to isolate the capability issue more clearly.

 Have you had a chance to think about backward compatibility concerns? How
 can we summarize the changes to SQL syntax?

 > There's still another case to take care, which is when we also query for
 multiple post statuses. I'm wondering if that will be too much for a
 single diff and maybe it's better to wait for this to move forward and do
 this in a following one. Anyway, I already started looking into it and the
 solution will be similar.

 Could you start by writing tests that describe how this is currently
 broken?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48556#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list