[wp-trac] [WordPress Trac] #38276: "Is thing public/accessible" 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:  4.7
 Severity:  normal           |  Resolution:
 Keywords:  dev-feedback     |     Focuses:
-----------------------------+------------------------------

Comment (by jdgrimes):

 [These were notes I had written down soon after the OP, and just never
 posted them.]

 Replying to [comment:9 jdgrimes]:
 > (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.)

 Thinking more about this, anything that hooks into the API could base
 whether something is accessible on the current application state, of
 course. But that is different than knowing exactly what context the
 accessibility check is in reference to. In other words, are we checking:

 - whether the user can view the post,
 - whether they can view the post in the admin,
 - or whether they can view the post in a particular list table in the
 admin (for example)?

 The basic API I've been envisioning here is mainly about that first, most
 general case. The second case could also in theory be implemented with it
 as well, in the sense that a different result could be returned based on
 `is_admin()` or other things relating to application state. The problem is
 when we get into more granular checks like the third case, where what
 particular context we are going to display the item in may or may not be
 apparent just from the current application state.

 Of course, individual contexts in which an item is displayed can provide
 their own method of letting something hook in and affect whether an item
 should be displayed in that context.

 I guess that really, this would be starting to intersect whether a user
 can view something with whether it is supposed to be displayed. Which are
 really two different things.

 ----

 In regard to attribute visibility, one of the use-cases I was thinking of
 was when plugins provide shortcodes that are used in post content that
 hide all or most of the context. However, when they only hide part of the
 content, things become more complex.

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