Justin Tadlock 8 months ago No, they are not harmful by just existing. Technically, capabilities only exist if they are assigned to at least one role. Otherwise, unless the capability is registered via a custom post type, a custom taxonomy, or by utilizing Members’ cap registration API, Members won’t display it. Now, Members does back up all of core WP’s capabilities in case someone removes one from all of their roles. So, those won’t disappear. Basically, what I’m getting at is that in order to get rid of these residual caps, you must remove them from any roles that have them (if they’re no longer registered). Side note: At some point, I’d like to build a capability manager to make it easier to just remove a cap from all roles. I’ve attempted it before but struggled with getting some of the nuances of the user interface in place for such a feature. As for the differences between primitive and meta capabilities: Primitive capabilities are caps that you assign to roles. These determine whether a user can or cannot do something. Meta capabilities are not assigned to roles. On their own, they do not give permission to do stuff. They’re handled dynamically based on a given object (post, taxonomy term, user, etc.). Depending on the scenario, a meta cap is “mapped” to one or more primitive capabilities to determine whether a user has permission to do something. For example, we might check a meta cap with current_user_can( 'edit_post', $post_id ). WP would run that through a series of checks to determine if you have the right caps. Assuming you’re the post author and the post is published, it’d map edit_post to the edit_posts and edit_published_posts primitive caps. These would then be used to do the actual permission checks.