Add extensibility filters to ContentPicker and ContentSearch components

[s3rgiosan]

Description of the Change

This PR introduces four new JavaScript filters to the ContentPicker and ContentSearch components, enabling developers to extend queried fields and customize UI display to better meet client requirements.

This approach:

• Reduces custom component development time on client projects
• Improves content editor experience with relevant contextual information
• Maintains backward compatibility with existing implementations
• Flexible filter system accommodates various client requirements

Problem

Client projects frequently require additional information beyond the default fields (title, URL) when picking or searching content. Common requests include displaying post IDs, parent page titles, or custom metadata to help content editors make informed selections.

Solution

Added filters that allow developers to:

1. Query additional fields from WordPress REST API endpoints
2. Customize the display of picked items and search results
3. Remove unnecessary information (like URLs) when not needed by editors

New Filters

ContentPicker

• tenup.contentPicker.queryFields - Extends fields queried from core WP REST endpoints

addFilter(
    'tenup.contentPicker.queryFields',
    'fooBar/contentPickerQueryFields',
    ( fields, mode ) => {
        if( mode === 'post' ) {
            fields.push('excerpt');
        }
        return fields;
    }
);

• tenup.contentPicker.pickedItem - Customizes picked item UI display

addFilter(
    'tenup.contentPicker.pickedItem',
    'fooBar/contentPickerPickedItem',
    ( item, result ) => {
        const info = `<strong>ID:</strong> ${result.id}<br>${result.excerpt.rendered}`;
        return {...item, url: '', info };
    }
);

ContentSearch

• tenup.contentSearch.queryFields - Extends search query fields (requires PHP companion filter)

addFilter(
    'tenup.contentSearch.queryFields',
    'fooBar/contentSearchQueryFields',
    ( fields, mode ) => {
        if( mode === 'post' ) {
            fields.push('excerpt');
        }
        return fields;
    }
);

Additionally in PHP:

function add_search_result_field() {
    register_rest_field(
        'search-result',
        'excerpt',
        array(
            'get_callback'    => function ( $post ) {
                return get_the_excerpt( $post['id'] );
            },
            'update_callback' => null,
            'schema'          => null,
        )
    );
}
add_action( 'rest_api_init', __NAMESPACE__ . '\add_search_result_field' );

• tenup.contentSearch.searchResult - Customizes search result display

addFilter(
    'tenup.contentSearch.searchResult',
    'fooBar/contentSearchSearchResult',
    ( item, result ) => {
        item.url = '';
        item.info = `<strong>ID:</strong> ${result.id}<br>${result.excerpt}`;
        return item;
    }
);

How to test the Change

1. Create a test WordPress environment with the updated block components
2. Add the example filters to your theme's JavaScript
3. For ContentSearch, add the PHP example to register additional fields
4. Test ContentPicker component:

• Verify additional fields are queried from REST API
• Confirm picked items display custom information
• Check that URL field can be hidden when set to empty string

5. Test ContentSearch component:

• Verify search results include additional queried fields
• Confirm search result display matches custom formatting

6. Verify no regressions in existing functionality without filters applied

Changelog Entry

Added - New JavaScript filters for ContentPicker and ContentSearch components to extend queried fields and customize item display

Credits

Props @s3rgiosan

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added Critical Flows, Test Cases, and/or End-to-End Tests to cover my change.
• All new and existing tests pass.

[s3rgiosan]

cc @rickalee @benlk @PypWalters @barryceelen

[s3rgiosan]

Merge conflicts were addressed. This is ready for review.

[fabiankaegy]

Lets use https://github.com/WordPress/gutenberg/tree/de11ef92c9f6478fedb7bd5f56b1612943d5c7a9/packages/dom#safehtml instead to avoid the additional dependency

[fabiankaegy]

I'm a little worried about the introduction of all these filters... Unlike in PHP here in JS they just behave oddly and are no longer really recommended by the core team...

Also I am a bit worried that there is no way to figure out the context of which component we are talking about. It just applies to all ContentSearch components on the site.

I would rather see an implementation that has the filters needed within the content connect plugin and then passes its callback function into the component as an optional prop. That feels more "safe" to me here.