Changes to meta capability handling in 3.1

If you were doing something crazy with custom or metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. capabilities and custom post types in 3.0, you’ll probably want to read #14122.

Custom post types had inconsistent meta capability handling in 3.0. current_user_can( ‘edit_post’, $id ) and current_user_can( $post_type->cap->edit_post, $id ) mapped to different capabilities when capability_type = post. We never called the former in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., however, so this would have only affected plugins in a very particular situation.

Now, we have the map_meta_cap flag for CPTs, which allows this to be throttled properly. map_meta_cap is also true by default if capability_type = post or page, and no custom capabilities were defined.

Making this post out of due diligence, but I don’t think this should break any plugins, except in the “This was never supposed to work” situation (which I do want to know about).

#3-1, #dev-notes