Rebuild post type meta capabilities when unregistering a post type

[westonruter]

unregister_post_type() removes entries from the global $post_type_meta_caps list by subtracting every value of the post type's own $cap object. That list is keyed by custom capability name and is shared by every post type resolving to the same name, so the subtraction deletes mappings that other, still-registered post types depend on.

Once a mapping is gone, map_meta_cap() stops translating the meta capability into contextual primitives and returns it verbatim. The ownership and post-status checks (edit_others_*, edit_published_*, edit_private_*) do not become stricter, they disappear from the result entirely, so a post's own author can lose edit access to it.

The full analysis, including three distinct defects and a reproduction script, is in Core-66008.

The fix

Subtraction cannot work against a shared list: an entry may be owed to any number of registered post types, and nothing records which ones. Rather than reference-count the entries, the list is rebuilt from the post types that remain.

The cleanup is removed from WP_Post_Type::remove_rewrite_rules() entirely, leaving that method to do only what its name says, and the rebuild happens in unregister_post_type() once the post type has been removed from $wp_post_types. Placement matters: remove_rewrite_rules() is called several lines before that unset(), so a rebuild performed from inside it would still see the post type being removed.

Rebuilding rather than subtracting fixes all three defects at once, because it inherits the rules of _post_type_meta_capabilities() instead of trying to invert them. Entries are written only for post types with map_meta_cap => true, only for the three meta capabilities, and an entry shared by several post types survives as long as any one of them is still registered.

Removing the loop also empties tests/phpstan/baselines/foreach.nonIterable.neon, so that baseline and its includes entry in phpstan.neon.dist are deleted here too. This supersedes #13079, which proposed silencing that baseline entry with a type cast.

Tests

Four tests in tests/phpunit/tests/post/types.php, one per defect plus a functional one. Each was confirmed to fail before the fix, on an assertion after the unregistration rather than during setup:

1) ..._retains_meta_capabilities_shared_with_another_post_type      Undefined array key "read_publication"
2) ..._retains_meta_capabilities_when_not_mapping_meta_caps         Undefined array key "read_post"
3) ..._retains_meta_capabilities_matching_primitive_capabilities    Undefined array key "edit_book"
4) ..._retains_meta_capability_mapping_for_another_post_type
       -    0 => 'edit_published_publications'
       +    0 => 'edit_publication'

--group post (951 tests) and --group capabilities (789 tests) both pass.

Notes for review

The $capabilities map handed to _post_type_meta_capabilities() comes from WP_Post_Type::$cap, a bare stdClass that carries no property types. PHPStan types get_object_vars() on any object as array<mixed> regardless of how the object is documented, so the call reports an argument.type error at higher rule levels even though the values are always strings at runtime. Narrowing the map at runtime or relaxing what the function documents would both be worse; typing $cap well enough for the analyzer to follow is separate work, tracked in Core-64898.

WP_Post_Type::remove_rewrite_rules() is public, so moving the cleanup out of it is technically a behavior change for any caller invoking it directly. A search of public GitHub for remove_rewrite_rules() returns only vendored copies of core's own post.php, taxonomy.php and the two class files, with no third-party call sites at all.

Some accompanying documentation fixes to _post_type_meta_capabilities(), each in its own commit: r36316 removed the branch that returned the list when the function was called with no arguments, but left behind the null default and a summary describing that return value.

Trac ticket: Core-66008
Trac ticket: Core-65817

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Opus 5
Used for: Investigating the defect and its history, drafting the fix and its tests, and drafting the Trac ticket. The approach, the final implementation and the tests were reviewed, revised and are owned by me.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props westonruter.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[dmsnell]

what are the implications here for registering a post type? does this go both-ways, where something gets potentially overwritten that shouldn’t be?

[westonruter]

Looking at how this works…

When register_post_type() is called during init, it constructs a WP_Post_Type. The constructor will call WP_Post_Type::set_props() which in turn calls get_post_type_capabilities(). This get_post_type_capabilities() function will also call _post_type_meta_capabilities() if map_meta_cap is true, which results in $post_type_meta_caps being populated. So the end result with just register_post_type() being called multiple times is the $post_type_meta_caps being rebuilt from scratch in the same way as this is being done here when one of the post types is unregistered.