wp-includes/class-wp-view-config-data.php:135Applies the entity view configuration filter and returns the result.
$kindstring$namestringarrayOne hook fires while WP_View_Config_Data::apply_filters() runs, in this order:
Filters the view configuration for a given entity.
public function apply_filters( $kind, $name ) { /** * Filters the view configuration for a given entity. * * The dynamic portions of the hook name, `$kind` and `$name`, refer to the * entity kind (e.g. `postType`) and the entity name (e.g. `page`), * lowercased — so the `postType`/`page` entity maps to the * `get_entity_view_config_posttype_page` hook. * * Callbacks receive a WP_View_Config_Data object and change the * configuration through its methods. Each write method takes the schema * version the change was authored against as its second argument, * and returns the object for chaining: * * - `merge( $patch, $version )` merges a partial change into the current * configuration. It touches only the top-level keys the patch names, and * merges each named value into the current one by shape: a scalar * replaces, an associative array merges key by key, and a list merges by * member identity (`id`, `slug`, or `field`). A `null` value drops the * key it names, resetting it to its default. * - `replace( $patch, $version )` applies a patch exactly like `merge()`, * but swaps any list it names wholesale instead of merging that list by * member identity. * - `set( $patch, $version )` also touches only the keys the patch names, * but swaps each named value in wholesale, dropping whatever the key held * before — for a callback that owns those keys outright. * - `remove( $spec, $version )` deletes named properties. The spec mirrors * the configuration shape: a list of names deletes entries at that level, * and a nested map recurses to prune from within a named value, down to * individual list members. * * A change that declares an unsupported schema version is rejected and does * not alter anything. As with any filter, each callback's return value is * passed to the next callback as `$data`, so callbacks must return the * container they received: a callback that returns nothing, or any other * value, hands that result to every callback hooked at a later priority * instead of the container. Since the write methods return the container, * a callback can end with `return $data->merge( $patch, $version );`. * * @since 7.1.0 * * @param WP_View_Config_Data $data The view configuration container * for the entity, exposing the * `default_view`, `default_layouts`, * `view_list`, and `form` keys. * @param array $entity { * The entity the configuration is built for. * * @type string $kind The entity kind. * @type string $name The entity name. * } */ apply_filters( wp_get_entity_view_config_hook_name( $kind, $name ), $this, array( 'kind' => $kind, 'name' => $name, ) ); // Discard any keys the filter introduced that are not part of the // documented configuration shape. return array_intersect_key( $this->get_data(), array_flip( self::CONFIG_KEYS ) ); }Introduced in 7.1.0.
Signature, return type and hooks compared across 1 parsed release.
src/wp-includes/class-wp-view-config-data.php, and regenerated for each WordPress release so it tracks the code rather than a snapshot of it.