Introduce filter to modify/override attributes returned by `wp_get_loading_optimization_attributes()`

[flixos90]

The wp_get_loading_optimization_attributes() function introduced in 6.3 (see #58235) provides a central place to get loading optimization attributes for specific elements/tags.

Currently, it is impossible for plugins to customize that logic, which is a limitation given that plugins may use alternative ways that e.g. can predict in-viewport elements or the LCP element more reliably than WordPress core.

A filter should be introduced that allows to change the returned attributes: Either before returning the attributes array, or alternatively as a short-circuit filter - or potentially both? Let's discuss.

This ticket's implementation should be considered blocked by #58891 as making the changes before that would be unnecessarily complicated and error-prone.

[joemcgill]

I noted a similar thing in #58895. Should we consolidate these two tickets, or focus mine on the specific rendered markup functions called in wp_filter_content_tags()?

[flixos90]

With [56347] committed, this effort is now unblocked. Please refer to the latest codebase for any changes to wp_get_loading_optimization_attributes().

[pereirinha]

@flixos90

I think both filters make sense, as there are valid use cases for both.

Someone might want to implement its custom logic for the optimization attributes — a short circuit early access is ideal as it prevents running lots of code that won't be needed — others just tweak one of the values — so the later, the better.

If we agree, I'll proceed with the 2 filters.

Perhaps a wp_pre_get_loading_optimization_attributes and a wp_get_loading_optimization_attributes filter.

[flixos90]

@pereirinha Your idea sounds good to me, +1 for implementing one pre_ and another regular (post) filter.

This PR adds 2 filters.

The first one, wp_pre_get_loading_optimization_attributes, allows short-circuiting the core logic, whereas wp_get_loading_optimization_attributes allows filtering the core logic.

Trac ticket: https://core.trac.wordpress.org/ticket/58893

@pereirinha, could you kindly address the feedback provided above and rebase the PR? It's worth noting that https://core.trac.wordpress.org/ticket/58894 was merged yesterday, so this may require some adjustments.

@pereirinha Could you please update code and unit tests as suggested below?

Add pre_wp_get_loading_optimization_attributes filter code after line 5628. and remove your changes for this filter.

/**
 * Filters whether to short-circuit loading optimization attributes.
 *
 * Returning an array from the filter will effectively short-circuit the loading of optimization attributes,
 * returning that value instead.
 *
 * @since 6.4.0
 *
 * @param array  $loading_attrs The loading optimization attributes.
 * @param string $tag_name      The tag name.
 * @param array  $attr          Array of the attributes for the tag.
 * @param string $context       Context for the element for which the loading optimization attribute is requested.
 */
$loading_attrs = apply_filters( 'pre_wp_get_loading_optimization_attributes', $loading_attrs, $tag_name, $attr, $context );

if ( ! empty( $loading_attrs ) ) {
	return $loading_attrs;
}

Unit tests:

/**
 * Tests for pre_wp_get_loading_optimization_attributes filter.
 *
 * @ticket 58893
 */
public function test_pre_wp_get_loading_optimization_attributes_filter() {
	add_filter(
		'pre_wp_get_loading_optimization_attributes',
		static function ( $loading_attrs ) {
			$loading_attrs['fetchpriority'] = 'high';
			return $loading_attrs;
		},
		10,
		1
	);

	$attr = $this->get_width_height_for_high_priority();

	$this->assertSame(
		array( 'fetchpriority' => 'high' ),
		wp_get_loading_optimization_attributes( 'img', $attr, 'the_content' ),
		'The filter did not return early fetchpriority attribute'
	);

	// Clean up the filter.
	add_filter( 'pre_wp_get_loading_optimization_attributes', '__return_empty_array' );

	// Modify the loading attributes with any custom attributes.
	add_filter(
		'pre_wp_get_loading_optimization_attributes',
		static function ( $loading_attrs ) {
			$loading_attrs['custom_attr'] = 'custom_value';
			return $loading_attrs;
		},
		10,
		1
	);

	$this->assertSame(
		array( 'custom_attr' => 'custom_value' ),
		wp_get_loading_optimization_attributes( 'img', $attr, 'the_content' ),
		'The filter did not return custom attributes.'
	);
}

/**
 * Tests for wp_get_loading_optimization_attributes filter.
 *
 * @ticket 58893
 */
public function test_wp_get_loading_optimization_attributes_filter() {
	$attr = $this->get_width_height_for_high_priority();

	$this->assertSame(
		array( 'loading' => 'lazy' ),
		wp_get_loading_optimization_attributes( 'img', $attr, 'the_content' ),
		'Before the filter it will not return the loading attribute.'
	);

	add_filter(
		'wp_get_loading_optimization_attributes',
		static function ( $loading_attrs ) {
			unset( $loading_attrs['loading'] );
			$loading_attrs['fetchpriority'] = 'high';
			return $loading_attrs;
		},
		10,
		1
	);

	$this->assertSame(
		array( 'fetchpriority' => 'high' ),
		wp_get_loading_optimization_attributes( 'img', $attr, 'the_content' ),
		'After the filter it will not return the fetchpriority attribute.'
	);
}

[mukesh27]

@pereirinha, could you please review the suggested changes on the PR? This will help us move forward with this ticket and commit it before the Beta release

Thanks again, @mukeshpanchal27, @felixarntz, and @spacedmonkey, for the feedback.

I addressed all the comments so far.
This is ready for you to circle back.

Thanks, @mukeshpanchal27, for the clarification on the outstanding issue.
I merged your code, and I'm running tests locally to confirm, but this should now be ready.

One small piece of feedback. But this is close.

Thanks @spacedmonkey. I haven't encountered the assertSameSets before, but it is excellent for the other ticket I'm working on.

For this case, given that we are expecting only one key in the array, I wonder if it will make any real difference.

For this case, given that we are expecting only one key in the array, I wonder if it will make any real difference.

If that is the case we should something like this.

$attrs = wp_get_loading_optimization_attributes( 'img', $attr, 'the_content' );
$this->assertIsArray( $attrs );
$this->assertArrayHasKey( 'custom_attr', $attrs );
$this->assertSame( 'custom_attr', $filtered_widgets['custom_attr'] );

@spacedmonkey @pereirinha Apologies, I didn't see your discussion here and just applied the suggestions. While I agree it's not a real issue here, using assertSameSets is generally a bit cleaner when doing assertions on associative arrays, since the order doesn't matter. So for one item it doesn't make a difference, but it's still "more correct" to use assertSameSets just because it is an associative array - e.g. in case the tests were to be adjusted later.

I got some notifications that Felix had merged ​https://github.com/WordPress/wordpress-develop/commit/896b25e63fa057e7902613ba17a3789338f1d4e5. I thought this was revolving everything outstanding.

Is there still an action item pending here?

@pereirinha All good, I'm about to commit this.

Once I have committed it, can you refresh your branch from #4991 with the latest trunk to integrate the changes, in case there are any merge conflicts?

[flixos90]

In 56651:

Media: Introduce filters to customize the results from wp_get_loading_optimization_attributes().

This changeset introduces two filters that allow customizing the loading optimization attributes array returned from wp_get_loading_optimization_attributes() for individual HTML tags:

• The wp_get_loading_optimization_attributes filter can be used to modify the results from the WordPress core logic.
• The pre_wp_get_loading_optimization_attributes filter can be used to use entirely custom logic and effectively short-circuit the core function.

Props pereirinha, mukesh27, spacedmonkey, joemcgill.
Fixes #58893.

Committed in https://core.trac.wordpress.org/changeset/56651

[thekt12]

#58895 was marked as a duplicate.

[flixos90]

The 4 tickets related to wp_get_loading_optimization_attributes() should receive a single dev note post explaining those changes.

[flixos90]

Dev note published: ​https://make.wordpress.org/core/2023/10/18/image-loading-optimization-enhancements-in-6-4/

[flixos90]

In 58974:

Media: Consistently pass 'src' attribute to wp_get_loading_optimization_attributes().

A common use-case for the 'wp_get_loading_optimization_attributes' filter is to modify attributes based on the 'src' attribute. However, the wp_img_tag_add_loading_optimization_attrs() was not passing that attribute to the function as expected, which would make such usage of the filter unreliable. This changeset ensures the 'src' attribute is also passed in this scenario. All other calls to wp_get_loading_optimization_attributes() already included the attribute.

Props deepakrohilla, prestonwordsworth, mukesh27, adamsilverstein, joemcgill, flixos90.
Fixes #61436.
See #58893.