Introduce singular capabilities for managing individual sites on a network

[johnbillion]

As we did in #35614 for taxonomy terms, singular capabilities should be introduced for editing and deleting individual sites on a network.

This would allow fine-grained cap checks such as current_user_can( 'edit_site', $site_id ).

Bear in mind there's a potential clash here with the existing delete_site capability which is intended as a cap check for site admins to delete their own site. Needs some thought.

[flixos90]

39156.diff​ is an initial proposal for this:

• It introduces two main capabilities edit_site and delete_site which require passing a site ID. The latter is not actually new, but has been revamped: delete_site in the patch solely denotes actually deleting a site, not deactivating it (it currently accounts for both which is not very accurate). edit_site by default maps to manage_sites while delete_site maps to delete_sites.
• To adjust the site status, new capabilities archive_site, spam_site, activate_site and mature_site are introduced which all map to manage_sites by default.
• The map_meta_cap() functionality for all of these checks if the passed ID represents an existing site. For archive_site, spam_site, activate_site and delete_site it also checks if that site is not the network's main site.
• For the one special use-case where a regular site administrator can deactivate their own site (actually it only deactivates the site, but the site admin is told that it is deleted, which I think we should continue to do so at this point), a new capability delete_admin_site is introduced. I don't like that name at all, so let's definitely find a more suitable one. The reason I'm not using something like deactivate_site or delete_site (which it uses currently in trunk) is that this use-case is different as everything else is by default only available to the network administrator.
• Minor tweak not directly related: I adjusted a manage_sites check in wp-admin/network/site-new.php to use create_sites instead for more granular permissions.

The patch should be backward-compatible, but please review in detail, I might certainly have missed something. What we need to think about is how the new delete_admin_site (or whichever name we use) should be handled. The current delete_site does not make sense there at all in my opinion, but we might need to scrape some plugins to check whether anything does something custom with it (like specifying do_not_allow for it, in which case we need to somehow adjust the patch so that the new capability somehow maps to delete_site without being passed a site ID.

[flixos90]

I remembered there was already a similar ticket, however with a different approach: #36940

[flixos90]

While this ticket was opened after #36940, it looks at site capabilities in a more global scope. Therefore I think we should close the other ticket and integrate its request and discussion here. I fully agree with the changes proposed in that ticket, it makes sense to deal with the capability changes in one ticket and one discussion IMO.

To summarize the other ticket: In addition to the capabilities introduced in 39156.diff​, we also need individual capabilities for the individual tabs manage_site_info, manage_site_settings, manage_site_themes and manage_site_users. To be backward-compatible, we need to map all of these to the new manage_site / edit_site capability by default. Regarding the name of that capability: in the patch I used edit_site, but I now lean more towards using manage_site in agreement with the other ticket. This is what other names for network capabilities follow, so I think we should rather align naming with these instead of other non-network object capabilities (like edit_post).

For more background, please read the discussion in #36940.

[flixos90]

Based on the discussion on the two tickets, I would like to give an updated summary of what I suggest to do here:

• introduce capability manage_site and map it to manage_sites
• revamp the capability delete_site (only use it for actual deletion, not deactivation) and map it to delete_sites
• introduce capabilities manage_site_settings, manage_site_themes and manage_site_users and map them to the new manage_site; I think instead of introducing manage_site_info we should rely on manage_site for that tab
• introduce capabilities archive_site, spam_site, activate_site (this is now for site (de-)activation) and mature_site and map them to the new manage_site
• for the one case where a site administrator can deactivate their own site, I think we should use the new activate_site capability and in its map_meta_cap() clause map to manage_options if the current user is a user on that site (from the site admin panel we would pass the site ID simply via get_current_blog_id())

All the capabilities mentioned above (except the existing manage_sites obviously) should be passed a site ID.

What we need to do as well is figure out in which areas of core such capabilities could apply. I already noticed a few areas for archive_site, spam_site, activate_site and mature_site that I missed in 39156.diff​.

I will create an updated patch with these changes soon. Feedback on this take on the new capabilities is much appreciated. :)

[johnbillion]

In 40433:

Networks and Sites: Correct a capability check when accessing the Sites -> Add New screen.

Props flixos90

See #39156

[flixos90]

All of these are part of a larger goal.