Recently, we noticed an issue with Facebook sharing of posts from our WordPress.com-hosted site: our posts, when shared on Facebook, would appear in the sharing preview without a thumbnail image – in spite of all the word we’d done in the past to provide not only an image but a choice of images. Alarming at least from a shareability perspective (posts shared with thumbnail images are far more likely to be read and therefore re-shared), we dug into the mystery and discovered that WordPress.com was adding its own Open Graph image property to our posts (pointing to a blank image), ahead of our own already carefully curated list of images intended for thumbnails – all, as it turns out, a result of our use of JetPack’s Publicize module. I’m not sure whether this is limited to WordPress.com VIP-hosted sites, but it came along with one of the more recent releases of WordPress (at least as it exists on WordPress.com; our local installs, which are provided by VIP and for the most part replicate the VIP environment, nevertheless do not demonstrate this behavior). Here’s what’s actually happening, and how we fixed it: JetPack’s Publicize module adds Open Graph og:image propery tags to the HTML <head> section of posts. In general, this works pretty much as they describe it, with a well-defined and reasonable search order. It’s also effective for the posts in which we have a designated “Feature Image.” The module also adds a bunch of other sharing-friendly information, though, so we added code to override it with information that, because of our settings, we couldn’t do through normal UI routes in wp-admin. Specifically, we wanted to add in our site’s twitter handle, and add in a couple of fallback images of our own (such as the guest author’s headshot, blog icon, or site icon), for posts that don’t have a featured image. The importance of adding fallback images is currently in question, because of a separate issue possibly related to Facebook itself, but in principle we wanted to take advantage of a feature in Facebook sharing that allows users to choose from among multiple different images to share with the post, as they see fit. To do all this, we added a custom filter to our functions.php file:
/**
* Override the default OpenGraph tags
*/
add_filter( 'jetpack_open_graph_tags', function( $tags ) {
$tags['twitter:site'] = '@ourhandle';
$tags['twitter:creator'] = '@ourhandle';
$tags['og:site_name'] = 'Our Site Name';
// the og:image key defaults to the featured image. if the value is
// not set, define it as an array. if the value is set, assume it is
// the featured image (or has been previously filtered)
if ( ! isset( $tags['og:image'] ) ) {
$tags['og:image'] = array();
}
$tags['og:image'] = (array)$tags['og:image'];
if ( is_a_particular_blog() ) {
$blog = custom_get_blog();
$tags['og:image'][] = custom_the_term_image_src( $blog->term_taxonomy_id );
} else {
foreach ( get_coauthors() as $coauthor ) {
$tags['og:image'][] = custom_get_coauthor_avatar_uri( $coauthor->ID, true );
}
}
$tags['og:image'][] = 'http://static.oursite.org/images/oursite_opengraph_360x185.png';
return $tags;
} );
This generated a list of og:image property tags for us that looked, for a post without a featured image, something like this:
<meta property="og:image" content="http://oursite.files.wordpress.com/2013/09/blog-icon.png" />
<meta property="og:image" content="http://static.oursite.org/images/oursite_opengraph_360x185.png" />
A post with a featured image or authored by a guest author who has a headshot in their profile, would see tags for those images – in that order – atop this list. After the WordPress.com updates that triggered the problem, however, we found a fun little blank image, taking precedence over all our others, appearing at the top of the list:
<meta property="og:image" content="http://wordpress.com/i/blank.jpg" />
<meta property="og:image" content="http://oursite.files.wordpress.com/2013/09/blog-icon.png" />
<meta property="og:image" content="http://static.oursite.org/images/oursite_opengraph_360x185.png" />
The way the JetPack fallbacks work, the blank image is inserted at the head of our $tags[‘og:image’] array — not at all convenient. A developer on our team suggested adding a filter that stripped out this image from the array in a hackish way by looking for an image named “blank.jpg”, but ultimately we were unsuccessful (and unenthused) about that solution. Working with our VIP support folks (props to them for the suggestions, though I’m not sure they’d want to be named here without their knowledge :o) we were first given access to a new filter that would have allowed us to override the blank with our own general image:
/**
* Replace the wordpress.com OpenGraph image
*/
add_filter( 'jetpack_open_graph_image_default', function( $url ) {
return 'http://static.oursite.org/images/oursite_opengraph_360x185.png';
} );
Problematically, the image is still appended to the head of the array, even though it is a fallback. Ideally, the JetPack module would append the image to the tail of the Open Graph image array that is constructed – which would also save us the step of adding that particular image in our other filter. Perhaps there was another way we could have changed our other filter with this knowledge, but ultimately the solution that worked for us was to feed an empty string to the VIP-created filter for the custom default image above:
/**
* Suppress the default wordpress.com OpenGraph image
*/
add_filter( 'jetpack_open_graph_image_default', function( $url ) {
return '';
} );
This successfully prevents the image from being added to our array in any way.
Comments are closed.