[wp-trac] [WordPress Trac] #38276: "Is thing public" API

[WordPress Trac]

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

Comment (by jdgrimes):

 Another thing that I'm ''not'' proposing we do here is change the
 blacklist-style philosophy of WordPress where everything is public by
 default, unless restricted. I'd just like to see us centralize the code
 that restricts things from being visible, so that plugins can more easily
 check that.


 ----

 I should note that the `read` capability is sort of an outlier in the caps
 API. All of the other core capabilities, as far as I can tell, are related
 create/update/delete user actions. It is only with posts that the
 capability API intersects with object visibility.

 Again, I'm not trying to change that with this ticket, but I do wonder
 whether long-term we should reconsider whether the `read` capability
 should be a capability at all. Of course, an API like the one proposed
 here would have to exist before the `read` capability could ever be
 deprecated or anything like that, much less removed. This ticket ''could''
 be a first step in that direction. But again, it doesn't have to be, I
 guess.

 ----

 To fill in some more detail about what I envision in the
 `is_thing_accessible()` function, when I first created this ticket I was
 envisioning it as accepting an object ID (and I guess what type of object
 it was, though I left that out of the example function signatures given).
 Possibly then it would just wrap a filter, passing it these arguments and
 filtering whether the object was accessible, which would be `true` by
 default. Then the restrictions for each object type would be provided by
 hooking into this filter.

 Now, when I created the ticket, I was kind of envisioning the
 `is_thing_accessible()` function automatically working based on the
 current user, kind of as a direct complement to `current_user_can()`. So
 it would also grab the current user and also pass that in to the filter.
 The `is_thing_accessible_for_user()` would then compliment the
 `user_can()` function, as it were, and allow you to pass the user ID in.

 Just now though, I was wondering whether that is the correct approach. I
 suppose that really the user is irrelevant if we are just checking whether
 the object is public. If the object is public, then that means anyone can
 view it. It doesn't matter who the user is. So if we limit the API to only
 check if the object is totally public, the current user shouldn't be taken
 into account.

 In that case the API would compliment the capability API by providing a
 way to check if something is publicly visible to non-logged-in users, but
 might not actually replace the `read` capability, because it wouldn't
 provide granular checks for different roles/capabilities of logged-in
 users. And I suppose that maybe that is only right.

 So in other words, this would be practical logic:

 {{{#!php
 $can_view = (
     is_thing_public( 'post', $post_id )
     || ( is_user_logged_in() && current_user_can( 'read_post', $post_id )
 )
 );
 }}}

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