Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#14998 closed enhancement (wontfix)

Allow WP_User->has_cap() to accept TRUE or FALSE as capability

Reported by: coffee2code Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.0.1
Component: Role/Capability Keywords: has-patch
Focuses: Cc:


It would be handy (and in some instances potentially eliminate some redundancy) if WP_User->has_cap() could be made to immediately return TRUE or FALSE if passed a boolean as the capability. The primary use case for this is for invoking the various menu-adding functions (add_menu_page(), add_submenu_page(), etc) after having determined the current user already has sufficient capabilities to view the menu. In such cases, we can bypass any further capability checks and simply pass TRUE or FALSE as the capability.

A simplistic example:

   if ( current_user_can( 'manage_options' ) ) {
      add_options_page( 'My Plugin', 'Item A', 'manage_options', 'my-plugin-a', array( &$this, 'my_menu_a' ) );
      add_options_page( 'My Plugin', 'Item B', 'manage_options', 'my-plugin-b', array( &$this, 'my_menu_b' ) );
      // do some other stuff here for someone with 'manage_options' capabilities

In the above, the current user is being checked three times for the 'manage_options' capability. With the attached patch applied, it'd be:

   if ( current_user_can( 'manage_options' ) ) {
      add_options_page( 'My Plugin', 'Item A', true, 'my-plugin-a', array( &$this, 'my_menu_a' ) );
      add_options_page( 'My Plugin', 'Item B', true, 'my-plugin-b', array( &$this, 'my_menu_b' ) );
      // do some other stuff here for someone with 'manage_options' capabilities

The patch should allow for a boolean to be specified as a capability in any capability-accepting function. If true or false is a capability (or in the list of capabilities), then has_cap() will return that boolean without further capability checking. In the event a capabilities array contains both, false takes precendence over true (err on the side of restriction rather than permission).

Patch attached.

Attachments (1)

14998.diff (621 bytes) - added by coffee2code 10 years ago.
Aforementioned patch.

Download all attachments as: .zip

Change History (4)

10 years ago

Aforementioned patch.

#1 @hakre
10 years ago

I think that introduces bugs as it can differ on runtime. You seem to have a faible to overload function arguments, but I don't think that this is helpful generally.

Probably the information stored with the menu elements which capabilities are needed will be executed for other users as well which would return true for them even if they don't have the needed capability. That could be somehow dangerous and hard to debug.

#2 @markjaquith
10 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Cap checks are very fast.

#3 @nacin
10 years ago

  • Milestone Awaiting Review deleted

Agreed. This leaves room for error.

Note: See TracTickets for help on using tickets.