[wp-trac] [WordPress Trac] #38276: "Is thing public/accessible" API (was: "Is thing public" API)

[WordPress Trac]

#38276: "Is thing public/accessible" API
-----------------------------+------------------------------
 Reporter:  jdgrimes         |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Role/Capability  |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  dev-feedback     |     Focuses:
-----------------------------+------------------------------
Changes (by jdgrimes):

 * keywords:   => dev-feedback


Comment:

 Another benefit of "is accessible" vs just "is public" is that it allows
 for more granular rules in relation to non-logged-in users as well. In
 other words, strictly speaking, if something is public, it is public for
 all non-logged-in users. With an "is accessible for user" API, that
 doesn't have to be the case, the IP of the current non-logged-in user can
 be taken into account, etc. I don't see any reason to arbitrarily restrict
 ourselves to building an "is public" API, when an "is accessible" API can
 be build on the same basic structure but provides many more opportunities
 for usefulness.

 ----

 I think maybe we should think of this ticket more like a "feature project"
 then a regular ticket. When it comes to fleshing out the API in more
 detail, we might indeed want to branch out onto GitHub, and then come back
 here with t he finished patch. First though, I want to get a very basic
 POC up and get a few more eyes on this ticket, to see if others
 (especially committers) feel that it is headed in the right direction.

 ----

 Actually, yeah, I just added a basic POC: [attachment:poc-1.php]. It's
 purpose is just to give something more tangible to help people understand
 what exactly we are talking about here. The final implementation might be
 completely different, but it should ultimately provide the same
 information to anything that calls it: whether the item is accessible to
 the user.

 Notes:

 The logic for posts from `WP_Query` condenses down to be unexpectedly
 simple. The raw logic that would come from `WP_Query` would be more
 complex, looking something like this:

 {{{#!php
 <?php
                 $status = get_post_status( $post_id );
                 $post_status = get_post_status_object( $status );

                 if ( $post_status->public ) {
                         $is_accessible = true;
                 } elseif ( $post_status->protected ) {
                         $is_accessible = user_can( $user_id, 'edit_post',
 $post_id );
                 } elseif ( $post_status->private ) {
                         $is_accessible = user_can( $user_id, 'read_post',
 $post_id );
                 } else {
                         $is_accessible = false;
                 }
 }}}


 The reason for the extra complexity there is that `WP_Query`'s logic
 attempts to take a short-cut by anticipating some of the logic in the
 capabilities API. In other words, instead of just leaving all of the
 handling for non-public post statuses to the capabilities API, it applies
 its own logic intended to be roughly equivalent to what the capabilities
 API would do. This once again demonstrates a lack of unity in the post
 accessibility "API" as it currently stands. Anybody wanting to influence
 that logic has to do so in multiple locations.

 The logic in `WP_Query` is basically equivalent to the ''default logic''
 in `map_meta_cap()`, but there is one difference: if the post's status is
 not `public`, `private`, or `protected`, then it is excluded entirely. In
 `map_meta_cap()` such a post status would be less restricted, defaulting
 to the `read` capability for that post type if the user was the author, or
 `user_can( 'edit_post' )` otherwise. This may be intentional, since
 `WP_Query` does choose to exclude some posts that are otherwise accessible
 to the user, for various reasons (like they aren't intended to be
 searchable in that way).

 (Note that this also brings to light something that might be worth
 considering in building this API, and that is that post accessibility
 doesn't equal post searchability. The post may be accessible to the user
 in general, but that might not mean that it should be made accessible to
 them in every context and by every means. Something to think about.)

 Anyway, in the POC I haven't made any assumptions in regard to the caps
 API like this, but instead fall back on it directly if the post status
 isn't public. I believe that this is the correct behavior, at least in the
 context of this API.

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