apply_filters( "{$kind,}", WP_View_Config_Data $data, array $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: <ul> <li>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.</li> <li>replace( $patch, $version ) applies a patch exactly like merge(), but swaps any list it names wholesale instead of merging that list by member identity.</li> <li>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.</li> <li>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.</li> </ul> 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-&gt;merge( $patch, $version );.