[wp-trac] [WordPress Trac] #32073: Undefined offset: 0 warning in wp-includes\capabilities.php on line 1119

[WordPress Trac]

#32073: Undefined offset: 0 warning in wp-includes\capabilities.php on line 1119
--------------------------+----------------------
 Reporter:  hubertnguyen  |       Owner:
     Type:  enhancement   |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  General       |     Version:  4.1.1
 Severity:  normal        |  Resolution:  wontfix
 Keywords:  has-patch     |     Focuses:
--------------------------+----------------------
Changes (by boonebgorges):

 * status:  new => closed
 * resolution:   => wontfix
 * milestone:  Awaiting Review =>


Comment:

 Is there any use of `current_user_can()` in WP core that causes these
 notices to be thrown? A glance through the codebase suggests that WP is
 always passing a post ID for these cap checks, which means that `$args[0]`
 will always be set.

 I think we should close as wontfix. If no post ID is explicitly passed to
 `current_user_can()`, it happens to be the case that we fall back on
 `get_post( null )`. However, this is bad practice.  Singular, mapped cap
 checks should always be performed against specific posts. Using
 `current_user_can( 'delete_post' )` as shorthand for `current_user_can(
 'delete_post', $GLOBALS['post']->ID )` is bound to cause developers to
 introduce permissions-related bugs, because the contents of the `$post`
 global can vary oddly in secondary queries, nested queries, and outside
 the post loop. The PHP notice that is being reported in this case should
 act as a warning to plugin devs to be more specific.

 If anyone can point to a place in WP where we're not passing a post_id to
 one of these cap checks, please feel free to reopen with details.

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