Post type objects are reponsible for mapping their capabilities to core caps.
As a result, when the post type is no longer registered, the caps are no
longer mapped. This causes problems when a post is left in the database after
the post type is no longer present, and WP does an 'edit_post' or other cap
check against it: a PHP notice is thrown, and the cap check always fails.
As a more graceful fallback, we map all post-type-dependent caps onto
'edit_others_posts', which allows highly privileged users to be able to
access orphaned content (such as comments belonging to disabled post types),
while minimizing the possibility of unintended privilege escalation.
We also add a `_doing_it_wrong()` notice, so that developers and site
administrators are aware that the cap mapping is failing in the absence of
the registered post type.
Props mitchoyoshitaka, DrewAPicture, imath, codeelite, boonebgorges, nofearinc, SergeyBiryukov, jorbin, dlh.
Fixes#16956.
git-svn-id: https://develop.svn.wordpress.org/trunk@34091 602fd350-edb4-49c9-b593-d223f7449a82
Other users in a network can now be given capabilities to manage users without also having global super admin privileges.
* Users with `manage_network_users` can not edit super admins.
* Users with `manage_network_users` can not promote users to super admin.
* Uses of `is_super_admin()` in `user-new.php` are now updated to `manage_network_users`.
Props daniellandau, chriscct7.
Fixes#16860.
git-svn-id: https://develop.svn.wordpress.org/trunk@33988 602fd350-edb4-49c9-b593-d223f7449a82
Creates:
`class-wp-roles.php`
`class-wp-role.php`
`class-wp-user.php`
`capbilities-functions.php`
`capbilities.php` contains only top-level code. Class files only contains classes. Functions file only contains functions.
See #33413.
git-svn-id: https://develop.svn.wordpress.org/trunk@33752 602fd350-edb4-49c9-b593-d223f7449a82
