Defining the allow/denylist for meta values

We can retrieve meta values for custom posts, users, comments, and taxonomies (tags and categories), by querying fields metaValue (for a single value) and metaValues (for an array of values) from the corresponding type:

• Post.metaValue
• Post.metaValues
• GenericCustomPost.metaValue
• GenericCustomPost.metaValues
• User.metaValue
• User.metaValues
• Comment.metaValue
• Comment.metaValues
• PostTag.metaValue
• PostTag.metaValues
• PostCategory.metaValue
• PostCategory.metaValues
• GenericTag.metaValue
• GenericTag.metaValues
• GenericCategory.metaValue
• GenericCategory.metaValues

We can also filter results for custom posts, users, comments, and taxonomies (tags and categories) based on meta, via the input field metaQuery.

For both querying and filtering, meta values may be public or private. For instance, user meta includes entry wp_capabilities, which is private, while description is public. And then there is last_name, which may be public or private depending on the application.

The GraphQL API plugin does not impose which meta keys are public and which are private; this must be explicitly configured. By default, the list of allowed meta keys is empty.

Meta value response permalink

When querying for a meta key whose access is not allowed in the corresponding Settings page, then the query returns an error.

For instance, executing this query:

{
  post(by: { id: 1 }) {
    id
    metaValue(key: "nothingHere")
  }
}

Returns:

{
  "errors": [
    {
      "message": "There is no meta with key 'nothingHere'",
      "extensions": {
        "type": "Post",
        "id": 1,
        "field": "metaValue(key:\"nothingHere\")"
      }
    }
  ],
  "data": {
    "post": {
      "id": 1,
      "metaValue": null
    }
  }
}

If the meta key does not exist for the queried object, or its value is empty, the response is null. Otherwise, the response is the meta value.

Configuring the allowed meta keys permalink

This is the description for module "Schema Custom Post Meta". For the Users, Comments and Taxonomies modules, the procedure is similar.

In the "Schema Custom Post Meta" tab from the Settings, we must configure the list of meta keys that can be queried via the meta fields.

Each entry can either be:

• A regex (regular expression), if it's surrounded by /, or
• The full option name, otherwise

For instance, both entries _edit_last and /_edit_.*/ match meta key "_edit_last".

There are 2 behaviors, "Allow access" and "Deny access":

👉🏽 Allow access: only the configured entries can be accessed, and no other can
👉🏽 Deny access: the configured entries cannot be accessed, all other entries can

Share