Don't retrieve the post type object for checking post meta capabilities

[ocean90]

Previously: #23226

There are a few places in core where get_post_type_object( $post_type )->cap->edit_post is used for a capability check. This is not required because map_meta_cap() does actually the same for meta caps.

Trac ticket: https://core.trac.wordpress.org/ticket/50128

[peterwilsoncc]

I'm genuinely not sure if this is correct but happy to defer to someone with a greater knowledge of roles and caps.

When registering a custom post type with a custom capability, the edit, read and delete post meta capabilities are mapped to the custom capability in ​get_post_type_capabilities.

When using custom caps, the developer is responsible for mapping any meta caps alongside giving appropriate roles the primitives.

For example registering the CPT:

<?php

register_post_type (
  'ocean'
  [
    'capability_type' => 'ocean',
    'public' => true,
  ]
);

Will result in the capabilities:

Meta:

• edit_ocean
• delete_ocean
• read_ocean

Primitive:

• edit_oceans
• edit_others_oceans
• delete_oceans
• publish_oceans
• read_private_oceans

In Core, most built-in post types are mapped to post for meta caps but, if my understanding is correct, the PR as is will certainly have adverse affects on the REST endpoints for CPTs.

[ocean90]

@peterwilsoncc I might be missing something but why are the REST endpoints different from wp-admin?

[peterwilsoncc]

@ocean90 I checked out the code, you're right this can be made safely.

The additional checks that are run (ensuring the post type is registered and ensuring revisions use the parent's post caps) won't adversely affect the existing checks. This applies for the read, edit and delete meta caps.

[ocean90]

In 47850:

Role/Capability: Use meta caps edit_post, read_post, and delete_post directly.

Rather than consulting the post type object, let map_meta_cap() handle that for us.

Props peterwilsoncc, ocean90.
Fixes #50128.
See #23226.