WP_View_Config_Data::apply_filters( string $kind, string $name ): array

Applies the entity view configuration filter and returns the result.

Description

Exposes the container through the dynamic get_entity_view_config_{$kind}_{$name} filter (with the dynamic portions lowercased), so that core and third parties can provide the configuration for a specific entity, then reconciles the filtered container back into a plain configuration array, limited to the documented configuration keys.

Parameters

$kindstringrequired
The entity kind (e.g. postType).
$namestringrequired
The entity name (e.g. page).

Return

array The filtered configuration, limited to the documented keys.

Source

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 ) );
}

Hooks

apply_filters( “{$kind,}”, WP_View_Config_Data $data, array $entity )

Filters the view configuration for a given entity.

Changelog

VersionDescription
7.1.0Introduced.

User Contributed Notes

You must log in before being able to contribute a note or feedback.