Changes between Initial Version and Version 1 of Ticket #40922, comment 20
- Timestamp:
- 08/24/2017 08:30:10 AM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #40922, comment 20
initial v1 7 7 The reason I like this approach is that it's simpler than yet another clause in `map_meta_cap()`, and it's much easier to adjust. If I want to give users this capability directly (as a primitive cap) in my custom setup, all I need to do is remove the filter hook. If it happens in `map_meta_cap()`, I need to use the filter there to override the default way with custom logic, which is much more involved. 8 8 Another reason is that I consider `map_meta_cap()` mainly useful for mapping actual meta capabilities (like singular capabilities for one object to more general plural capabilities): Things like `edit_customize_changesets` (and even `customize` although it's currently part of `map_meta_cap()`) are in my opinion primitive capabilities, and the only reason we don't treat them as such is that we can't just add new primitive capabilities in WordPress because of all the database migration that would require. In other words, if we had known from the beginning of core development about these capabilities, they would live in the database alongside the others. Therefore adding these capabilities through the `user_has_cap` filter makes more sense to me because that actually filters the data as if the user had these capabilities as primitive ones. If that makes sense. That's obviously just my POV. 9 10 To clarify my above thoughts: Every capability that is a general/plural capability and only maps to one other capability without any further conditions should not be in `map_meta_cap()` I think. Examples for this are `add_users`, `manage_post_tags`, `edit_categories`, `edit_post_tags`, `assign_categories`, `customize`, ... 11 Of course we won't be able to change all these, just wanna explain my thoughts.