The template that I use on a development site uses a filter for the has_post_thumbnail function that does not exist in the current version of ClassicPress!
At this point, for the same result, the solution is more complex and much slower, because I need to use a get_post_metadata filter and debug_backtrace to find out if the function call came from has_post_thumbnail ~ (it’s like scratching your left ear using your right foot fingers )
Possible solution
Only an update for has_post_thumbnail is required: code copied from the current version of wordpress:
function has_post_thumbnail( $post = null ) {
$thumbnail_id = get_post_thumbnail_id( $post );
$has_thumbnail = (bool) $thumbnail_id;
/**
* Filters whether a post has a post thumbnail.
*
* @since 5.1.0
*
* @param bool $has_thumbnail true if the post has a post thumbnail, otherwise false.
* @param int|WP_Post|null $post Post ID or WP_Post object. Default is global `$post`.
* @param int|string $thumbnail_id Post thumbnail ID or empty string.
*/
return (bool) apply_filters( 'has_post_thumbnai l', $has_thumbnail, $post, $thumbnail_id );
}
The reason for this is that, as you can see, this filter was added in WP 5.1, whereas CP is a fork of WP 4.9.
I doubt this can be added to the full release of CP v1 now, because it’s too close, but it can probably be added later. In the meantime, have you considered just adding this code in a plugin?
Fun The last time I did something like this, our security lead said “let’s not ship code that might trigger anti-virus heuristics” and we looked for a simpler way to do it.
@timkaye is right on both points - we’d be happy to add this in a future 1.x release, but right now we are too close to 1.0.0.
In the meantime here is some background/info on what we’ve done so far to enable backporting changes from WP: Backport WP5 trac tickets
We have some of the infrastructure to make this work, including a script that copies and reformats a WP commit for ClassicPress, but we haven’t decided exactly what we want to port yet, or how to organize those efforts.
Some changes could have compatibility implications since we still report our WP version as 4.9.x, but adding a filter is pretty harmless.
If you can use our backport script and submit a pull request to add this filter, then we will get it in a future 1.x release.
After some more in-depth analysis of the functionality and the need for such a filter, I came to the conclusion that the best and best would be implemented in the get_post_thumbnail_id function.
The result is much more satisfactory, the use is more versatile and universal, the implementation of solutions becomes much easier, simpler, quicker and more efficient.
Obviously, to maintain somewhat compatibility with the future versions of wodrpress that will come, the proposed filter will have to be added, but the value of a get_post_thumbnail_id filter is much more important than has_post_thumbnail, I would say incomparable!
The idea lies in the need for a more complex plug-in that provides a backup solution (fallback) if the articles / posts do not have an attached picture (thumbnail).
P.S. For the time being, I really have a plug-in for my needs that makes fallback to “more complex” (but slower) solutions if the required filter is not available! But in the future it is recommended to implement the filters so that the resulting code in the end is smaller and simpler.
I used DEBUG_BACKTRACE_IGNORE_ARGS, apparently faster.
I do not use interactions for the verification because I already know the position of the function being searched for. In my case, the exact position can be pre-calculated once when initializing the code.
the 2nd parameter for debug_backtrace is defined, because I do not need the whole stack!
Ideally we’d get this change implemented in both ClassicPress and WordPress, so that plugins using the new filter can remain compatible with both.
I was also wondering if you really need the debug_backtrace shenanigans in this case? I.e. are there harmful effects if you override the post thumbnail meta value in other places, or on specific page loads, or whenever ! is_admin()?
The effects are only of a nature of performance, there are no other side effects. but the solution offered by an optimized plug-in can be much more efficient than an adhoc solution implemented in the hurry when needed!
The advantage of using such a filter for a specialized plug-in, helps other plugins or themes that use thumbnails, to work relatively well without the need for a great change to make everything work, at least visually!
)
The 