Filtering front_page social image has no effect for single image

[alpipego]

I've used the filter as described in #470, unfortunately, this does not work for the front page.

Since the $single argument in the get_image_details() method is always false it lands in the else part of the condition:

the-seo-framework/inc/classes/generate-image.class.php

Lines 76 to 90 in f23bceb

	public function get_image_details( $args = null, $single = false, $context = 'social', $clean = true ) {
	if ( $single ) {
	$details = $this->get_custom_field_image_details( $args, $single, false );
	if ( empty( $details[0]['url'] ) )
	$details = $this->get_generated_image_details( $args, $single, $context, false );
	} else {
	$details = array_merge(
	$this->get_custom_field_image_details( $args, $single, false ),
	$this->get_generated_image_details( $args, $single, $context, false )
	);
	}
	return $clean ? $this->s_image_details( $details ) : $details;

If the multi_og_image option is false though, the first image is output, which in this case always is the image from the db and not the filtered image generated by callback. Therefor the filter has no effect if get_custom_field_image_details returns and image.

Possible solution: Reversing above lines

$details = array_merge(
    $this->get_generated_image_details( $args, $single, $context, false ),
    $this->get_custom_field_image_details( $args, $single, false )
);

[sybrew]

My apologies for taking this long to get back to you. I took a small break, and this issue is a bit too advanced to coincide with a break 😅.

The function caller can change the $single parameter. $single is only true when we obtain a JSON-LD image, or when we provide the first image used as an example in the admin-area. In almost all other cases, it's false.

When we reverse the non-single lines, per your proposal, the custom image field no longer has the highest priority. But, the custom image field must have the highest priority, as it gives control to the user. This control mustn't be challenged; the SEO settings fields have the final say.

Moreover, the custom field image can not be filtered, and that's intentional: ignoring that field will make the user interface unreliable and unpredictable.

The filter we discussed in #470 is only for the "next best thing." The user can provide the "best thing" via the interface. The option multi_og_image stops the image-obtaining generator/iterator when the "first best thing" is found, either from the user input or from the content.

So, to transcribe:

• On the homepage:
  1. Fetch the homepage settings image, if any.
  2. Fetch the post-custom field image, if any.
  3. Get alternative images.
• Everywhere else:
  1. Fetch the post-custom field image, if any.
  2. Get alternative images.

The default alternative images order is listed at the_seo_framework()->get_image_generation_params(), and you can append, prepend, and remove the callbacks via the filter the_seo_framework_image_generation_params.

[sybrew]

Expounded upon in (hopefully) simpler terms at this comment and exemplified in this gist.