[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):

 Replying to [comment:6 PieWP]:
 > Replying to [comment:5 jdgrimes]:
 > > Unless of course we add more read-type caps to capability API for
 other objects. But honestly I don't know that we want to encourage that.
 >
 > The first thing people will ask (once {{{is_post_accessible()}}} is
 introduced) will be: why can't I do this for terms/taxonomies?So let me
 ask the question in advance: Why would it make sense to hide a post but
 not to hide a term?

 I agree with this, though I haven't been entirely sure that this ticket
 should go whole-hog or whether that would be biting off more that anybody
 is willing to chew (I'm thinking more and more that we should though).

 My point in that particular quote though, was more that I question whether
 the ''capability API'', specifically, is really a good fit for
 ''visibility restrictions''. As opposed to this proposed API, which is
 somewhat separate. Because visibility restrictions are things that we want
 to check against non-logged-in users, and the capability API has no
 application to non-logged-in users. So although the two currently
 intersect with the post statuses and `read_post`, I'm not sure that this
 is a pattern that we want to start using for other objects, or whether
 going forward it would be better to keep the capabilities solely about
 what somebody is allowed to ''do'', and the accessibility API proposed
 here deal with what one is allowed to ''see''.

 Although, that does make me wonder whether some "can user ''do''" checks
 couldn't possibly relate to non-logged-in users as well (in other words,
 some ''actions'' can be public just as some objects can). But as I said in
 the OP, changing the capabilities API as a whole to apply to non-logged-in
 users would probably break too much stuff. I dunno though, maybe that
 angle should be explored more as well.

 > ''Please note I'm not trying to bash by questioning everything, just
 really want this feature to be introduced. My daily work involves making
 business portals based on WP so features like this are quite handy.''

 No worries, I really appreciate your input. :-)

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