WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#13358 closed defect (bug) (fixed)

Switch post type and tax capabilities to a single 'cap' property

Reported by: nacin Owned by:
Milestone: 3.0 Priority: normal
Severity: normal Version:
Component: Role/Capability Keywords:
Focuses: Cc:

Description

Like what we're doing in #12968 and #13357 with labels.

Thus:

$pt->cap->edit_post
$pt->cap->edit_posts
$pt->cap->edit_others_posts

Etc.

By basing them off what they are called for posts, we reduce confusion significantly (it's also the default) and we prevent errors like [13955] which caused quite a headache, and MarkJaquith and I spent maybe an hour tracking that down.

Patches welcome, otherwise I'll get to it.

Change History (7)

comment:1 @nacin5 years ago

(In [14584]) Use correct cap check. see #13358.

comment:2 @nacin5 years ago

(In [14585]) Move post type object capabilities to a 'cap' object. Allow them to be initialized via the 'capabilities' key (an array) when registering support for the post type. Caps are now referred to by the name of the cap as if it was a post, i.e. ->cap->edit_post. see #13358.

comment:3 @nacin5 years ago

(In [14587]) Fix typos. see #13358.

comment:4 @nacin5 years ago

(In [14588]) More typos. see #13358.

comment:5 @nacin5 years ago

(In [14589]) Unset capabilities property when we're done. see #13358.

comment:6 @nacin5 years ago

If someone wants to take this up for taxonomies, please do.

comment:7 @nacin5 years ago

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

(In [14593]) Move taxonomy object properties for capabilities into a cap object. Capabilities can be specified via capabilities? (an array keyed by the generic cap name) for register_taxonomy. fixes #13358.

Note: See TracTickets for help on using tickets.