Feature: Add read_post_meta capability.

[Debarghya-Banerjee]

Trac Ticket : Core-29786

Description:

• This pull request addresses the need for more granular control over metadata access in WordPress by introducing the read_post_meta capability. Currently, the existing capabilities for editing, deleting, and adding post metadata (edit_post_meta, delete_post_meta, and add_post_meta) do not provide a mechanism to determine if specific metadata keys can be accessed publicly.

Problem Statement

• The current implementation relies on the is_protected_meta function, which only checks if a meta key is prefixed (usually with an underscore). This does not adequately control access permissions for individual metadata keys, as it lacks the flexibility to allow or deny access based on custom conditions. Consequently, metadata that should be exposed publicly may inadvertently remain restricted, leading to potential issues with transparency and accessibility.

Proposed Solution

• The proposed implementation introduces the read_post_meta capability, allowing developers to define access permissions for specific metadata keys. This new capability utilizes filters to assess whether a user has permission to read a given meta key associated with a post. It checks the following:

  • Ensures that the requested post exists and is accessible.

  • Validates the post type and its associated capabilities.

  • Applies filters for individual meta keys, providing a flexible and extensible mechanism to control access.

  • This enhancement not only adheres to WordPress coding standards but also promotes better security practices by allowing more nuanced permissions for accessing metadata.

Impact

• Improved Access Control: The ability to control access to individual metadata keys enhances security and flexibility in handling metadata.

• Customizability: Developers can leverage the provided filters to implement custom permission checks tailored to their specific use cases.

• Consistency: This approach aligns with existing capabilities in WordPress, ensuring a cohesive experience for developers.

• Public Data Exposure: The implementation facilitates safe exposure of necessary metadata while restricting access to sensitive information.

This pull request is a step toward making metadata handling more robust and user-friendly in WordPress, fostering a more secure environment for managing and exposing post metadata.

[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 debarghyabanerjee.

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

• The Plugin and Theme Directories cannot be accessed within Playground.
• 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.