Plugin pulls thumb back down right after removing featured image in WP

[ghost]

Overall, this has been rock solid since I fixed that Gutenberg problem from another thread.

Issue popped up today and I can't see an easy way to deal with this. Client wants to have a post or category of posts not have featured images, but still have a link to a youtube video in the post. All efforts so far show us deleting the image and then a second later, it re-populates the featured image file...

Only solution I have to date is to use bitl.ly shortened links and that removes the URL format the plugin is looking for.

Any way to turn this off per post?

[tw2113]

Closest i can find for a potential solution, with the current code base in version 1.1.1, would be the wds_featured_images_from_video_filter_content and returning some sort of empty value on that.

https://github.com/WebDevStudios/Automatic-Featured-Images-from-Videos/blob/1.1.1/automatic-featured-images-from-videos.php#L113

The question is how to do this conditionally for your cases.

Even something simple like add_filter( 'wds_featured_images_from_video_filter_content', '__return_empty_string' ); would work, but making sure not to do that for every single post would be the important part.

I'm open to ideas on how to handle such a thing, so that we can help provide a solution into the code that is agnostic enough to make sense, but still help your specific usecase.

[ghost]

What about using something like this?
(My php coding skills are rudimentary, obviously)
Here we add code to create a new checkbox inside the Featured Image check box:

// Creating custom field to allow user to grab featured image or not
function wds_ok_to_set_featured_thumb_as_video $content, $post_id ) {
	if( 'post' != get_post_type( $post_id ) )
		return $content;
	$field_id    = 'wds_video_featured_image';
	$field_value = esc_attr( get_post_meta( $post_id, $field_id, true ) );
	$field_text  = esc_html__( 'Get video featured image.', 'wds' );
	$field_state = checked( $field_value, 1, true);

	$field_label = sprintf(
	    '<p><label for="%1$s"><input type="checkbox" name="%1$s" id="%1$s" value="%2$s" %3$s> %4$s</label></p>',
	    $field_id, $field_value, $field_state, $field_text
	);

	return $content .= $field_label;
}
add_filter( 'admin_post_thumbnail_html', 'wds_ok_to_set_featured_thumb_as_video $content', 10, 2 );

function wds_ok_to_set_featured_thumb_as_video( $post_ID, $post, $update ) {
	$field_id    = 'wds_video_featured_image';
	$field_value = isset( $_REQUEST[ $field_id ] ) ? 1 : 0;
	update_post_meta( $post_ID, $field_id, $field_value );
}
add_action( 'save_post', 'wds_ok_to_set_featured_thumb_as_video', 10, 3 );

Then we change lines 151-165 to check if the new field value is true, else we fail as if there was no video content...

	if ( $post_id
	     && $content
	     && ( $youtube_id || $vimeo_id )
	     && ( $wds_ok_to_set_featured_thumb_as_video )
	) {
		update_post_meta( $post_id, '_is_video', true );
		update_post_meta( $post_id, '_video_url', $video_url );
		update_post_meta( $post_id, '_video_embed_url', $video_embed_url );
	} else {
		// Need to set because we don't have one, and we can skip on future iterations.
		// Need way to potentially force check ALL.
		update_post_meta( $post_id, '_is_video', false );
		delete_post_meta( $post_id, '_video_url' );
		delete_post_meta( $post_id, '_video_embed_url' );
	}

Mind you I cobbled this together from about a 1/2 dozen sources and the codex but I think it would work, have not tested yet. If you have any input I'd appreciate it before I try to add this into a local test...

[ghost]

I'm also unclear as to if we need to verify the user via nonce before we save the data out as a security precaution...

[tw2113]

At least in what I can think of right now, it'd probably end up being more of a case of doing a filter early in our save_post callback that checks a variable's boolean status. Skeleton code below.

$bypass = apply_filters( 'maybe_bypass', false, $post_id );
if ( true === $bypass ) {
    return;
}

This way we default to false meaning we shouldn't bypass setting, but we allow someone else to intercept that value and return true if we should. The only caveat of sorts is that we still end up requiring the user to determine if it should skip, and how to do and determine that will depend on each usecase. Could be as simple as storing an array of IDs that shouldn't thumbnails as an option and doing an in_array() check. It could be maybe grabbing a meta value that is from a checkbox saying "don't regenerate" and if checked, return early. That last one may be something we want to consider as part of the core plugin as well.

[ghost]

I agree, the second option (which is I think what the top part of the code I posted does) adds a checkbox that defaults to true.
That way when you install the plugin, the functionality stays the same.
And the user can stop the plugin from fetching a thumbnail from the video URL source by unchecking a box.
Then they can manually remove the one that's already been fetched and insert their own or just not have one (which the the case for my user).
In your example we'd have a checkbox that would say "skip download thumbnail from video source?" and then if that was checked the plugin would not download a thumbnail, correct?

[tw2113]

Gotcha, I missed seeing that checkbox part as I wasn't quite sure at the time about that filter.

I know we have output somewhere for some values, i just can't immediately recall how they are, other than just in the out-of-box custom fields metabox.

The plugin is coded in a way where we don't download/re-upload the same file many times, because that makes a huge mess of media libraries. What we do is we name the images uniquely by the video ID, and before we do any down/uploading, we check the posts table for matching media library items by the same ID and make those the featured image, if found. Long term, what we'd be essentially doing is just not re-assigning the thumbnail meta data if we're told to skip. If at all possible, not doing it in the first place if somehow told not to. Details we'd need to work out.