[wp-trac] [WordPress Trac] #38276: "Is thing public" API
WordPress Trac
noreply at wordpress.org
Mon Oct 10 20:45:09 UTC 2016
#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
More information about the wp-trac
mailing list